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 notion of having a context structure that is extensible isn't new by
any means and has precedent elsewhere. I agree with Greg (no surprise I hear you
say) that from a syntactic perspective the idea of a base context structure that
users can augment makes a lot of sense. And this is not about coping with a
broken SOAP header model as you made out in a previous email; I can convey a lot
of other information in the SOAP header that is not context. What I'm after is a
way of clearly marking up relevant (related) context information in such a
manner that I can have services that announce they can deal with Base-context or
Augmented-context (for example). Although I could do this all in a derived
specification or implementation, I'd have to do it every time I needed it and in
an ad hoc manner. What we are defining in WS-Context is a standard
representation for this information so that it (the basic context and its rules)
only need be defined once and referencing specifications need define only deltas
to this structure.
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.
Or put more accurately: an activity
is a set of related operations and the context is the physical representation of
that activity; a service receiving a context knows it is within a specific
activity.
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.
This ignores the basic notion of
activities as structuring mechanisms for composing Web services applications.
Maybe you're looking for a different specification? It's certainly not the one
that was mentioned in the charter though.
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)
FYI the issue about nesting of contexts was closed at New
Orleans.
Mark.
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.
I mention this because a satisfying 3 (which is a
reflection of 1) is made both simple and intuitive by the existence of 2.
While we could imagine using an arbitrary SOAP Header in lieu of a context,
it seems to me that we would wind up having to add most of the same
"generic" elements to each of these new headers. At which point clever
implementers would probably generate a parent or container type, ie, would
have to recreate the context structure on an ad hoc
basis.
Greg
Furniss, Peter wrote:
Jim,
<snip>
I think I see what you're saying - why bother wrapping, say,
a WS-LRA context inside a WS-Context context when you could
just put the WS-LRA context into a SOAP header directly. If
that's what you mean then I think it's a reasonable point.
Yes, that's the precisely the point. I originally raised it in Paris,
where most of the counter
argument seemed to be somewhat spurious - amounting to "implementations
today have difficulty doing/don't
do X (even though X is covered in the specifications they do purport to
implement), and WS-Context-by-value offers assitance/an alternative" But
since implmentations would need to be changed to do WS-Context-by-value,
they can surely be changed to the already-specifed X in any case.
However, for some of the work I'm doing now, just having a
plain vanilla context is really quite useful.
So: would it be correct of me to split your argument into to points?
1. There is little perceived value in using the context
structure to house other contexts. 2. There is little value
in WS-Context.
For the first, the specs (used to) say that higher level
contexts dervied from lower level contexts rather than being
bundled inside them. That might have changed now (editors?)
since pretty much no-one gets substitutionGroups (or so it
would seem from the appalling support for them).
I believe the changes in New Orleans mean that a context is monolithic -
a context covering security+transactions is defined as such and has no
derivation or containment of the security and transactions contexts
(though obviously it might well incorporate some of the same elements in
its xsd:any element.
So I think that means the higher level contexts are "derived" directly
from the WS-Context context. Whether the derivation is syntactic is
another matter.
For the second I respectifully disagree. In my work I have an
"application X" context which ties together a bunch of
services which for me comprise "application X".
So what features of WS-Context are vital to your use that save you
writing them in the specification of your particular use of ws-context ?
Thought experiment: You must have some definition of what your
context-type URI means. You probably have some types that go in the
xsd:any element. You possibly have some operations that are implemented
by the same entity as supports the ContextService and ContextManager.
Suppose you defined the types that go in the xsd:any as soap headers in
their own right. You can use the context-type URI as the namespace uri.
All the rest of the specification is the same. What have you now got to
add that specification that you currently do by reference to WS-Context
? That's the only aspect of WS-Context that justifies its use for your
case.
Does your current specification put constraints on the WS-Context
implmentation ? Would it work with an independent WS-Context
implementation ? (are the identifiers truly opaque, for example)
Peter