Since this is an aside to the main work of the TC, I think it would be
best to move discussion to a subgroup. Really we just want to do as
little as possible ourselves. Can we have setting up a subgroup as an
agenda item for the next call?
Mark Little wrote:
-----
Original Message -----
From:
Greg Pavlik
To:
Sent:
Monday, January 05, 2004 10:40 PM
Subject:
[ws-caf] Moving on Addressing
What I would like to propose is that
we consider aligning CAF's addressing requirements with WSDL as closely
as possible in order to achieve four objectives: eventual migration to
standardized addressing, a useful way to talk about web services,
addressing information independent from the message bodies, and a
static declaration of relationships between port types in WSDL. I think
we what we need to define is something simple enough to satisfy the
requirements of CAF and nothing more. I don’t believe that we can make
use of WS-Addressing in this context as it’s currently a proprietary
specification detached from any standards efforts.
I agree. Such
an approach matches the original intention which was to have something
that could more easily be swapped out with whatever was the standard.
The formal technical details of whatever we do can be
hashed out in a working group. For now, I’d like to put some ideas on
the table and make there is a consensus that we need something more
than what is in the current submitted specifications. First, I'd like
to make it clear why each of these objectives is important.
Standards Alignment
Obviously, we want broad
interoperability with as much infrastructure as possible. This
objective is perhaps the most difficult since there currently is no
standard mechanism for SOAP message addressing, so I assume that it is
a goal rather than a requirement.
If
we make it a goal then I don't believe we can hit our deadlines. It's
definitely a requirement and perhaps a goal for a 1.x version of the
specifications, but to be realistic we don't stand a chance of 1.0
being compliant with an addressing standard that doesn't look like
existing any time soon.
However, there is movement in this
area in the WSDL working group and I propose that we use WSDL as the
basis of our addressing solution in so far as possible. If all goes
well, we can work to achieve broad interoperability as well as ease of
consumption of addressing instructions by endpoint infrastructure and
intermediaries. In the worst case, we will have our own addressing
solution in the end, but one that makes sense.
Referencing Web Services
We have to have a way to talk about
services, since services consume the messages we are sending around.
The current submitted CAF documents use a URL
URI.
to represent a service (a bit of a
simplification, but basically accurate). This is not useable as
multiple services may share the same URL. There is also an
extensibility element that I presume is meant to act like an Object Key
in CORBA, but that is meaningless to web services and should be avoided.
I
know we've had this discussion before, but I don't think it's been
public, so it's probably worth going over it again now. The ideal
scenario that we wanted when writing the specs. was to unambiguously
identify services by URI. However, as you point out many/most SOAP
server implementations don't support this option well (e.g., dynamic
endpoint registration isn't possible, or simply running multiple SOAP
servers for each endpoint doesn't scale, there are only so many active
ports that the OS can support anyway). So, we ended up with the URI/URI tuple that currently
exists, which is meant to provide the abstraction of the "ideal"
service implementation. The first URI is the absolute endpoint for a
"listener" service, and the second URI is for demultiplexing across
multiple services that may be hosted by that "listener" service.
Obviously if you don't do multiplexing of services then you can ignore
that second URI.
It would be better to use something
that is based on WSDL. For our purposes, the most important outcome of
current WSDL deliberations is this: the wsdl20:ServiceType may be used
as the basis for providing service references. A service element
provides complete definition of the service itself and is a perfectly
useful mechanism for establishing dynamic relationships between
services; we could also provide "strongly typed" references in message
payloads. This group needs to formally resolve whether it will be
dependent on WSDL 2.0 or WSDL 1.1; I believe that we can make this work
for referencing with WSDL 1.1 if we require that the service implement
only a single PortType.
As
long as the mapping you are proposing matches the requirements above, I
agree. If it doesn't then we need to examine the impact on real-world
deployments. I kind of assume it does match, from our previous
discussions, but just want to be sure.
Addressing Information In SOAP Body
If you look at the schema for WS-CAF,
the addressing information is passed around in the SOAP body. This is
bad for a number of reasons. It creates brittle solutions (eg,
demarshalling errors in the SOAP body can not be addressed). More
importantly, it's simply a bug to include system level instructions in
SOAP bodies. We should move the addressing information to SOAP headers.
There are no standardized headers, so we will need to invent some in
the short run. If standardization occurs, we can move pick up those
addressing header definitions. We could make do with the following
headers:
MessageOriginator: Originator of the SOAP message. May be a
service reference.
MessageDestination: (Final) destination of the SOAP
message. Must be a service reference.
ReplyDestination: Destination for asynchronous reply. Must
be a service reference.
FaultDestination: Destination for faults. Must be a service
reference. Note that CAF doesn’t respect any fault rules, so we’ll need
to mull this over a bit.
MessageId :A unique identifier for the message of type URI.
MessageReference: A
reference to a MessageId. This may be used for correlation.
A brief example is included in the
end of this email.
Hmm,
interesting. I'll have to mull this over before replying on this one.
Establishing Relationships Between
Services
The consumer of the specifications as
they stand is left to interpret the relationship between operations
defined in different abstract WSDL definitions. It would be desirable
for both human users and for tools to define formal relationships
between those operations as a full-fledged message exchange pattern
that are machine interpretable, or at the very least communicate what
the messages that the operations send asynchronously. Of course the
specification text could (and should) spell out the relationships, but
this is less useful since the web services runtime platform is barred
from automating any of the addressing functions. There is no way to do
this at all in WSDL, so I’m going to punt on this one and suggest we
wait for a few months to see if there are any developments to help us
here since this is nonessential to a functioning runtime.
I'd
recommend pushing this out to a 1.x requirement given the timescales
involved. It's neither necessary nor sufficient for using the specs,
but would be a nice thing to have eventually.
Example SOAP Header (not quite
correct for simplicity):
<!--[endif]--><s:header>
<caf:messageOriginator>
<wsdl:service
interface=“caf:ActivityService"
binding=“caf:SOAPActivityService“>
<wsdl:endpoint>
<wsoap:address
location=http://www.someurl.com/example/>
</wsdl:endpoint>
</wsdl:service>
</caf:messageOriginator>
…
<wsmd:messageId>http://someguid
</wsmd:messageId>
</s:header>
Note that this allows us to talk
unambiguously about services and messages. Presumably, other headers
would include a reply destination and a fault destination, though the
two may be redundant. And of course the addressing directives are not a
part of the SOAP body.
Again, I would like us to have a
subgroup that deals with these issues in detail, so please regard this
as a launching point for those discussions only.
I
agree that this sounds like the work for a subgroup. It's also not
something that needs stall other work in the WS-Context space, i.e., it
can occur in parallel with the mainline work.
Mark.
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
www.arjuna.com
