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