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

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
>