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

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

Apologies for the delay in responding to this.  I think the open questions we have about coordination message sets and factoring can only really be resolved in the context of protocol type definitions.  

I think that generic pub /sub protocol may be a good start.  We also have 2PC, LRA, and BP.  What else?  How about plain old shared outcome notification (without recovery) of the set of participating services?  (This could build on the pub/sub protocol type perhaps.)

Eric

-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: Wednesday, October 27, 2004 7:25 AM
To: Greg Pavlik; ws-caf
Subject: Re: [ws-caf] high level description for CF goals/model


Comments inline.

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

I think this is an accurate summary of what we discussed in Dublin.

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

On approach would be to recognize that this is interesting, but to also
recognize that we're working on coordination and transactions in WS-CAF. So
we concentrate only on that aspect and any other factorization is either
done elsewhere or is considered a back-end implementation choice. Look at
what we did with ALS-es in WS-Context, for instance. It's entirely possible
that something like them might rear its head again in some WS-Lifecyle-like
approach, but we agreed that for WS-Context it probably was overkill, and
anyway, it need not be exposed by the WS-Context Service WSDL. The same
argument could be made here.

Just to be clear though: I'm not saying that this factorization isn't
potentially useful, only that maybe for our purposes and time constraints
it's possibly too much.

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

Well actually it doesn't. There's no processSignal operation in the WSDL for
participants as things currently stand.

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

I think we should remove them from CF. But just to be clear and go over what
we discussed in Dublin: the fact that messages are "derived" from some
extensibility message sub-class is a different thing entirely, i.e.,
extensibility options on the messages through inheritence is maybe a good
thing.

> If the spec doesn't do coordination
> signals, does the name WS-CF make sense?

Well I believe the answer should still be yes, because the overall aim of
the specification is coordination. Not that we should necessarily take a
leaf out of the IBM/MSFT playbook, but WS-C is the same - there is precedent
that other areas of the industry (users as well as vendors) are happy with.

> 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?

Mark.

----
Mark Little,
Chief Architect,
Arjuna Technologies Ltd.

www.arjuna.com