After thinking about the structure
of context further, there was some concerned that the current structure
may inhibit adoption by potential users of the specification because it
does require a change to existing context structures (or at least to
recipients of the context). If we take the case of an activity that has
security and transactions involved, then the current format of that
context would be:
<wsctx:ctx>
<security>
...
</security>
<transactions>
...
</transactions>
</wsctx:ctx>
whereas normally you'd expect
(because this is how the relevant specs. would define it) the context
to be:
<security>
...
</security>
<transactions>
...
</transactions>
We've said from the start that
existing services should just be able to plug in to Context and be used
as-is. If we take the case of ALSs then that may well be the case (the
difference between the formats of context can be hidden from the
individual ALSs by the context service). However, that's not the case
for user-level services (those things that actually consume the
context), because we would need to look for a mangled form of their
current context structure in the WS-Context format. Is this is a big
thing? Maybe it makes sense to differentiate WS-Context aware
user-level services from those that aren't?
If we changed the structure to say that there wasn't an
all-encompassing context "wrapper", then it
does allow non-Context aware services to be driven within a Context
activity transparently - they just can't tell the difference since the
context structure is identical. However, we would lose relationship
information and Greg put this quite well:
"For one thing, I've found these kinds of non-nested
relationships in XML to be awkward to work with and somewhat
non-intuitive -- this is how the EJB spec structured that transcation
attributes, for example, and I must say as an implementor I hated it."
If we were to change the structure
of context so drastically (and I'm not convinced that it's
required), I'd suggest we keep the basic context data element from the
original context, but have it as a specific element. So:
<security>
...
</security>
<transactions>
...
</transactions>
<activity-service>
...
</activity-service>
A side-effect of such a change is
that we'd lose the automatic nesting structure of the context. However,
how services (ALSs) deal with nesting in their own context element is
up to them. The problem comes if there's a required relationship
between the various contexts (e.g., transactions only belong to the
lowest-level child in a nested activity.) I haven't had a chance to
fully think the implications of this change through yet, but I suspect
we could either punt on this to the respective specifications, or
provide some related-to schema element:
<wsctx:related-to>
<security>
...
</security>
<transactions>
...
</transactions>
<wsctx:related-to>
with attributes that allow you to
specify where within a nested hierarchy a specific context element
applies. But this looks complex.
Mark.
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
www.arjuna.com