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