-----
Original Message -----
Sent:
Friday, March 26, 2004 5:10 PM
Subject:
RE: [ws-caf] context block or one element per type
Interesting.
I had assumed the usual way of dealing with representing contexts
and the protocol-specific information would be as Greg describes - each
context is a soap header containing the stuff for its (combination of)
protocol and there can be multiple headers of base type wsctx:ctx.
:
Mark's proposal startled me, partly because it raises a question
about context as a whole, at least context-by-value (this is partly a
reprise of some of the Paris discussion)
If it is possible for a compound context to be broken up, with its
protocol-specific elements travelling in their own right, and a context
element to define the relationship, then presumably one could do the same
with simple (one protocol) context. In which case, what semantic is being
carried by the context in that case? Is it needed as a header at all ? And
then the same argument applies to a simple context in the
normal arrangement - if the protocol-specific content is
intelligible on its own, what has been gained by putting it inside a
context, in addition to making it a header ? This was one of my points in
Paris - context-by-value is not needed
Of course, there is a semantic in the multi-protocol case : the
context wrapper (or references in the context) mean "these two are to be
considered together, in accordance with the rules defined in uri
....", the uri being that of the context-type ( aka
ALS-configuration-identifier, I think)
But that raises another question with these multi-protocol
contexts: who is supposed to implement the combination rules ? The Context
Service is, as I understand it, unaware of what the different context
types mean - it just goes round all its enlisted ALS's asking if they
would like to make a contribution. If it is unaware of different types
(i.e. one could take a Context Service implmentation and use it with ALSes
and a context-type that were unknown when the Context Service was
written), then it can only have a very simple combination rule - put the
stuff from each ALS in the context in an arbitrary
order.
If anything more sophisticated is needed (order the requests to the
ALSes, structure the combining of their responses) then the Context
Service has to implement the combination, and the Context : ALS
relationship is no longer the use-agnostic interface it appeared. And is
it really going to be common that independent ALSes can just be combined
without modifying the ALSes themselves ? It seems much more likely that
the Context+ALSes group will be the implementation unit - in which case,
separating them out in an interoperable way isn't really worth
it.
Which in turn means there is no such thing as a general
multi-protocol <context> element. There are contexts (in the
sense of soap headers on application messages that contain information
relevant to supporting protocols/mechanisms) but their internal content is
specific to the combination, in the same way as the content of a
single-protocol context is specific to the protocol. And it we are back to
considering why:
<wsctx:context>
<wsctx:type>uri_for_foo_and_bar_combination</wsctx:type>
<foo:contextinfo
xmlns:foo="foo_schema_uri"> ... <foo:data>
<bar:data
xmlns:bar="bar_schema_uri"> ... <bar:data>
</wsctx:context>
is easier to cope with as a header
than
<foobar:context
xmlns:foobar="uri_for_foo_and_bar_combination">
<foo:contextinfo xmlns:foo="foo_schema_uri">
... <foo:data>
<bar:data
xmlns:bar="bar_schema_uri"> ... <bar:data>
</foobar:context>
As I mentioned, some of this was raised in Paris, but I don't
remember a clear answer, and it would be good have it on the archive if
I've forgotten it/failed to understand it.
Peter
Attached find response to original mail from
Mark in RTF.
Mark Little wrote:
Agreed.
Mark.
-----
Original Message -----
Sent:
Tuesday, March 23, 2004 5:17 PM
Subject:
Re: [ws-caf] context block or one element per type
I suggest we have a statement explaining why context
is useful with this structuring approach.
Newcomer, Eric
wrote:
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.
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