|
Jan, my original comment was directed at the questionable use of
WS-Addressing mentioned in Peter's email.
Mark.
----- Original Message -----
Sent: Friday, May 28, 2004 12:40 PM
Subject: RE: [ws-caf] Mt Everest and
WS-CF
So if I understand this correctly, your original
comment was not about WS-Addressing at all, since WS-Addressing does
not place context related information within an address. The other
question is, whether the concept of the EndpointReference (encapsulation of
the address and other endpoint instance related information), as defined by
WS-Addressing, is appropriate for Web Services. Is it right?
From my experience with Web Services, having only a
transport address of the endpoint is not always enough to be able to
communicate with the service - I'm not talking about message formats here,
you have to know them too of course . It is helpful to have a
mechanism to embed additional properties (like policies) to the
particular web service instance reference, that, as you said, shouldn't be
placed inside the original Web Service endpoint address. Such a endpoint
reference can then be placed into a WSDL describing that particular web
service instance instead of the transport address of the endpoint.
Unfortunately this cannot be easily accomplished using WSDL 1.1. This is not
about WS-RF, which is going a lot of further and is defining concept of
resource and association between the resource and the service, which
executes in the resource context. I agree, that this is rather a
questionable thing to do in Web Services environment in
general.
Jan
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
|