[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
ok, but we need to sort out the original question - is the participating-services element fully defined in ws-context, or in another specification. I wasn't sure if your suggestions were referring to context as whole, or context-by-reference as whole, or just to the p-s list. On the p-s list, are we agreeing a) the p-s list is meaningless without additional specification on how it is maintained b) this additional specification is not part of base ws-context document c) therefore the p-s list element should not be in the base context syntax as defined in the schema and possibly d) the p-s list is only useful with context-by-reference I don't think it would be difficult to work up a sound specification to define how the p-s list is maintained with context-by-reference. It would be helpful to have a known use-case, if only to put some sort of boundaries on things. (I was about to include something on this, but I'll make that a separate thread) Or were your suggestions covering context by reference in general, rather than just the p-s list ? That would seem to relate to issue 91 - I'm not sure what the status of that really is, and the text I think is meant to cover it in section 2 is still a bit vague, so I'd be interested clarification there. Peter > -----Original Message----- > From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] > Sent: 26 June 2004 17:36 > 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 > > > 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]