Title: Message
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
-----Original Message-----
From: Greg Pavlik
[mailto:]
Sent: 25 March 2004
23:00
To: Mark Little
Cc: Newcomer, Eric;
ws-caf
Subject: Re: [ws-caf] context block or one element per
type
Attached find response to original mail from Mark in
RTF.
Mark Little wrote:
Agreed.
Mark.
-----
Original Message -----
From:
Greg
Pavlik
To:
Newcomer, Eric
Cc:
Mark
Little ; ws-caf
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.
-----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
