|
WS-Addressing does not place context into the address. What
it does, it uses set of SOAP headers to identify execution context for the
particular "Endpoint" by introducing EndpointReference abstraction. The
EndpointReference itself additionally contains logical address of the endpoint
and a set of policies, which are relevant to the use of that EndpointReference.
It is important to distinguish between a service address
and a service instance identifier. The first is similar to for instance IP
addresses and port number, the second to CORBA IOR. I don't see anything against
"SOA principles" in the EndpointReference concept as it is not just a service
address. I agree that it would be useful to use WS-Context for mapping
EndpointReferenceProperties into SOAP headers as they identify the
execution context of the endpoint.
Jan
+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
|