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

["Newcomer, Eric" <Eric.Newcomer@iona.com>]

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