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

[Greg Pavlik <greg.pavlik@oracle.com>]

Peter, a minor comment: the WS-Context specification defines a number of things. An incomplete list includes: 1) it introduces the notion of an activity, which is understood to be a scoping mechanism for some set of web service operation invocations 2) it introduces a (basic) context structure that communicates to participants that they are in fact being asked to execute in the context of an activity and 3) it introduces web services interfaces that allow applications to demarcate and control the lifecycle events of an activity.

I mention this because a satisfying 3 (which is a reflection of 1) is made both simple and intuitive by the existence of 2. While we could imagine using an arbitrary SOAP Header in lieu of a context, it seems to me that we would wind up having to add most of the same "generic" elements to each of these new headers. At which point clever implementers would probably generate a parent or container type, ie, would have to recreate the context structure on an ad hoc basis.

Greg

Furniss, Peter wrote:

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