Re: [ws-caf] Coordination Contexts

["Mark Little" <mark.little@arjuna.com>]

> There is no broad functional utility to climbing mt. everest, merely
> subjective utility in the more or less Mengerian sense of the term. As
> much as I enjoy mountaineering, this is not an appropriate analogy for
> structuring the discussion moving forward. Apologies, but I'm changing
> the thread title to reflect the issue at hand more directly.

I didn't there would be any utility in this excercise of climbing, only that
it's possible ;-)

I did think that we had gotten through this "is context useful" debate,
since whenever it has come up before (along with any related issues), a
majority of this TC has either expressed or voted that the answer is "yes".
How many times do we need to go around this before we can move on?

Mark.

>
> As I understand it, Alastair's position is that we require a
> Coordination context, but that it ought not derive from WS-Context, but
> should be invented, along with necessary control interfaces and
> semantics, afresh strictly for application to protocols that require
> coordination signals to be sent in the lifecycle of an -- and I'm not
> sure what term we would apply here without either subsuming or
> referencing WS-Context -- activity. Is this correct or have I grossly
> misrepresented the position?
>
> Greg
>
>
> Mark Little wrote:
>
> >Alastair, I'm happy to discuss climbing Everest in the context (no pun
intended) of WS-CF iff that does not impede the progress of WS-Context.
> >
> >Mark.
> >
> >----
> >Mark Little,
> >Chief Architect, Transactions,
> >Arjuna Technologies Ltd.
> >
> >www.arjuna.com
> >
> >  ----- Original Message -----
> >  From: Green, Alastair J.
> >  To: Mark Little ; ws-caf
> >  Sent: Thursday, May 27, 2004 1:07 PM
> >  Subject: RE: [ws-caf] Mt Everest and WS-CF
> >
> >
> >  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.
> >
> >
> >
> >  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.
> >
> >    To: Mark Little ; ws-caf
> >
> >    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.
> >
> >      To: Mark Little ; ws-caf
> >
> >      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-mappings
-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
> >
> >
> >
> >
>
>