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

["Jim Webber" <Jim.Webber@newcastle.ac.uk>]

Hi Peter, 

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


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

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

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

My current work places no additional constraints on WS-Context. It would
work with anyone's WS-Context implementation.

Jim
--
http://jim.webber.name