Re: [ws-caf] Mt Everest and WS-CF

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

> > Peter, that is incorrect. Maybe there is a problem with the
> > text describing this, but I thought we were quite clear in
> > the 0.2 draft that a context identifier represents an
> > activity which represents a set of related invocations on
> > (potentially a number of different) Web services. As such, by
> > itself it does have implied semantics: correlation of
> > invocations. This is precisely what Jim, Savas and the WS-GAF
> > document defined last September (I think). As such,
> > WS-Context is useful by itself.
>
> What does correlation cause to happen ? Something has its behaviour
> modified by the presence of the WS-Context header or there wasn't any
> point in sending it. Stating that a context identifier labels the
> invocations in an activity means nothing unless the activity itself has
> some  attributes that are known among the implementations.

Obviously something needs to understand what only having a context id
(activity identifier) in the header means. Just as you'd expect something to
understand some other entry in a SOAP header (or what's the point of sending
it). What I meant was that there is no requirement for a referencing
specification to augment context in order for "raw" context to be useful in
and of itself.

>
>
> Another way of expressing this:
>
> a) A SOAP implementation allows access to the headers, and has no
> constraints on the headers - they can be inspected and walked through as
> xml constructs. (as infoset or raw, as you please - infoset only if it
> can find the schema) Is it an implementation of basic WS-Context ?

No, because WS-Context does not "operate" on the whole SOAP header.

>
> b) The implementation is modified to recognise WS-Context headers, and
> offers an additional internal api that gives access to them via
> thread-local storage. No deployed application uses this new api. Is it
> an implementation of basic WS-Context ?

I suppose so, but since no services use the API, who knows?

> c) the implementation is modified such that if it receives a WS-Context,
> and the mustPropagate flag is true, and the processing resulting from
> the received message causes any outbound soap messages, the WS-Context
> header is copied unchanged to that. Is it now an implementatioan of
> basic WS-Context ?

Is there an API as in b)? Ignorning the API issue (not really sure what your
point is here with regard to the API), it's as much an implementation as b)
since mustPropagate is optional anyway.

>
> d) An application using a) or b) includes the context identifier in its
> access logs, but does nothing else. Is it now an implementation of basic
> WS-Context ?

It's a user of WS-Context.

> I'm not sure what else can be done with just WS-Context alone - and even
> d) seems to have some understanding of a specification in addtion to
> WS-Context itself. Anything more (like recognising it as a WS-CF context
> and registering with the coordinator, or adding stuff to it) would
> clearly be implementation of a WS-Context-using protocol, not of
> WS-Context alone.

No, I think talking at slightly cross-purposes: the point I tried to make
was that there is no requirement to augment a basic context in order to use
WS-Context. Obviously there is a requirement for recipients to understand
what a raw context id means.

Anyway, in light of Martin's email this may be moot if you have a specific
proposal.

Mark.