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

["Mark Little" <mark.little@arjuna.com>]

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