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

[Doug Bunting <Doug.Bunting@Sun.COM>]

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