OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[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]