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

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

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 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.

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.

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