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
