RE: Web services composition

> -----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