RE: [ws-caf] [Bug 135] New: participating-services list needs to have defined semantics and modification mechanisms or be removed

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

That seems to be a proposal to abolish context-by-value and use
context-by-reference only.

I might support that :-)

Peter

> -----Original Message-----
> From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
> Sent: 26 June 2004 13:46
> To: Furniss, Peter; ws-caf@lists.oasis-open.org
> Subject: RE: [ws-caf] [Bug 135] New: participating-services 
> list needs to have defined semantics and modification 
> mechanisms or be removed
> 
> 
> I guess we are going to need some discussion on this, or at 
> least a proposal to review.  What I was talking about 
> eliminates the need for copying the context, it would become 
> a Web resource instead.
> 
> -----Original Message-----
> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> Sent: Friday, June 25, 2004 7:06 PM
> To: Newcomer, Eric; ws-caf@lists.oasis-open.org
> Subject: RE: [ws-caf] [Bug 135] New: participating-services 
> list needs to have defined semantics and modification 
> mechanisms or be removed
> 
> 
> Eric,
> 
> I don't entirely understand what you are suggesting. Some of 
> this seems to be suggesting an alternative to the Context 
> Service and Context Manager interfaces that are currently in 
> the spec, which I doubt is your meaning. What is a 
> context-by-reference other than "a Web resource accessible by all 
> participants".
> 
> But concerning the participating-services list specifically, 
> the protocol used in the by-reference case is a secondary 
> matter - I suggested an extension to Context Manager because 
> we were using wsdl & soap mechanisms for other 
> interactions, although one could use get and put there as 
> well (though then has to be some specification of exactly 
> what url to use for what). But, as I 
> say, that is secondary.
> 
> The primary question is how the "epistomology" of the 
> participating-services list works - how is information 
> accumulated in various copies of the context, and who has 
> responsibility for causing an update to the list (regardless 
> of the particular distribution mechanisms used to achieve 
> that update). On this, you raise the point of 
> persistence/non-persistence which I hadn't considered
> - 
> possibly that's orthogonal to the participation list - if a 
> holder of a copy of the context loses it, then that copy 
> goes, along with any information that was held in that copy 
> and nowhere else.
> 
> If a participating services list in *any* copy of a context 
> is to have any clear meaning, there needs to be explicit 
> statement of the mechanisms that get the information into the copy.
> 
> So, could you propose text defining what the mechanisms are - 
> who MUST or MAY send GET, PUT or POST to which uri (i.e. 
> where it got the uri from) and in 
> response to which events ?
> 
> That would still leave the choices A-E that I had - where is 
> that specified put and when is it required.  And if the 
> answer is D - it is specified in 
> a referencing specification, we can wait till we have a use 
> case that needs it (thus helping work out what is actually 
> needed - and you don't need to work it out now), and omit the 
> field from the base context.
> 
> 
> Peter
> 
> > -----Original Message-----
> > From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
> > Sent: 25 June 2004 17:29
> > To: Furniss, Peter; ws-caf@lists.oasis-open.org
> > Subject: RE: [ws-caf] [Bug 135] New: participating-services 
> > list needs to have defined semantics and modification 
> > mechanisms or be removed
> > 
> > 
> > Peter,
> > 
> > Actually I'd prefer a description of this a bit the other way
> > around, i.e. define the sharing as a Web resource accessible 
> > by all participants rather than try to define rules for 
> > copying and sharing by value. 
> > 
> > A minimal protocol for me would be along the lines of REST
> > instead of the old RPC oriented style of copy-in, copy-out 
> > since we probably can't assume the use of persistent sessions 
> > at the minimal Web services implementation level.  Once we 
> > get to coordinators and other "referencing specifications" I 
> > think it's more reasonable to assume the possibility of the 
> > manipulation of data by the implementation. 
> > 
> > At the simplest level I think I'd want to propose a protocol
> > based on URI passing and the concept of a shared Web resource 
> > context that eveyone can access (i.e. via standard GET and 
> > PUT operations) rather than try to work out semantics of 
> > passing the context structure around among the various 
> > implementation agents involved.
> > 
> > Once you have the agents anyway (i.e. coordinators) I think
> > the data passing protocol would make more sense.  But for the 
> > bare context spec, and a minimal usage of the mechanism, I 
> > think the REST oriented shareable Web resource approach makes 
> > more sense.
> > 
> > Eric
> > 
> > -----Original Message-----
> > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> > Sent: Friday, June 25, 2004 12:05 PM
> > To: ws-caf@lists.oasis-open.org
> > Subject: RE: [ws-caf] [Bug 135] New: participating-services
> > list needs to have defined semantics and modification 
> > mechanisms or be removed
> > 
> > 
> > There is a need for clarification on the meaning of the
> > participating-services list in the context. This message 
> > attempts to provide text towards that, but ends up concluding 
> > it shouldn't be in the base context spec.
> > 
> > I believe the only explanation at present is:
> > 
> > "An optional list of the Web services currently participating
> > in the activity, called participating-services." 
> > 
> > For this to be useful in any particular use of ws-context a
> > considerable amount of additional specification would be 
> > needed. Since it is a field in an interoperable protocol, the 
> > definition of what it means has to be defined in the 
> > protocol, and since it concerns distributed information, the 
> > semantic definition will impose behavioural requirements on 
> > the implementations taking part. In the absence of clearly 
> > defined responsibilities on the context manager, on the 
> > systems invoking Web services to which they pass the context, 
> > and on Web services receiving the context the contents of the 
> > list will have no meaning, and no reliance can be put on the 
> > presence or absence of an entry in the list. The following is 
> > an attempt to provide, or outline, this additional 
> > specification. There are then questions of placement - where 
> > such text goes and under what circumstances implementations 
> > are required to follow the procedures defined.
> > 
> > The specification text here is not complete, but should make
> > it clear what would be needed to complete it. In some cases 
> > there are specification-time choices of action 
> > - these are shown as [ one way | another way]. Explanations 
> > are put in Notes - these might or might not end up in the 
> > specification text.
> > 
> > The behaviour required to enforce the semantics have to be
> > completely different depending on whether the context is 
> > propagated by value (and evolves into divergent forms) or by 
> > reference (and is owned by the context manager). In 
> > consequence, the meaning of the list is different too.
> > 
> > The elements of the list are assumed to be URI's, as in 0.3,
> > but they probably ought to be service-references.
> > 
> > 
> > When a context is created the participating-services list MAY
> > be omitted, but if present it MUST be empty. 
> > 
> > With propagation by value:
> > 
> > Assumption: application entities (web service users and web
> > services) retain a copy of a context which is used when the 
> > context is propagated on to other web services. (In practice 
> > an "entity" is defined by the possession of a single copy of 
> > the context.)
> > 
> > An entity that propagates a context to a Web service MUST add
> > the URI it is using to access that Web service to its own 
> > copy of the context prior to sending the context to that Web 
> > service, unless that URI is already in the list. A Web 
> > service that receives a context MUST retain all members of 
> > the participating-services list in its own copy of the 
> > context (this will include its own URI as used by the entity 
> > propagating the context to it). An entity MAY add URI's for 
> > Web services to the participating-services list of its copy 
> > in advance of any attempt to propagate to that Web service.
> > 
> > Note -- the nature of propagation by value will mean the list
> > of participating-services present in any particular copy will 
> > always include the immediate ancestors in the propagation 
> > path from the first web service that received the context 
> > (but not the entity that issued begin to the Context 
> > service). It may include "lateral relations" - siblings of 
> > itself or of an immediate ancestor if these were invoked 
> > before the direct line, or the URI was known and added to the 
> > context before the invocation in the direct line.  It will 
> > not include services that were involved in the activity by 
> > ancestors after the context was propagated on the direct line, or 
> > any that were involved from non-ancestors -- endnote
> > 
> > 
> > [possible additional rule:   If a context a received by a Web 
> > service is
> > found to
> > have the same context identifier as an already known and
> > retained context, the participating-services lists MUST be 
> > merged and only one copy of the context retained. ]
> > 
> > 
> > Note -- it is difficult to see how any useful interpretation
> > of "currently" in the definition quoted above can be achieved 
> > with propagation by value. It appears to imply that a service 
> > ceases to be "currently participating" at some point and is 
> > removed from the list. The only generally definable point 
> > would be when the web service returns or replies to the 
> > message that carried the propagating context. But this won't 
> > necessarily be well defined in the case of "asynchronous" 
> > replies. A clear definition could be achieved by having an 
> > anti-context
> > (context-reply) element that could be put in the header of a 
> > reply message, indicating that the replying web service had 
> > completed its participation, - if this existed there would be 
> > extra text explaining that a web service uri was removed from 
> > the list when the context-reply was received. (actually it 
> > needs to count out the propagations to that web service and 
> > count back the replies, removing the uri only when the in use 
> > count falls to zero.
> > 
> > Even if this were done, what use the list would then have on
> > a propagated context ? It would tell the receiving web 
> > service which other webservices were participating at the 
> > point of propagation, but this list would be invalidated by 
> > the replies from other sibling services.
> > -- endnote
> > 
> >  
> > With propagation by reference:
> > 
> > In this case the context is maintained and held by the
> > context manager, rather than by the application entities. 
> > Since the context  manager is a "public" service, there need 
> > to be additional web service operations on the context 
> > manager to manipulate the participating services list. The 
> > could either be added to the context manager port type, or an 
> > additional port type could be specified. If the latter, then 
> > either it must be defined that the context manager port whose 
> > url is in the context must implement both port-types, or the 
> > context (when carried by reference) must carry an address 
> > (url) for the port implementing the 
> > participation-list-manager port type. Since the context is 
> > kept "behind" the context manager port, there seems little 
> > point in having a separate port for the 
> > participation-list-manager operation(s)
> >  
> > The required operation of the participation-list-manager 
> interface is
> > 	addParticipantService, with parameters of the context
> > identification and
> >  		a url (service-reference ?). A (context/p-list) 
> > manager implementation MUST
> > 		add the URI to the participant-list for the 
> > identified context, unless
> > 		it is already there. Errors will be similar to 
> > those for context manager's 
> > 		contentsSet operation.
> >  	
> >  	
> > The behaviour of an implementation receiving a context MUST
> > be in accordance with the following:  
> > 
> > [EITHER:
> >  Prior to invoking a webservice, an entity that propagates a
> > context to a Web service MUST invoke addParticipantService on 
> > the context manager identified in context, passing the URI of 
> > the service to be invoked. 
> > |OR
> >  On receipt of a WS-context in a header, a Web service must
> > invoke  addParticipantService on the context manager 
> > identified in the  context, passing its own URI. ]
> > 
> > Note -- again there is a need for removal of elements from
> > the list if "currently participating" is to be implemented. 
> > This would require another operation on the 
> > participating-services-manager or the base context manager. 
> > The question of how to determine that a service has ceased to 
> > be participating applies as for by-value.
> > 
> > Ignoring the "currently" participating/removal question, the
> > list does seem to have some clear meaning when the context is 
> > passed by reference. Whether this has any use is another 
> > question. end rules
> > 
> > ---
> > 
> > the choices for where the specification of updating the
> > participating-services list is placed, and when the behaviour 
> > is required of implementations would seem to be:
> > 
> > A  it is included in the ws-ctx spec, and mandatory for all
> > implementations of and for all uses of ws-context. The 
> > actions required of a receiver of a context are thus the 
> > substance of "mustUnderstand=true" - if you don't do them, 
> > you must fault. The participating-services list MUST be 
> > present unless it would be empty.
> > 	
> > B  it is included in the ws-ctx spec, and a referencing
> > specification that defines context type states whether they 
> > are required (similar rules about mustUnderstand (though this 
> > is the sort of thing that might cause us to keep the ws-ctx 
> > mustUnderstand as well as the soap one)). A context with a 
> > context type that does not require these procedures MUST not 
> > include the participating-services list.
> > 	
> > C  it is included in the ws-ctx spec, but it is up to an
> > implementation whether it does it, unconstrained by any 
> > mutually known specification
> > 	
> > D  it is included in a referencing specification that defines
> > a context type, and required of implementations that 
> > implement/claim to understand that type
> > 
> > E  it is just vaguely understood and implementations can do
> > it if they want
> > 
> > 
> > this categorization ignores the difference between procedures
> > for by-reference and by-value
> > 
> > --
> > E is clearly absurd, and included only because that appears
> > to be the current position :-)
> > 
> > C is equally absurd, as it is effectively the same as E, and
> > means there is no well-defined semantics of what the 
> > participating-service list is
> > 
> > B means we really have a sort of "functional unit" in
> > ws-context - there are ws-context uses with and without 
> > participating-services. Implementations might choose to 
> > implement these mechanisms or not, and would need to state 
> > whether they did. Implementations that did not could not 
> > support a referencing specification that required use of it.
> > 
> > A is coherent, but would seem a nuisance for uses that didn't
> > take advantage of the participating-services list.
> > 
> > D - Leaving the definition of the mechanism and semantics to
> > the referencing specification has the advantage of avoiding 
> > the ambiguities and confusions of the alternative mechanisms. 
> > (especially if the ref. spec. mandates by-value or by-reference
> > exclusively)
> > 
> > However, if the use and thus semantics of the list are
> > defined in a referencing specification, the 
> > participating-services list should not be defined in the 
> > base context, but should be part of the extension to context 
> > made by such a referencing specification. 
> > 
> > ---
> > 
> > In the light of this, I propose that solution D is adopted,
> > and the participating-services list is removed from the 
> > context definition in the base spec.
> > 
> > Peter
> > 
>