OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-caf-editors] comment question


 
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.
I agree that (i) is a degenerate case of (ii), but if you look at (ii) and change only a few words, you get (iii):
 
(iii) 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 services together into an activity. An activity is a series of related interactions with a set of Web services; these operations are related via the context.
 
My point is that in order to define context correctly, there has to be a notion of associativeness. We're calling that an activity at the moment, but we could have called it foobar. To remove activity (or foobar) and just talk about context first, is a little confusing IMO, precisely because we don't talk about relationships and how context is used.
 
I don't think this is really a discussion about the architecture. Let's not confuse activity with ALS, for a start, i.e., if there was no such thing as an ALS in the spec. I'd still be arguing for the notion of activity up front. Does that help?


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.
Actually single celled organisms came first ;-)
 
I'd just reference what I said above: let's ignore ALS (if that's at the back of anyones minds when they think about activity). In order to bring context into this picture, we need to define why it's needed and that really requires the notion of associativeness of invocations/messages/whatever. In its purest form, activity is a conceptual notion; context is the concrete representation.
 
I think what I'm getting at is that I'd be happy to introduce activity early (like we used to), and make it clear that this is an abstract (conceptual) entity, and then show how context is related to that. We could even rename ALSs to remove the A, if that's adding to the confusion.


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.
I understand and agree, but don't think this negates what I've just said.

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.
I don't think you can get much simper than: an activity is a conceptual grouping of services cooperating to perform some work; a context is the concrete manner in which this grouping occurs.
 
Mark.


 
Mark.


Greg




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]