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

["Tony Fletcher" <tony_fletcher@btopenworld.com>]

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?