split
as a distinguishing subject. The useful subthreads (if it is considered there
are any) can come together again later.
Does
it mean anything for a service receiving a context to know it is within a
specific activity in the absence of knowledge of what that activity is about
?
What
would it mean for a service to announce that it can deal with Base-context alone
? (this was the thrust of my a, b, c implementation examples in another
message). I think it just means it won't choke if it gets a ws-context header,
but doesn't actually do anything with it.
I
agree an activity is a concept that can be applied to sets of operation
invocations that share some behaviour or information (such as using the
same user identiifcation, say). And then one can see that there are many
different kinds of activity for different purposes. And that for most or
all kinds of activity the involved services pass some information around
reflecting and supporting their involvement in the activity, which can be
considered a context. But that's a descriptive concept, not a prescriptive one.
It doesn't of itself indicate there is any need for a common base protocol - the
need for that is a matter of finding the facilities that are common to many
activiites.
I'm
perhaps just recapitulating the thoughts everyone else had before ws-context
started, because of course once you've defined what's in the base protocol, one
could consider implementing that as a framework that real activities could use.
So I'm sorry if I'm being slow. But actually I think the story is being
presented backwards. There is no such thing as a base activity and no use in a
base context.
Peter
I
-----Original
Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: 28 May 2004 10:36
To: Furniss, Peter; Greg
Pavlik
Cc: Jim Webber; ws-caf
Subject: Re: [ws-caf] Mt
Everest and WS-CF
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