----- 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
