RE: [ws-caf] Nested contexts ( was RE: [ws-caf] Mt Everest and WS-CF)

["Newcomer, Eric" <Eric.Newcomer@iona.com>]

Peter,

Again, I think that we have had sufficient general discussion on this topic.  Please submit any further issues in the form of a change request, citing specific text, with specific proposed new text, and reasons for it.

We are obviously not making progress this way.  The point about implementation is pertinent to the weight of concerns expressed by representatives of a single company, representing only a single potential implementation (with no intention given to implementing WS-CAF), and we must as responsible TC members weigh the importance of concerns around a spec at this stage in the context of those who intend to implement.  

Thanks for your understanding and cooperation.

Eric

-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
Sent: Saturday, May 29, 2004 8:04 PM
To: Newcomer, Eric; Doug Bunting; ws-caf
Subject: RE: [ws-caf] Nested contexts ( was RE: [ws-caf] Mt Everest and
WS-CF)


Eric,

My comment on nesting seems to have been rather misunderstood. In
summary:

i) the semantics of nesting, and the basic context services ability to
manipulate it are under-specified

ii) I don't think the specification of those that we have at present
does what nested and interposed transactions need.

I didn't mean to suggest that context propagation or nesting was
exclusively for transactions contexts.

It may be that nested transactions won't in fact use the nested context
support that is in ws-context, but that it is suited to other uses
(perhaps on the lines Doug suggested) with completely contrary nesting
requirements to nested and interposed transctions.  But I am sure the
spec needs clarifying in this area, hence the a to d of my earlier
message.

Other comments interleaved:


> -----Original Message-----
> From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
> Sent: 29 May 2004 15:34
> To: Doug Bunting; ws-caf
> Subject: RE: [ws-caf] Nested contexts ( was RE: [ws-caf] Mt 
> Everest and WS-CF)
> 
> 
> The use of contaxt in distributed systems is much broader 
> than transaction context propagation, although transaction 
> context tends to be the "top of the food chain" or top-level concept.
> 
> However, as we've said many times in F2F and email 
> discussions, many types of context exist in the execution 
> environments of distributed systems.  Since Web services can 
> be mapped to any execution environment, and are useful for a 
> very broad range of applications, it seems appropriate to 
> similarly broaden the concept and useful scope of shared context.
> 
> The debate over context-by-value vs context-by-reference is 
> entirely a red herring.  Preserving both options is sensible 
> for broad implementation applicability since in Web services 
> we are not trying to constrain specifications to any 
> particular execution environment, and preserving these 
> options is helpful rather than detrimental.  Despite what we 
> continually hear as concerns from the representatives of one 
> of these potential execution environments, representatives of 

you have perplexed me utterly with this. I wasn't very sure, but I
thought "execution environment" in the sense you use it meant "running
system", or, in a more static sense (as earlier in this paragraph)
"platform and language environment". Do you think my arguments about
value and reference relate to implementation considerations ? They
relate to getting clarity in what is supposed to be in interoperable set
of protocols that (by that definition) involve multiple execution
environments. And making it likely that multiple, independent
configuration of those execution environments by end users is tolerably
easy. Which again requires clarity, and benefits from re-use of existing
functionality rather than re-invention of the same functionality in a
different place.

> every other exeuction environment involved in the TC are in 
> favor of preserving both options, which to me simply proves 
> the point that preserving the options is necessary.

Our different execution environments are unimaginably irrelevant to the
considerations. We are defining protocols that run between systems - the
implementation of any of these choices, once clearly defined, is fairly
easy. The necessity of the options is to be determined by whether they
provide distinguishable functionality that is not available to
interoperating systems using the existing web-services specifications,
or which would require repeated implementation in specific applications.
(I agree entirely with Jim Webber's motivations on this about standards
- just I think he is fooling himself on the particulars)

> The debate here about "consuming specifications" seems to me 
> to represent another concern of fairly limited scope, or I 
> should say a concern around limiting the scope of the 
> specification to a single execution environment or set of 
> concepts.  The business of Web services specifications is to 
> open up possibilities not constrain them.

I'm not sure where "consuming specifications" came from - I assume this
is the same as "referencing specifications".
If so, you seem to have misunderstood what I meant it to mean when I
suggested it in issue 64.

As mentioned on another thread, I assert that WS-Context alone is not
useful. Two users, each with WS implementations that implement
WS-Context alone - the service can advertise its support in its WSDL,
the client's software can recognise that - would gain no benefit from
the WS-Context support without some shared knowledge of what the
implications of the context were. (whereas if the implementations
supported WS-TXM LRT, say, they would - but that would be additional to
WS-Context). That shared knowledge is what is meant by the "referencing
specification".  In the demo app, Simeon's document is (or contains) the
"referencing specification". With WS-TXM LRT, it would be the other
WS-CAF specs (assuming they keep their present relationships).
Sometimes, it will be considered to the application - but it is shared
knowledge between the parties, so it is the specification that each end
must abide by, however formal or informal the "specification" is.  It
would be misleading to think of it as the implementation, since with an
interoperable specification, that is usually conceived of as just one
side.

