[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] [Bug 135] New: participating-services list needs to have defined semantics and modification mechanisms or be removed
No, it isn't. It's an idea for a very simply "referencing specification" that uses the context by reference feature. It doesn't go so far as to suppose that other referencing specifications don't need context by value. But I would be very glad to work with you on this idea in any case, if you're up for it? -----Original Message----- From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] Sent: Saturday, June 26, 2004 9:43 AM 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 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]