RE: [ws-caf-editors] comment question

["Newcomer, Eric" <Eric.Newcomer@iona.com>]

Well the context can be obtained from whereever it is, the results of one-ways etc. should be updated into the context data structure.

 

Yes, it is a kind of chicken and egg situation, and I think that you're right this is probably the key debating point we should try to figure out sometime, maybe we can meet in New Orleans and hash through this together.  In the case of a simple context management system, one that includes a REST-ful style of interaction, you pretty much have to start by positing the existence of the context.  Then the definition of the activity is derived from the list of Web serviecs that share it.  If you start by assuming that you are defining the activity first,i.e. somehow an activity has been defined using BPEL or whatever, then I agree that the activity would create the context.  I am not sure we need both models but I'm interested in the former since it would seem to provide a real low-cost simple entry point to the whole stack of functionality.  People could use it with very simple toolsl.

-----Original Message-----
From: Greg Pavlik [mailto:greg.pavlik@oracle.com]
Sent: Thursday, April 22, 2004 8:19 AM
To: Mark Little
Cc: Newcomer, Eric; ws-caf-editors
Subject: Re: [ws-caf-editors] comment question

Mark Little wrote:

 

----- Original Message -----

From: Greg Pavlik

To: eric.newcomer@iona.com ; mark.little@arjuna.com ; ws-caf-editors

Sent: Wednesday, April 21, 2004 9:11 PM

Subject: [ws-caf-editors] comment question

Eric asks:

[Would it be better to say that the context captures or reflects the semantics of the Web service(s) executing within the activity rather than that the semantics are defined by the specifications? The specifications define the way in which the context reflects the semantics of the activity, rather than vice versa?  I had always thought of the definition of an Activity as the same as the scope of context sharing, and the context reflected the semantics of the activity:...]

 

This is kind of what I was saying in the AIM conversation Greg and I had. I've always considered that an activity is used to group related "work" and that the context is the physical representation of the activity structure.

To which I have a few questions:

1) are these mutually exclusive?

 

It's all wordsmithing, but I always found that the original activity->context relationship was easier to explain to people and with little confusion. OK, I wasn't at the Paris F2F to witness that confusion, but then we could always blame a disaffected few and inconsistencies in the specification.

2) does a context reflect semantics when a service chooses to ignore the context?

We can't say anything about this really, unless we want to get into re-inventing something like WS-Policy. The semantics of the activity are global, and whether or not a service wants to use/ignore this at a local level is outside the control of the spec. at the moment.

I'm expecting that the backend of the service is required to respect some predefined semantic iff their exist a definition of the semantic and rules for which it is applied. Both require a specification.

Put another way, I agree that the context reflects the semantics of the activity, but I think the definition of the semantic expectations of the operation invocation cannot be established without reference to some highter authority.

Or am I missing the point?

This is a model/architecture point really. Let's consider (roughly) the two ways of approaching this:

 

(i) we define the abstract notion of an activity as a unit of "work" that is solidified by higher-levels (e.g., made secure work, transactional work, workflow, ...) Then there is a requirement for services to be able to identify whether they are participating in that work and, likewise, for clients to inform services that they are involved in that work and what it means to be involved in that work. This comes through the context.

 

or

 

(ii) we define context as a way of passing additional information under the covers that is non-functional to the normal running of the service (e.g., secure, transactional, ...) and used to related them together somehow. Then we define a notion of an activity that can use the context if required. But context is irrespective of activity.

 

Yesterday I wasn't so sure about (ii), but was prepared to punt on it. However, after spending last night re-reading the update, I'm more for (i) than (ii). I can see why you might want to go the route of (ii) if you didn't want to define activities, but I'm not convinced it actually adds anything and I'm sure it subtracts. The term "activity" is essentially a short-hand for "grouping of work" or "services that co-operate somehow" (you get the idea), so we need something like that anyway - you can't describe context without saying why it's needed and in most cases those terms will come up. So why not call it an activity? It has mappings into workflow, for instance, where it's almost a 1-to-1 mapping, transactions, correlation sets, etc.

First of all, we can go with whatever the consensus is.

But I have to disagree on a point. First let me make a statement: i is a degenerate case of ii. Once that's established, then you don't loose anything, but you gain the ability to use the context structure in new and interesting ways. For example, you can exploit it in place of headers that might benefit from the pass by reference capabilities, but do not require any kind of activity model.

While I understand what you're saying, let me switch gears again: I think Eric's point is a bit more subtle -- and independent of this issue of decomposability; if you read the model text, activities and contexts are more or less intertwined. He asks specifically about the execution embodying the semantic. And I'm asking if we have a chicken or the egg problem here -- to which there's no universal answer. One could say "God created a chicken" or "Evolution started in the egg", and both are starting points that some set of people might agree on. In some sense we need to pick our position.

The second implication is that the context viewed at a point in time tells us about the state of the activity. This is particularly hard for me because the context only reveals itself on the boundaries of execution -- not at all on responses that don't exist, as in oneway operations, and becomes even more complicated for parallelized executions. Which is why I tend to think at best the context can have associative properties, but no absolute view of the state of the world.

The reaction I get on the spec is that 1) it sounds important and invariably 2) it's hard to understand. Most of the confusion comes from the fact that there's alot of concepts. I was hoping that the concepts could be isolated to some extent in the presentation -- particularly if they had independent use cases to support them.

 

Mark.

Greg