Web services composition

According to the WS-choreography charter, and according to the WSA 
requirements, it is stated that Web services should be recursively 
composable.

Let me first of all state that I am personally extremely sympathetic 
with this point of view; as it represents a well-trodden route to large 
scale systems.

However, I have to say that this goal appears to conflict with another 
goal/property of Web services: that a Web service is identified using a 
URI. (The URI part is not relevant to the following discussion, but the 
identification bit is.)

The issue does revolve around names, and please forgive me on two 
counts: if I am wrong then let me know and I will be grateful and this 
is a little technical.

1. Consider what it means for a Web service to be composed. From the 
outside a composed Web service should be indistinguishable from a 
`primitive' Web service -- agent interacting with it should be able to 
do so in essentially the same way that they interact with directly 
implemented Web services. Yet internally, looking at how the composite 
Web service is realized one should be able to see the `parts' -- 
presumably as Web services also.

1.a. If this assumption is not correct, then we can stop now. However, 
think about it: we abandon the explicit goal of Web service 
compositionality. We can still describe the choreography of a set of 
Web services interacting together; but we do not attempt to make that 
choreography have the same essential properties of a Web service -- 
that it has a name, for example.

1.b One may `compose' a Web service by constructing a new primitive Web 
service that engages in the composite choreography and acts as a 
(de-)multiplexor for the component Web services. However, this is not 
really composition in the normal sense as this `front end' is simply 
another primitive Web service; in particular, significant code writing 
is required, not to mention resource management.

2. Suppose that we wish to compose Web services; i.e., that a 
choreographed set of Web services may be considered as a bona-fide Web 
service in its own right.

We interact with Web services by exchanging messages; in particular by 
sending a message to the service as identified by its URI. However, 
composite Web services cannot directly send or receive messages; so to 
actually send a message to a composite Web service requires sending it 
to one of its component services -- ultimately a primitive component.

But that primitive Web service is a service in its own right and has 
its own identifier; which is not the same as the identifier of the 
composite Web service: so, which identifier should the outside agent 
use, and where might it get them from? Since we are not presuming an 
intermediary we have a fundamental ambiguity: a Web service agent 
interacting with a composite Web service may be sending and receiving 
messages from any of the component Web services; each of which has its 
own identifier; and each of which is almost certainly ignorant of the 
identifier of the composite Web service itself.

This results in a scenario where a composite Web service has 
potentially n+1 names associated with it; and any agent interacting 
with it has to be aware of all of them.

3. There are a number of ways of resolving this:

3a. Associating the identifier of a Web service with its description 
rather than the computational resource.

This would allow the n+1 names to be `hidden' behind 1 name: the URI of 
the composite Web service description; with the `low-level' function of 
associating particular messages' destinations and sources being 
effectively masked by the description.

Note that this would mean that descriptions become a MUST have aspect 
of Web services.

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.

3c. Abandoning the explicit goal of Web service compositionality.

4. This is all about names: non-structural names are inherently 
non-composable. And names are pretty fundamental to the Web. (A 
non-structural name is one which cannot reflect the structure of the 
resource it is identified with. URIs are non-structural in this sense, 
LISP meta-structures that denote programs are structural; as might be a 
Web service choreography description.)

Again, if I have missed something obvious, please forgive me, and 
enlighten me.

Frank McCabe

 From WordNet (r) 1.7:

epiphenomenon
      n : a secondary phenomenon that is a by-product of another
          phenomenon

Received on Monday, 17 March 2003 11:41:16 UTC