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