[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] Coordination Contexts
Peter, Great, thanks, very much appreciated. I realize the amount of change in the new draft is substantial, which is all the more reason to maintain change control. I realize also that we editors (speaking especially for myself) need to get the new draft out as soon as we can. Eric -----Original Message----- From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] Sent: Sunday, May 30, 2004 2:04 PM To: Newcomer, Eric; Mark Little; Greg Pavlik Cc: Green, Alastair J.; ws-caf Subject: RE: [ws-caf] Coordination Contexts Eric, I had been holding back on various questions until I had seen 0.3. The improvements arising from New Orleans are sufficiently substantial as to make it almost a new specification. Note how many of the messages include reference to this - as answering someone's question or assuming its content (not just my messages, several peoples) However, there are some things that have arisen from the recent discussions that can be put as defined issues, and I've just submitted several. For some of these there are multiple options rather than a single proposed text, since they are often "clarify, fix or delete" - which is what happened with ALS. Peter > -----Original Message----- > From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] > Sent: 30 May 2004 02:33 > To: Furniss, Peter; Mark Little; Greg Pavlik > Cc: Green, Alastair J.; ws-caf > Subject: RE: [ws-caf] Coordination Contexts > > > Peter (and everyone), > > The WS-Context specification is now under change control, and > we are working hard to produce a new draft to incorporate the > changes agreed during previous calls and F2F meetings. > > The time for general discussion has past. At this time for > the sake of progress, and for the sake of the TC, I would > like to ask everyone to please present issues in the form of > suggested changes to specific text. > > When raising an issue, please provide the text citation, > proposed new text, and reasons for the change. This will > help focus the dicussion and ensure we can all make progress > toward the TC goals. > > Thanks, > > Eric > > -----Original Message----- > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > Sent: Saturday, May 29, 2004 8:04 PM > To: Newcomer, Eric; Mark Little; Greg Pavlik > Cc: Green, Alastair J.; ws-caf > 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]