Jan, I hope you didn't think I was suggesting that WS-Addressing does place
context into the address, but rather commenting on 'WS-Addressing is
particularly interesting because it is essentially "opaque context"' As I said,
context shouldn't be within an address.
However, it's a different argument as to whether the use of
ReferenceProperties to create the equivalent of an IOR
(ReferenceProperties==Object Key) is a good thing. If you read the recent paper
on WSJ comparing WS-Context with WS-RF I think you'll see the argument against
in a much stronger way than I have time to write in this email.
Mark.
----- Original Message -----
Sent: Friday, May 28, 2004 10:42 AM
Subject: RE: [ws-caf] Mt Everest and
WS-CF
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
|