[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] Coordination Contexts
Eric, Some of this discussion may have gone into areas that you feel have been worked over, which is why I have been raising it as a documentary point - the specification or its supporting material needs to explain why or in what circumstances use of a header derived from ws-context is better than just putting the same information in a SOAP header. (phrased better in other messages) There has been a lot of assertion (in previous waves on this) that ws-context can be used for various purposes. That's getting the question the wrong way round - the question is not can ws-context be used, but is it needed? What is gained by ws-context-by-value that would not be provided by the simple header ? The recent discussion has produced some aspects of this answer - especially the exchanges with Greg. But we need to capture that answer, so when it someone outside the tc asks it, we can say "here is the answer". Peter > -----Original Message----- > From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] > Sent: 29 May 2004 15:37 > To: Mark Little; Greg Pavlik > Cc: Green, Alastair J.; ws-caf > Subject: RE: [ws-caf] Coordination Contexts > > > To second Mark's point, let's please confine debate to issues > that remain open. The question of context by value and > context by reference has been closed, as has the question of > whether or not contexts are generally useful. > > Please let's have some debate on new topics, and suggestions > for improving the specifications rather than continually > bringing up the same old concerns over and over again. > > Thanks, > > Eric > > -----Original Message----- > From: Mark Little [mailto:mark.little@arjuna.com] > Sent: Friday, May 28, 2004 5:40 AM > 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 > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]