RE: Questions on Document submission

["Newcomer, Eric" <Eric.Newcomer@iona.com>]

Title: Message

Jean-Jacques,

 

Basically, yes.  The main idea is to manage shared application state (normally system state but perhaps application-specific state) separately from the application.  I did not remember to mention the word "scope" but in the WS-CAF specifications this word is used to identify the Web services that share state, and therefore are considered to be within the same composite application.

 

The specs are written as a layer of functionality.  In the simplest case, the state is kind of "self managed" -- that is, the application manages the state itself with no external guarantees about persistence, recoverability, lifecycle etc.  This is the basic WS-Context specification.  Within the WS-Context specification there is also an optional lifecycle service (the "activity service")  to provide some level of external support for context management.  However, the activity service does not drive protocols or augment context, which is left to the coordinator.  The coordinator is really the thing that manages shared state on behalf of multiple applications, and to accomplish this the applications (i.e. individual web services within the applications) must register with the coordinator to recieve callbacks etc.  At this stage interaction between the "context management" facility is defined in terms of interaction between the coordinator and the application(s).

 

I will take an action item to better explain Figure 3 and send the text to the list.  I agree that the text is not as clear as it should be. 

 

Regards,

 

Eric

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
Sent: Wednesday, November 05, 2003 11:08 AM
To: Newcomer, Eric; ws-caf
Subject: RE: Questions on Document submission

Eric:

 

more comments below...

primer:

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

 

primer and ws-cf:

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. 

 

Cheers,

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

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
Sent: Friday, October 31, 2003 9:06 AM
To: ws-caf
Subject: [ws-caf] Document submission

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.

 

Regards,

 

Eric Newcomer

IONA Technologies