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

Yes, of course. I was teasing Eric.  There is a smiley in my message.

In fact, I wasn't quite sure whether Eric's suggestions about not
copying the context
referred only to the participating-services-list or covered the use of
contexts in 
general. Some of the peculiarities of behaviour I described in my first
message, for the
by-value case, are the inevitable consequences of by-value propagation,
and apply to 
other fields as well. To object to these is to object to by-value. 

However, since these peculiarities are pretty much what
transaction-contexts want
(unsurprising, since tx contexts
have been propagated by value for at least 20 years), by-value is
appropriate there.

I wasn't going to propose dropping by-value again, but if Eric wanted to
...   :-) [JOKE !!!]

However, I would still very much like to see a worked-out example of an
application that would 
interoperably switch between by-value and by-reference, with precise
statements of 
the behaviour required of the parties in various circumstances. I
continue to doubt
the viability of such a beast. Perhaps other members of the TC are just
bursting
with such examples that are fully worked-out but they can't divulge for
confidentiality
reasons. But until someone shows me one, I will suspect it is a mythical
animal. (In fact,
there is a name for it - a chimaera, a lion-goat-snake mixture.)

Peter

> -----Original Message-----
> From: Mark Little [mailto:Mark.Little@arjuna.com] 
> Sent: 27 June 2004 19:25
> To: Furniss, Peter; 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
> 
> 
> Peter, I think you were joking, but: there is no such 
> proposal on the table 
> for abolishing context-by-value. This has been discussed 
> several times over 
> the lifetime of this TC (at face-to-face meetings and in 
> teleconferences) and 
> each time it has been agreed to support both the reference 
> and value form. 
> That decision has been made. We now need to move on to other issues.
> 
> Mark.
> 
> >===== Original Message From "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
> >> >
> >>
> 
> 
>