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

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

Jim,

> > I believe the changes in New Orleans mean that a context is
> > monolithic - a context covering security+transactions is 
> > defined as such and has no derivation or containment of the 
> > security and transactions contexts (though obviously it might 
> > well incorporate some of the same elements in its xsd:any element.
> 
> Oh. I rather thought that a security context and a 
> transaction context would be totally different entities, 
> albiet that they would inherit the basic context structure 
> from WS-Context.

Yes, I think that's where we are now. At one time there was considerable
discussion
about dealing with the case where multiple context uses interacted (as
those two do). 
As I understand it, the answer is that the combined use is defined in
its own right.
(among other things, this is an implication of dropping the ALS)
 
> > So what features of WS-Context are vital to your use that
> > save you writing them in the specification of your particular 
> > use of ws-context ?
> 
> I need to be able to to together a group of operations across 
> a number of services. It's essentially a distributed session. 
> Programmatically, I don't need anything more than a unique ID 
> for this, but I do need for the context structure to be 
> standardised because some of the services I use won't be mine.

"some of the services won't be mine" ? I take it you are hoping they
will implement WS-Context, as part of their bundle of WS--*.

But they have to implement your particular use of context. Something in
that box has to understand your particular use to make it worth sending.
(that's the
mustUnderstand=false case - if it's true, the case is even stronger)

Even if all a service has to do to be part of your application X is
write the identifier in its records, it has to know to do that. If all
it must do is put the identifier on the response, it has to know to do
that.

WS-Context CANNOT be used alone. There MUST be a "referencing
specification"
that is implemented at all the points where the context is used. In
other words a
defined protocol. The
referencing specification may be written only on your whiteboard, or
even only
in your head, but it exists. And it has a URI that identifies it.

> > Thought experiment: You must have some definition of what
> > your context-type URI means.
> 
> Yes.
> 
> > You probably have some types
> > that go in the xsd:any element. 
> 
> No, but I wouldn't rule it out.
> 
> > You possibly have some
> > operations that are implemented by the same entity as 
> > supports the ContextService and ContextManager.
> 
> Not in this case. 
> 
> > Suppose you defined the types that go in the xsd:any as soap
> > headers in their own right. You can use the context-type URI 
> > as the namespace uri.
> 
> That's not the semantic I'm after. I want to be able to tie 
> together operations in an activity, and I want to be able to 
> know when that activity is over (in some cases).

you're sort of refusing to do the thought experiment :-) Never mind the
standardisation bit, state what you would have to define as part of the
use of the header version. Anything you have to define for that, that
you don't have to define for WS-Context, is the value of WS-Context.

"tie together operations" - I think you mean you want an identifier to
propagated on each operation. Ok,
you can do that in a header. The far-end won't understand it any more or
any less for being in a WS-Context with your context-type URI or your
header namespace.

"to know when the activity is over" - how is this getting determined ?
The only mechanism in WS-Context is complete (post New Orleans, that now
has an optional completion status, whose values you must define, I
think). That can only be effective once, so who sets it - and what takes
the information from the context service ? Are the service calling the
context service - in which case they require the <activity service>
element in the contexts they receive. (=constraints on the
implementation)
 
> All I'm asking for is a standardised vanilla context that my 
> application services can use. I think there is value in that 
> - there is for my work.
> 
> [snip]
> 
> > Does your current specification put constraints on the
> > WS-Context implmentation ? Would it work with an independent 
> > WS-Context implementation ? (are the identifiers truly 
> > opaque, for example)
> 
> I don't work on specifications any more Peter :-) I changed 
> jobs a while back...

You do work on specifications if you in any way do something that
determines what an interoperating machine must do. You answered:

> > You must have some definition of what
> > your context-type URI means.
> 
> Yes.

that's a referencing specification.

Peter