Re: [ws-caf] Re: activities (was RE: [ws-caf] Mt Everest and WS-CF)

["Mark Little" <mark.little@arjuna.com>]

I don't know. You take a weekend off and come back to a plethora of emails
stuffed into my mailbox. Next time I'll read email during the vacation!

> I must admit that I don't understand entirely what is at issue here.
> With respect to this thread, the specification seems rather clear.

I haven't caught up on all emails, so maybe I'm off-base here, but I also
don't see how the current specification is confusing on this issue.

> I'm less clear on the questions: What is a "Base-context"? Is that a
> context with only the required elements?
>
> There's a type uri which automatically discriminates to some understood
> semantic. WS-Context does not provide a default uri, at least not that I
> am aware of.  The activity concept is explicitly abstract in the spec.
> So I presume that Peter is correct in that the uri that is used must at
> least explained to have meaning somewhere.

I haven't caught up on the emails so may be off base here, but maybe Peter's
point is that the base context ID cannot be interpreted alone unless in a
very restrictive environment. If there are multiple ways in which a basic
context ID can be used (not just "correlation") then receiving such a
context ID by itself doesn't help: you need to type ID too. Or is that a
different argument?

Mark.

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

www.arjuna.com


>
> Greg
>
> Furniss, Peter wrote:
>
> >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
> >
> >
> >
> >
> >
> >
> >
> >
>
>