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

["Green, Alastair J." <Alastair.Green@choreology.com>]

Keeping it loose, and opening up possibilities, is all very well. But
specifications have to be tight: more equals redundancy equals
ambiguity. Paradoxically, the more you assume the more you restrict. The
whole drive of comments from this "execution environment" has been:
Occam's razor. Don't multiply the necessary. Simplify, pare it down, get
to that which is essential, general. And I think that has been the
direction since Paris.

I have certainly never thought of this discussion as solely stemming
from the case of transaction protocols. I fully accept that there are
all manner of communities, activities, trees, collections, sessions and
so forth that have some shared identity, or information associated with
a shared identity. 

Every utilization of context ever suggested is (has to be) an expression
of a protocol (a consuming or referencing specification). The protocol
may not be written down, it may be assumed to be intuitively obvious
(i.e. cultural), but it is still a protocol. If we agree that contexts
of type foo contain a value that is the database open string for a group
of services, then that is a protocol: on reception of a context of type
foo, take the value and insert it into your database initialization
routine. If you do this then you will share a resource; if you violate
this protocol then you will not share a resource. Jim's correlation by
URI is a protocol. Etc, etc.

The question here is: what do I get out of WS-Context that will save me
appreciable work by comparison with an application's own specification
and implementation of its interoperable use of contextual information? 

The statement that a multifarious world demands extensibility is
argument by assertion. What is the basic functionality that is common,
such that it should be extracted into a generic interoperable protocol,
which can then be extended? Another way of dealing with
multifariousness, is plurality. Lots of applications, lots of
communities: lots of specific context mechanisms.

Suggestions to justify a generic approach have included:

a globally unique id service (get_uuid() by SOAP)
a general interoperable factory interface
a (very heavily underspecified) way of holding a piece of data in a
central repository so that many can read it and write it (REST by SOAP)
a base class for understand and propagate attributes

I think that you can't sell a spec to an over-spec'd world without
stringently arguing the worth. 

By-value and by-reference: it's not a red herring. Once again: is there
worth in by-value, is there worth in by-reference? The two approaches
are not necessarily tied together: their tandem worth seems to be
assumed, but once again has to be justified, argued, explained.

Doc/literal vs RPC seems to me to truly a red herring. How can a choice
of approach to context (base + extension, monolithic) affect independent
choices of that kind? Utilizations of the notion of context can do that
(e.g. "contexts of type Broohahah must never be sent by RPC" or some
more sensible protocol rule), but the way the context is created and
built cannot have any effect on rules of use.

Alastair

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