Greg,
This
one may really be a bit off our proper track.
Interleaved
Furniss, Peter wrote:
Greg,
<snip the earlier part of the alastair .. thread>
A further comment on the IBM/MS product specs: there are in
fact three
contextualization mechanisms: one in WS-Coordination, one in
WS-ReliableMessaging, and one in WS-Addressing. Putting aside
WS-Addressing for a moment since it introduces a new model to the web
services environment that I don't want to argue about here, let me
observe that there is no fundamental distinction between the
lifecycle
control interface in WS-Coordination and WS-ReliableMessaging. Why
shouldn't these be based on a common model? Wouldn't that in fact be
simpler and less error prone? From there, it seems a small step to
imagine the reliability and coordination/transaction contexts
having a
common root. I submit that this is in fact a flaw, not a strength, of
the specification set; they they are unnecessarily complex due to the
failure to deal with common constructs, idioms and patterns as, well,
things-in-common.
Well the WS-Coordination and WS-RM both have equivalent of "begin".
WS-RM doesn't always use it,
and when it is used, it is asked of the eventual receiver. The
termination sequences are different, since WS-RM is just stopping, and
WS-Coordination will have delegated to a transaction protocol.
As contextualization, it is true that a message carrying the relevant
headers is "in the context" of those headers, and subject to their
implications. But the same is true of more or less any header - that's
what they're for. WS-Addressing is particularly interesting because it
is essentially "opaque context" - the reference properties don't need to
contain any kind of identifier in the ws-context sense at all (it might
tell the receiver which database to look in, but since only the receiver
knows what they meant, that's fine - it's just a piece of syntactic
partitioning of the address)
Is it fine? What if it happens to conflict with another header since
there are no restrictions? I'd like to suggest that WS-Addressing would
benefit from a container and that this is generally a problem for
contextualization based solely on headers.
PRF: I thought ws-addressing needed a container at first but
then realised the trick. The reference properties only emerge from their
WS-Address EnpointReference wrapper when the message is sent to the
originator of the EPR. So all a generator of EPR's is saying is
"when you send to me, put these in the headers; never mind why, or what you
think they mean, just do it". It could only conflict with another header if the destination supported
that header - (I suppose a sender might put in headers that it hoped the
destination would understand (mustUnderstand=0, presumably) that in fact
weren't wanted, but that's kind of wierd)
It does admittedly lead to some possibly odd
things - one could have a joker reference property, that was something
like:
<wsa:ReferenceProperties>
<ns1:statement>If
this appears in a SOAP header it is an admission by the sender that
he is a nitwit</ns1:statement>
</wsa:ReferenceProperties>
I've been trying to work out if that could actually
be used in a damaging way - it might be possible, but it would depend on more
apparatus around web services than we have at present.
But generally I don't see why a container for
contextualization helps. ALL soap headers are the contextualization of the
body. This works because they can be discriminated by their namespace
identifiers. But that's the main contention I have, which the thread this
sprang from can deal with.
Peter
. The other two would have an identifier but
that's the only thing they share, I think.
Peter
|