[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] Mt Everest and WS-CF
Peter, would it simply be satisfactory to address these questions directly in the FAQ or primer? Furniss, Peter wrote: >I'll restate the documentation question I raised on this: > >Does the specification state what are the advantages of using ws-context >by-value over and above using a SOAP header with the same application >information. > >Does it state what considerations would lead a designer to choose to >define a use of ws-context by-value instead of defining a soap header. > >I don't believe the question (which is quite distinct from the question >of value OR reference) has ever had a documented answer. It has been >discussed (at least in Paris, I'm not sure if it was discussed since), >but where is the answer ? > >I raised it as a documentation question precisely because I don't want >force revisitation if the answer is in fact already well known to most >of the TC. > >Peter > >-----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 <mailto:mark.little@arjuna.com> Little ; 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]