[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]