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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

interleaved

> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com] 
> Sent: 28 May 2004 14:12
> To: Furniss, Peter; Jim Webber; ws-caf
> Subject: Re: [ws-caf] Mt Everest and WS-CF
> 
> 
> > > 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.

that's what I meant by "overloading the context id" in an earlier
message to Jim. Certainly the existing fields, even the id alone
may have meaning - but that meaning is defined by the referencing
specification. WS-Context is NOT useful by itself. It's syntax might be,
but the other side needs to have access to the document that is
logically pointed to by the context type (aka referencing
specification).
 
> >
> >
> > 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.

well, the point was that an application that wanted to, and was written
in the knowledge of a particular context use could find the context an d
use it appropriately. I was trying to see if there was any meaning in an
infrastructure/web-stack implmeentation saying "we support ws-context."
- which would distinguish a) and b). I suspect there isn't.

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

In which case we agree. Substituting the xsd:any will not be needed for
all ws-context uses. Adding to the shared semantics is.
 
> Anyway, in light of Martin's email this may be moot if you 
> have a specific proposal.
>
> Mark.
> 
> 
>