RE: Questions on Document submission

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