So referencing specification is exactly NOT limiting to a single
execution environment.  It may be that a better term is needed.

Hope this hasn't gone off the deep-end. I am trying to make WS-Context
an openly interoperable specification that states what implementations
must do to implement it and states what it provides to other
specifications and users accurately.

Peter

> We could assume, for example, that every Web service 
> invocation is expressible using the Doc/literal style, which 
> allows the loosest possible interpretation of a Web services 
> message, very similar to REST principles in fact.  I think we 
> need to be sure we can support this interaction style equally 
> well, if not better, than the RPC-oriented style.
> 
> The need to manage context therefore has a similarly very 
> wide scope.  The more abstract the interaction -- and 
> doc/literal is more abstract than rpc/literal for example -- 
> the greater the need to set up and manage execution 
> environment context.  In a mixed world of doc/literal and 
> rpc/literal implementions it should be very clear that one 
> size cannot fit all and we need the inherent flexibility of 
> an extensible context structure.
>
> Eric
> 
> -----Original Message-----
> From: Doug Bunting [mailto:Doug.Bunting@Sun.COM]
> Sent: Friday, May 28, 2004 4:48 PM
> To: ws-caf
> Subject: Re: [ws-caf] Nested contexts ( was RE: [ws-caf] Mt 
> Everest and
> WS-CF)
> 
> 
> Peter,
> 
> I  have  a slightly  different  perspective  that  only 
> sometimes  involves transactions in  the "shared outcome 
> decision and  distributed knowledge of that outcome" sense.  
> When I  think of linked contexts, I consider multiple 
> activities that coincide  with a particular message to  form 
> a nested stack of contexts applicable to that  message.  I 
> guess nesting and interposition of  transactions  (with 
> varying  time  spans I  would  assume)  might be  a derivative case.
> 
> The (generic?) use case I am thinking of involves a message
> - sent securely (referring to an earlier authentication event),
> - within a transaction  (lasting longer  than the  secure 
> session  in this case),
> - as part  of an identified instance of  a known choreography 
> (effectively, two activities  with the instance having  a 
> much shorter  lifetime than the description of the choreography),
> -  driven  by  SLA terms  and  other  machine  and  / or  
> humanly  readable information about the larger contract 
> between the enterprises involved (and legal documents are not 
> small ;),
> - sent by / to / about a specific enterprise whose physical 
> characteristics (shipping locations, for example) and other 
> information is available to all parties,
> - et cetera (until the context describes the universe).
> 
> The list above is not intended to be at all exhaustive or to 
> imply that all messages require  everything listed.  It  must 
> remain an  implementation or overall  distributed application 
>  choice  how much  of  the hierarchy  gets mentioned 
> (transitively in some cases) when sending a particular message.
> 
> How  I   represent  this   stack  of  related   contexts  is  
>  probably  an
> implementation choice  at the moment.  If  I am correct (and  
> using the old draft as a guide), the current specification 
> makes no recommendations about how often to use the  child 
> pointers or whether multiple WS-Context headers
> should  appear in  the  same message.   Contexts  with 
> different  lifetimes
> (including multiple  contexts with varying senses of  an 
> infinite lifetime) could reasonably  be all  linked into one  
> (nested, hierarchical,  at least
> unified)  list, could  be  sent  as multiple  WS-Context  
> headers (one  per
> context) or everything in between.   Are you making a 
> recommendation on way
> or the other or asking for this type of clarification in the 
> documentation?
> Alternatively,  are  you  suggesting   that  everything  
> except  nested  or
> interposed transactions must be handled using separate 
> WS-Context headers?
> 
> Should mention  that my  leaning is toward  a single 
> WS-Context  header per message.  This might  imply a receiver 
> need understand  only WS-Context and the  semantics  of  the  
> top  level  (outermost,  shortest  lived)  context
> mentioned  in that  message.   The WS-Context  and dependent  
> specification
> propagation rules should mean anything above the level they 
> understand gets carried along for the ride.
> 
> Does this align with your thinking?  From what I have seen 
> (and, no, I have not  seen the  
> soon-to-be-available-we-all-hope editors  draft), WS-Context 
> supports either type of linking  (syntactic nesting or 
> carrying in parallel
> with  overlapping  lifetimes)  directly.    The  main  issue  
> seems  to  be
> clarifying  the  choices mentioned  above  so  that  all of  
> the  dependent specifications  do not  need to  describe how  
> they relate  to  every other context type.
> 
> thanx,
> 	doug
> 
> On 28-May-04 06:08, Furniss, Peter wrote:
> ...
> 
> > The most-known use case for nested contexts is, I believe, 
> the nesting 
> > and interposition in transactions. Does that use really want to 
> > propagate the entire ancestral (and colateral ?) tree ? Other 
> > transaction protocols tend only to propagate the identifiers of the 
> > immediate line. The present WS-Context nesting capabilities 
> don't seem 
> > to be well-aligned with that need.
> > 
> > Peter
> 
>