Moving on Addressing

[Greg Pavlik <greg.pavlik@oracle.com>]

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.

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

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.

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.

Example SOAP Header (not quite correct for simplicity):

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

Greg