OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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