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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Doug,

Those are nice examples - and perhaps useful for testing what the common
functionality is, to persuade me of the usefulness of ws-context :-)

My understanding of the post New Orleans nesting/structuring rules are
that a WS-Context context has a single purpose. This this may contain
multiple defined sub-purposes (e.g. the security+transactions case) but
would not be a hold-all for independent purposes. (c.f. SOAP:Headers,
which definitely is a hold-all)

That would imply that your message would have a several SOAP header
elements that were ws-context contexts, each with different type uri.
(for some, pass-by-value looks wise, for other pass-by-reference)

I had assumed as an axiom that if contexts were nested in each other it
would have some semantic implication, although what that implication was
would depend on the specification identified by the context type.  I
guess it would be possible to have a context type that was "hold-all"
and which stated that any arbitrary context could be nested in it, and
it imposed no additional semantic on the child-contexts. But that would
seem odd. And un-necessary, as *that* context would certainly add
nothing to soap header element, regardless of the general case.

But I think you are suggesting an outer context that does have some
meaning, although it contains a rag-bag - precisely that it identifies
the rag-bag. However, I don't think the context service currently
supports this. I presume some of the child-contexts are passed by
reference in an outer context that is passed by value - (at least some
of the time) - if it is intended to be able to do this, we need to say
so. And that would only work if we can de-reference a child-context.
And in this case we definitely want the context service to supply us
with a parent that contains several children (since the combination has
a shorter lifetime than at least some of its components, I think).  Were
you expecting this use to be largely covered by the basic ws-context
specification ?  Because there needs to be a lot more text somewhere, I
think.

With just separate contexts, each in their own header, you don't get any
identity of the set, but I'm not sure you'd need it much.
 

Peter

> -----Original Message-----
> From: Doug Bunting [mailto:Doug.Bunting@Sun.COM] 
> Sent: 28 May 2004 21:48
> 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
> 
>