-----
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