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

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

Jim,

<snip>

> I think I see what you're saying - why bother wrapping, say, 
> a WS-LRA context inside a WS-Context context when you could 
> just put the WS-LRA context into a SOAP header directly. If 
> that's what you mean then I think it's a reasonable point.

Yes, that's the precisely the point. I originally raised it in Paris,
where most of the counter
argument seemed to be somewhat spurious - amounting to "implementations
today have difficulty doing/don't
do X (even though X is covered in the specifications they do purport to
implement), and WS-Context-by-value offers assitance/an alternative" But
since implmentations would need to be changed to do WS-Context-by-value,
they can surely be changed to the already-specifed X in any case.
 
> However, for some of the work I'm doing now, just having a 
> plain vanilla context is really quite useful.
> 
> So: would it be correct of me to split your argument into to points?
> 
> 1. There is little perceived value in using the context 
> structure to house other contexts. 2. There is little value 
> in WS-Context.
> 
> For the first, the specs (used to) say that higher level 
> contexts dervied from lower level contexts rather than being 
> bundled inside them. That might have changed now (editors?) 
> since pretty much no-one gets substitutionGroups (or so it 
> would seem from the appalling support for them).

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.

So I think that means the higher level contexts are "derived" directly
from the WS-Context context. Whether the derivation is syntactic is
another matter.

> For the second I respectifully disagree. In my work I have an 
> "application X" context which ties together a bunch of 
> services which for me comprise "application X".

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 ?


Thought experiment: You must have some definition of what your
context-type URI means. You probably have some types that go in the
xsd:any element. You possibly have some operations that are implemented
by the same entity as supports the ContextService and ContextManager.
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.
All the rest of the specification is the same. What have you now got to
add that specification that you currently do by reference to WS-Context
? That's the only aspect of WS-Context that justifies its use for your
case. 

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)

Peter