RE: [ws-caf] [Bug 135] New: participating-services list needs to have defined semantics and modification mechanisms or be removed

[Mark Little <Mark.Little@arjuna.com>]

<humour-impaired>
I figured it was a joke.
</humour-impaired>

;-)

Mark.

>===== Original Message From "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
>> >> >
>> >>
>>
>>
>>