[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] Nested contexts ( was RE: [ws-caf] Mt Everest and WS-CF)
Alistair, Could you please reformat this as a proposal for specific text changes? Thanks, Eric -----Original Message----- From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] Sent: Thursday, June 03, 2004 2:16 PM To: Newcomer, Eric; Doug Bunting; ws-caf Subject: RE: [ws-caf] Nested contexts ( was RE: [ws-caf] Mt Everest and WS-CF) 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]