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