[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] Mt Everest and WS-CF
Greg,
I
agree the conclusion of your message, but I've yet to see strong evidence of
getting to it. I've been trying to press the question of using a specific
(arbitrary if you like) SOAP Header, and then see what the generic elements are.
Anything there aren't multiple uses for should then be left to the specific
referencing spec, leaving the base context with what it should have. I suspect
by then you are left with very little.
the activity:context relation is sort of self-defining - an
activity is a set of operation invocatins that are scoped by a context that is
shared among the operation invocations in the activity that it
scopes.
The
only things that really seem to be general are the identifier and the
context-type. So, there is a pattern of putting an identifier in a soap header
with a uri that states what the identifier (and anything else in the header) are
about. And all invocations with that identifier can be deemed to be part of
a single "activity" if that helps. Since headers already contain a URI for their
namespace, and getting an identifier is scarcely a big deal, I don't see the
need for the indirection.
The
web service interfaces to demarcate and control the lifecycle seem doubtful as
well. For context uses that have a central point (like coordination), there has
to be a whole lot of other stuff in the central point anyway - to do
registration etc. So we've only got some elements of the interface in ws-context
for many uses. And other uses don't need a separate web-service interface anyway
- i.e. if there is no registration from "participants", there is no way to tell
them the completion or results of the activity, so there is no point in
delegating that control. If there is registration and a completion fan-out etc.
then we've got a whole lot of extra protocol anyway and the little we started
with in ws-context isn't very significant.
The
other stuff in context:
timeout - imaginably useful, but handleable as pattern for
uses that need it
activity-service (dereferecable uri) - only useful if it is
actually the url of some higher level service (i.e. same address for some other
port-type) or for dereferencing the by-reference form (which I can imagine some
use for, by the way, and which I still don't think is sufficiently distinguished
on the wire).
participating-services - how is this lot built up ? some
sort of registration exchange presumably. so it belongs with the protocols that
do that
child-contexts - (i think we have an issue challenging
these) - I beleive the only known uses are coordination/nested
transactions/subtransactions, which actually need something different
(parent-contexts might be useful)
Peter
-----Original Message-----
From: Greg Pavlik [mailto:greg.pavlik@oracle.com] Sent: 27 May 2004 14:26 To: Furniss, Peter Cc: Jim Webber; ws-caf Subject: Re: [ws-caf] Mt Everest and WS-CF Peter, a minor comment: the WS-Context specification defines a number of things. An incomplete list includes: 1) it introduces the notion of an activity, which is understood to be a scoping mechanism for some set of web service operation invocations 2) it introduces a (basic) context structure that communicates to participants that they are in fact being asked to execute in the context of an activity and 3) it introduces web services interfaces that allow applications to demarcate and control the lifecycle events of an activity. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]