Re: [ws-caf] high level description for CF goals/model

[Greg Pavlik <greg.pavlik@oracle.com>]

Sounds right .... at the F2F you mentioned that we should also take into 
consideration Alastair's comments but didn't elaborate. In any case, 
these are largely in line with the tentative direction we are 
investigating and I think add some additional rationalizations that we 
need to consider.

Thanks.

Greg


Tony Fletcher wrote:

>Dear Greg,
>
>I have just noticed your request to me at the bottom of this email.  I am
>not sure which of Alastair's remarks you are refereeing to.  If they where
>ones I mentioned at the F2F please remind me of context / subject matter or
>give me some other clue.
>
>Alastair did make three points during the 11 Oct 04 teleconference that are
>(I think) well recorded by Eric in the notes for that meeting.  I quote:
>
>"Alistair: comments - a group of members is an instance of an activity, but
>not necessarily vice versa.  Three comments:
>
>.	The notion of recovering the relationships of a group is a generic
>need, and some level of recovery should be added at the group level - this
>is general
>.	Specific ideas - such a thing as a distinguished coordinator may not
>be always necessary, perhaps groups can have peer to peer coordination
>instead. You may not know in advance that a coordinator is needed,
>determining who is the coordinator may not have to be known during the
>creation of the group. May be better to identify the membership in the group
>first, and then later decide that they need a coordinator
>.	Second specific idea - in certain coordination protocols, the ending
>doesn't arise at the explicit end but rather the end is a deduction based on
>the results of the activities being coordinated. If you have the notion that
>"end must come" as a result of a context activity, you may end up with an
>additional message. I'm not sure therefore that the layering on context will
>serve us well when it comes to transaction protocols."
>
>This is an expansion on my personal notes for that meeting.  Is this what
>you were referring to??  If not then please give me a clue and a prod.
>
>Best Regards     Tony
>A M Fletcher
> 
>Cohesions  (TM)
> 
>Business transaction management software for application coordination
>www.choreology.com
> 
>Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
>Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
>tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
>
>
>-----Original Message-----
>From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
>Sent: 25 October 2004 21:38
>To: ws-caf
>Subject: [ws-caf] high level description for CF goals/model
>
>
>Based on the discussion we had at the F2F, I have tried to describe the 
>model we were moving toward and the issues that we had not come to any 
>resolution on. I hope I have retained the spirit of the discussion. I 
>can take another stab at this if not, or if there is a need to take 
>things to another level of detail.
>
>Registration
>
>WS-CAF provides a set of modular and composable service definitions to 
>facilitate the construction of applications that combine multiple 
>services together in Composite Applications. The fundamental capability 
>offered by the WS-Coordination Framework specification is the ability to 
>register a web service as a participant in some kind of domain specific 
>function. An example scenario may be to register with a pub-sub topic to 
>receive a stream a messages asynchronously. The registration endpoint is 
>described by WSDL and provides operations to register and unregister for 
>participation with specific operations described in WSDL. The semantics 
>of the domain are communicated by a protocol identifier. While it is 
>expected that the vast majority of protocols will involve some form of 
>signaling to registered services via SOAP messages, this signaling is 
>not a part of the model itself at this level. Monitoring protocols for 
>example may express interest in participation is some interaction 
>semantic without any subsequent signaling to registered services; 
>Pub-sub protocols may use some optimized channel based on a native MOM 
>protocol for message distribution. There is also no assumption how 
>signals sent to registered services relate.
>
>Comment: note that this point, WS-Context is not referenced.
>
>Comment/Question: I am throwing out the fact that this appears to be 
>similar to the subscription concept, but the main difference is there is 
>no concept of expiration of the registration act. It is just 
>"enlist/delist". An easy way to support this is to add an "isRegistered" 
>which could be used in a number of ways. Are there other use cases to 
>support this? How far do we want to pursue this at a conceptual level? 
>If we opt not to pursue it, then the idea that registration, context and 
>group membership should be considered as separate building blocks 
>probably can't be rationalized.
>
>Group Membership
>
>WS-Context provides a late binding session model for the web services 
>environment. SOAP messages that are to be processed within the scope of 
>an activity contain context headers, uniquely identifying a single 
>activity-model pair. WS-Coordination Framework extends the session model 
>for protocols that require group membership paradigms by defining a 
>"Registration Context". The "Registration Context" extends the basic 
>context type and provides a Web service reference to a "Registration" 
>endpoint. Registration in the context of an activity adds the registered 
>service to an activity group. Membership in the group may be used to 
>drive some group specific protocol (eg, data replication) over the 
>lifetime of the activity group or may be used to coordinate signals 
>associated with a termination protocol (eg, two phase commit). The 
>purpose and semantics of activity group membership are protocol specific.
>
>Signaling
>
>The WS-Coordination Framework currently provides generic port type 
>declarations used to send protocol specific signals to activity group 
>members throughout the lifecycle of the activity.
>
>Open Questions: if coordination signals are 1) defined by derivative 
>specification and 2) also supported by specific WSDL operations in these 
>specifications (eg, WS-TXM), are the generic coordination endpoints 
>necessary? Do we want two ways to do the same thing (not to intermingle 
>roles, but our position is no)? If the spec doesn't do coordination 
>signals, does the name WS-CF make sense? Note that at the F2F we had 
>talked about the two models (somewhat imprecisely) by referring to the 
>generic coordination endpoint in CF as the Activity Service model and 
>the specific operations in WS-TXM as the WS-Transaction model.
>
>Comment: Tony, I could not find the comments from Alastair that you 
>referred to. Are they in the mail archives?
>
>  
>