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

[Greg Pavlik <greg.pavlik@oracle.com>]

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'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.

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
>
>
>
>  
>
>
>  
>