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

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

Green, Alastair J. wrote:

>Mark, 
> 
>I am not asking for anything to be revisited (at least fundamentally: if
>it turns out there are unturned model issues or bugs in WS-Context over
>time, I'm sure we will all be happy to entertain them). 
> 
>I am content that WS-Context exists, and that you think it is valuable,
>while I question its value. 
> 
>Like Mt Everest, it is there. That may not mean that I want to climb it.
> 
>My current concern is precisely the relationship between WS-Context and
>WS-CF, which you take as given, and which I wish the TC to question. 
> 
>If you look again at my mail you will see that I am making two points,
>which I think you are missing.
> 
>1) I am not discussing whether to use by-value or by-reference. I am
>discussing whether to use WS-Context at all. (I assume by-reference is
>idiosyncratic with respect to WS-CF etc; I see no proven worth in
>WS-Context-by-value over plain old SOAP header elements.)
> 
>2) I am specifically raising whether WS-CF should reference WS-Context,
>or whether it should not reference WS-Context. I see no need for WS-CF
>to do so, and I believe that doing so causes unnecessary complexity and
>implementation effort for WS-CF and WS-TXM. The relationship is
>artificial.
> 
>I believe that the model of WS-Coordination and its relationship to the
>coordination protocols in the WS-Transaction family is correct; that is
>to say - all that is required. We should apply Occam's razor here. If in
>the mists of the pre-history of WS-CAF and WS-C+T IBM and Microsoft
>sheared away the predecessor of WS-Context, then I think they were right
>to do so (for the purposes of defining coordination protocols).
> 
>In addition, and with reference to the political concerns you raise
>about impeding adoption:
> 
>3) I believe that if other standards bodies adopt WS-Context then they
>are probably not looking hard enough at the value they will obtain by
>doing so. The tough job is to define the content, nature and meaning of
>context information for a particular higher-level protocol; not to
>define a generic wrapper element to hold all such contexts, nor to
>define an interoperable factory interface.
>
I guess I remain confused: why should the simple parts have to be 
re-created on an ad hoc basis for every new specification? This is the 
part of the argument that I can't seem to digest. It seems to me this is 
exactly the kind of thing that should be factored into a common 
specification.

A further comment on the IBM/MS product specs: there are in fact three 
contextualization mechanisms: one in WS-Coordination, one in 
WS-ReliableMessaging, and one in WS-Addressing. Putting aside 
WS-Addressing for a moment since it introduces a new model to the web 
services environment that I don't want to argue about here, let me 
observe that there is no fundamental distinction between the lifecycle 
control interface in WS-Coordination and WS-ReliableMessaging. Why 
shouldn't these be based on a common model? Wouldn't that in fact be 
simpler and less error prone? From there, it seems a small step to 
imagine the reliability and coordination/transaction contexts having a 
common root. I submit that this is in fact a flaw, not a strength, of 
the specification set; they they are unnecessarily complex due to the 
failure to deal with common constructs, idioms and patterns as, well, 
things-in-common.

Let me see if I can draw an analogy. Some years ago we were discussing 
the ACE toolkit for C++ network applications. The advantage of ACE as I 
see it, is that it reifies common patterns in components that can be 
easily resused. Web services are a step up the abstraction ladder from 
component toolkits, but should they be a step all the way up to simply 
referencing common patterns somewhere on mailing lists, or should we be 
aiming for at least some set of standardization that aims at avoiding 
the problems associated with continuous reinvention?

> 
>Alastair
> 
>PS It is always a good idea, as Peter points out, to justify the
>existence of a specification in the specification or accompanying
>material. 
> 
>-----Original Message-----
>From: Mark Little [mailto:mark.little@arjuna.com] 
>Sent: 27 May 2004 11:42
>To: Green, Alastair J.; ws-caf
>Subject: Re: [ws-caf] Mt Everest and WS-CF
> 
>Alastair, I understand why you may want to revisit this, but obviously
>disagree and don't want the TC process to be unduly stalled. I cannot
>see what adverse effect going forward with the specification as it
>currently stands has on any referencing specification that decides not
>to use context by value but instead chooses context by reference (and
>vice versa). It does neither impinges on the readability of the
>specification nor on the understandability IMO.
> 
>I re-iterate that I believe we have already discussed this subject over
>the past 2/3 months in teleconferences and face-to-face meetings. I
>don't believe that revisiting it will benefit us or the WS-Context
>specification at this stage. What it will do is delay the adoption of
>WS-Context by other interested groups and by other referencing
>specifications (e.g., WS-CF). I see that as a big disadvantage.
> 
>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: Thursday, May 27, 2004 11:28 AM
>Subject: [ws-caf] Mt Everest and WS-CF
> 
>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? 
> 
>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
>
>  
>