- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 18 Mar 2003 14:27:35 -0800
- To: "Francis McCabe" <fgm@fla.fujitsu.com>
- Cc: <www-ws-arch@w3.org>, <public-ws-chor@w3.org>
> -----Original Message----- > From: public-ws-chor-request@w3.org > [mailto:public-ws-chor-request@w3.org]On Behalf Of Francis McCabe > Sent: Tuesday, March 18, 2003 8:50 AM > To: Assaf Arkin > Cc: www-ws-arch@w3.org; public-ws-chor@w3.org > Subject: Re: Web services composition > > > > Assaf: > >> > >> 3b. Not associating an identifier with a Web service at all: Web > >> services would become epiphenomena of the interaction of Web service > >> agents. I.e., the WSDL description would identify the identity of the > >> providing agent for each message exchange pattern, rather than any Web > >> service itself. > > > > What about another alternative. The composed Web service is known by > > it's > > definition like any other Web service (WSDL). For the purpose of > > interaction > > there is no distinction between a composed Web service, a non-composed > > Web > > service. > > That is precisely what I am suggesting. However, this is an issue, > because in the Architecture group the description of a Web service need > not be a resource (in the WWW sense). I can see why people think WSDL is confusing. It both describes the service type (what it does, etc), and it also describes the service itself, and there could be multiple services for the same type. And the later is just another way to represent an end-point, just more capable than a URI. WSDL doesn't have to do both, I can have one WSDL for the service type, and a lot of WSDL's for different services that implement this type. So the layering has purpose but the fact that we use one schema brings a lot of confusion. And to add insult to injury I may just know the end-point URI, or I may know the end-point definition as given by WSDL, and they're conceptually equivalent. Let's assume a service is a resource and has an identifier. But the definition of an identifier does not require it to be the end-point. It may be a reference to it's end-point definition, or it may be just a name with which you can find the end-point definition. The definition is a resource - it has an identifier by which it is known. It may not be an accessible resource with some know URL where you can get it, but it's still a resource. So yes, I can see why this is confusing, and I'm not sure I clarified anything, not even to myself;-) But going back to the name issue. If you need an end-point than a composite Web-service has an end-point just like any other service and you don't need to know about the end-points of the composed services unless you care about that. If you need a definition than a composite Web-service has a definition just like any other service and you don't need to know about the definition of the composed services unless you care about that. So hiding a lot of names behind one name, but allow these names to be known if necessary, works well whether we're talking about end-points for the purpose of sending/receiving messages, or about descriptions for the purpose of a better understanding of how to use things. arkin > > Frank
Received on Tuesday, 18 March 2003 17:28:14 UTC