+1.
I'd also like to suggest that context embedded in an address isn't
really the right way to go. Despite the fact that we (Jim, Savas, myself and
others) have suggested that ReferenceProperties *could* use WS-Context, that
doesn't necessarily mean that it's the best way of tackling the problem.
Suggesting that context within an address is the right model is ignoring SOA
principles.
Mark.
----- Original Message -----
Sent: Thursday, May 27, 2004 3:56
PM
Subject: Re: [ws-caf] Mt Everest and
WS-CF
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.
. The other two would have an identifier but
that's the only thing they share, I think.
Peter
|