RE: Questions on Document submission

more comments below...

p11: a Web Service is identified ... on the header... -> in the header of what ? every message that his this service, in an initialization message?

>> In the simplest case, where the composite Web services take responsibility for managing their own context, it would be every message in an interaction. Meaning that the appearance of the context URI in the header of the message indicates that the Web service requester is asking the Web service receiver to participate in the same composite application, by definition sharing the same context.
[<JJ>] I see, let me try to re-phrase this in my own words to see if I hear you correctly. You are in effect suggesting to "externalize" or otherwise "separate" the notion of application (and therefore application state) from the services. You basically attach the "application state" to the request, such that when a service receives a request, it first look at the context and says, for this request, I am working for this "application" and here is what I am supposed to do. I like that idea a lot. That would in effect favor the re-use of web services across a lot of different application types and helpthe web services designer/implementer to make them far more generic (otherwise I can really see this kind of logic being embedded within the web service itself).

I am trying to establish a distinction between coordination and composite apps and I am having difficulty. It seems that a coordinator is both a part of a composite app (providing its services to the CA), and managing several CAs.

>> The main difference a coordinator brings is that it provides a software agent to manage context on behalf of the Web services participating in a composite application. In this case, instead of simply sharing context, Web services also register themselves with the coordinator so that the coordinator can take care of quality of service items such as persisting the context, ensuring every Web service in the composite has a consistent view of the context, and that the coordinator can also drive additional protocols across the participants that register (such as transactional protocols).
[<JJ>] Again, to see if I hear you correctly, the coordinator really manages one application type (therefore is part of the CA definition), but of course can deal with many application "instances" at the same time. Of course coordinators (and therefore applications types can be composed). I am not sure that what I am saying here is correct when I look at figure 3 of the primer in details. I don't know if you would have some time to explain this figure in detail.

What is the relationship between coordination and orchestration? (participants, activities, coordination points, ...). Is coordination a special form of orchestration?

>> Coordination plays a supporting role to orchestration, managing context where system and/or persistent data needs to be shared among serviecs in the composite, and recovery protocols in the case of failure handling during the execution of an orchestration flow.
[<JJ>] Yes, I can see that, thanks.

Jean-Jacques
tel: 425-649-6584
Cell: 508-333-7634

Dear WS-CAF TC Members,

On behalf of the companies sponsoring the WS-CAF collaborative effort, Arjuna Technologies, Fujitsu Software, IONA Technologies, Oracle Corporation, and Sun Microsystems, I am very pleased to submit the WS-CAF set of specifications (WS-Context, WS-Coordination Framework, and WS-Transaction Management, along with the Primer) to OASIS under royalty free terms and conditions.

The WS-CAF companies listed above are the authors and copyright holders of these specifications, which from this point forward will be under control of the OASIS WS-CAF Technical Comittee. The purpose of submitting these specifications is to allow them to be progressed toward OASIS standards by the TC.

ws-caf message