Sounds
like a good idea, let's put the formation of an addressing subgroup on the
agenda for the call on the 19th. There are a lot of issues here, and it
would be great to get some progress toward a WSDL-aligned solution, but as Mark
said the timeframe for using WSDL 2.0 would take us past our
deadlines. But addressing is a more of less "logical" thing and as long as
what we keep things flexible we should be able to continue the work on the
main spec and substitute in a new mechanism in the future...
Eric
-----Original Message-----
From: Greg Pavlik
[mailto:]
Sent: Tuesday, January 06, 2004 9:39
AM
To: Mark Little
Cc:
Subject: Re: [ws-caf] Moving on
Addressing
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
