W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2003

Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003

From: Ugo Corda <cordau@acm.org>
Date: Sat, 28 Jun 2003 15:48:17 -0400 (EDT)
To: <www-ws-desc@w3.org>
Message-ID: <000e01c33dae$36262820$6801a8c0@ucordahome>






Anne,

Let me see if I understand you correctly. I think you are saying two things.

a) A serviceURI is a way of associating a URI with a particular wsdl:service
(single interface), so that this URI abstracts away the individual endpoints
and associated URIs.

This is fine with me. The URI of the WSDL document plus the fragment
identifier mechanism gives us that type of URI right away.

b) A serviceURI is a way of abstracting away a particular wsdl:service
document instance, so that I could change some of the endpoint URIs under
that wsdl:service (and generate a new WSDL document) and still refer to the
same serviceURI.

I am not sure we need this. We could just keep the endpoints the same while
changing the underlying implementation and/or deployment. (To take your
parallel with a Web site's home page, the Yahoo home page is always
http://www,yahoo.com regardless of any change in the underlying
implementation and deployment).

Regarding the use case of a single service implementing multiple interfaces,
that "service" will actually be a bunch of wsdl:service's, and this
particular type of relationship among them could be addressed by the service
group solution.

(As you can see, I am taking a minimalist approach and trying to avoid
introducing new concepts unless they appear to be absolutely necessary).

Ugo

----- Original Message -----
From: "Anne Thomas Manes" <anne@manes.net>
To: "Ugo Corda" <UCorda@SeeBeyond.com>, <www-ws-desc@w3.org>
Date: Sat, 28 Jun 2003 07:57:02 -0400
Subject: Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003


Ugo,

My proposal for point 1 is simply the assignment of a name (a URI -- let's
call it serviceURI) to a service implementation (a resource). As with any
resource, there's no reason why you can't change the code that implements
this resource.

In many respects, it is equivalent to assigning a URI to a Web site's home
page. There's nothing stopping you from changing the code behind the Web
page (in fact it happens all the time).

I proposal the serviceURI SHOULD NOT be the same as the endpoint URL of the
service implementation -- for exactly the reason that you may want to change
its implementation some time down the road.

And I think I agree that the new wsdl:service definition looks pretty close
to being right for the definition of a service implementation -- but I
suggest that the resource MUST have a serviceURI name. Given the naming of
the service implementation, I'm not sure we then need targetResource -- or
perhaps it could be added to the service group definition as a means to
identify the relationship among the services in the group.

By naming the service implementation, you also solve the use case where a
single service might implement multiple interfaces -- you would still
maintain the one service/one interface requirement, but you could define
multiple service implementations that reference the same serviceURI.

Anne
Received on Wednesday, 2 July 2003 09:53:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:25 GMT