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

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

Green, Alastair J. wrote:

>Hi Mark, 
> 
>You pointed the list at an interesting document by Savas et al. I
>commented upon it, as did Peter upon the interop demo, because it
>illustrates a fundamental issue for any potential user of WS-CAF: what
>is the worth of WS-Context context-by-value? 
>  
>

"Every example of WS-Context use that I see discussed
uses "by value". I certainly think that coordination protocols need
by-value contexts (which of course can be carried in SOAP headers
directly)."



> 
>The argument for this feature seems to resemble the motivation for
>climbing Mt Everest: "because it's there". 
> 
>I don't think that this question can be circumvented, and it is relevant
>to WS-CF. Should WS-CF have a necessary dependency on WS-Context? After
>all, WS-Coordination manages to create a generic tree-building
>(address-exchange) protocol without use of a layer like WS-Context. I
>think this is a better model. Then those who wish to wrap context
>information in standard wrappers can do so (use WS-Context), and those
>who don't wish to do so, don't need to (ignore WS-Context as adding
>little real value). 
> 
>My interest in this is far from academic. If WS-CAF transaction or
>coordination protocols gain traction at some future date, then I would
>like to make our engineers' lives as easy as possible, by streamlining
>the work needed to the strictly necessary (after all, it will only be
>the third set of two-phase outcome protocols we have to add to our
>product, in order to accommodate the jostling of the software industry
>majors). I cannot see how WS-Context contributes to WS-CF or WS-TXM.
> 
>Incidentally, I made no mention of context by reference. I view this as
>an interesting possibility fraught with problems, which I predict will
>not be widely used. Every example of WS-Context use that I see discussed
>uses "by value". I certainly think that coordination protocols need
>by-value contexts (which of course can be carried in SOAP headers
>directly).
> 
>Alastair 
> 
>-----Original Message-----
>From: Mark Little [mailto:mark.little@arjuna.com] 
>Sent: 27 May 2004 10:20
>To: Green, Alastair J.; ws-caf
>Subject: Re: [ws-caf] interesting document
> 
>Alastair, is this interesting for a purely academic standpoint? I
>believe that the TC already discussed these issues and voted on them, so
>it seems like going back over old stuff to me. To summarise what this TC
>already agreed on, since we neither mandate context-by-value nor
>context-by-reference in the base-line context document, it is up to
>referencing specifications to determine which format they wish to use. I
>think that arguing this again is not going to be fruitful and I'd like
>to see this TC move on to the coordination specification (which was
>agreed at New Orleans).
> 
>Mark.
> 
>----
>Mark Little,
>Chief Architect, Transactions,
>Arjuna Technologies Ltd.
> 
>www.arjuna.com
>----- Original Message ----- 
>From: Green, Alastair J. <mailto:Alastair.Green@choreology.com>  
>To: Mark Little <mailto:mark.little@arjuna.com>  ; ws-caf
><mailto:ws-caf@lists.oasis-open.org>  
>Sent: Wednesday, May 26, 2004 6:03 PM
>Subject: RE: [ws-caf] interesting document
> 
>I have to believe I'm missing something or being plain stupid, but here
>goes ...
> 
>It would be interesting, in light of Peter's recent mail on the value of
>WS-Context context-by-value, to examine what would change in these
>scenarios if the <ctx:context/> were to be replaced by a simple SOAP
>header element. Strip out <ctx:context/>, replace the placeholder
>"context state" with <protocol:context/>, place this element in the SOAP
>header, and proceed. This would be a less restrictive, but I believe
>legal, use of WS-I (i.e. move protocol-specific context info from body
>to header).
> 
>It would also be interesting to consider, in the light of Jim and Guy's
>exchanges, what role activity completion plays, if any? Activity
>completion can only be communicated to context recipients if they are
>registered with the context service that knows that the activity is now
>complete. WS-Context does not define such a registration-notification
>mechanism. This continues to leave in question the independent value of
>WS-Context context-by-value. This type of functionality must reside in
>the surrounding protocol (session, coordination etc) that in my example
>is denoted by the namespace URI indicated by the prefix "protocol" (the
>"referencing specification"). An example of such a protocol is WS-CF, or
>in truncated form, WS-Coordination.
> 
>As there is no bundle of contexts specified by WS-Context (if my
>understanding has kept pace with the spec changes), the argument that
>value is provided by easing interception (simpler to identify the group
>of contexts that must be processed by a set of interceptors), becomes a
>non-argument.
> 
>Where does this leave the independent value of WS-Context
>context-by-value?
> 
>These points are orthogonal to the issue: header element in the raw,
>body element in the raw, or element embedded in an address.
> 
>Alastair
>-----Original Message-----
>From: Mark Little [mailto:mark.little@arjuna.com]
>Sent: 26 May 2004 16:45
>To: ws-caf
>Subject: [ws-caf] interesting document
>http://forge.gridforum.org/projects/dais-wg/document/draft-ggf-dais-mapp
>ings-ggf11/en/1
> 
>And Savas is a member of this TC (though I don't think he's ever
>attended any of the teleconferences ;-)
> 
>Mark.
> 
>----
>Mark Little,
>Chief Architect, Transactions,
>Arjuna Technologies Ltd.
> 
>www.arjuna.com
>
>  
>