RE: [ws-caf] Coordination Contexts

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

Just to clarify what I understood Alastair's original point was, since
it's got rather buried in metaphor.

WS-CF needs to pass information allowing the building of its
registration trees.
This will be carried in a SOAP header.
There is no need for WS-CF to take a dependency on WS-Context, since
WS-CF will define most of the
contents and various facilities to use the information in this header.

If it turns out that large chunks of what WS-CF needs are in fact
already in WS-Context, then it is 
indeed reasonable to use it. But there is no need to start with that
assumption. We should see if
we end up back there. Whether WS-CF finds WS-Context useful is not an
necessary answer to the 
question of whether WS-Context is useful.

(one might note, that if WS-CF undergoes as radical a change as
WS-Context in dropping ALS, it is by no means
impossible that it would no longer need the dependency.)

Peter

> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com] 
> Sent: 28 May 2004 10:40
> To: Greg Pavlik
> Cc: Green, Alastair J.; ws-caf
> Subject: Re: [ws-caf] Coordination Contexts
> 
> 
> > 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
> >
> >
> >
> >
>
>