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.