----- Original Message -----
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.
Mark.
Greg