It
might be no harm to include the context wrapper as an optional element (ignored
by those systems that don't want to deal with it but used by those that can) to
indicate ordering - where one may want to define an order of header
processing precedence.
-----Original Message-----
From: Mark Little
[mailto:]
Sent: Monday, March 22, 2004 5:37
AM
To: ws-caf
Subject: [ws-caf] context block or one
element per type
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:
<SOAP:header>
<wsctx:ctx>
<security>
...
</security>
<transactions>
...
</transactions>
</wsctx:ctx>
</SOAP:header>
whereas normally you'd expect (because this is
how the relevant specs. would define it) the context to be:
<SOAP:header>
<security>
...
</security>
<transactions>
...
</transactions>
</SOAP:header>
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:
<SOAP:header>
<security>
...
</security>
<transactions>
...
</transactions>
<activity-service>
...
</activity-service>
</SOAP:header>
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:
<SOAP:header>
<wsctx:related-to>
<security>
...
</security>
<transactions>
...
</transactions>
<wsctx:related-to>
</SOAP:header>
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
