The Ancient Art of Programming

If you read the SOAP specification, you will notice that the entire spec doesn’t contain the word operation. Not once. On the other hand, in the WSDL spec it is mentioned numerously. This seems weird, isn’t WSDL used to specify SOAP services?

Actually, it isn’t so weird. While RPC-style SOAP there is a strong relation between the message and the actual method being called; in document-based SOAP, there is not. Document-based SOAP is just a messaging protocol: one just sends a message somewhere, not necessarily binding this message to any method, or class for that matter. However, if you do want to expose a class via SOAP. and couple you document-literal message to a specific method (thus tightly coupling your web service to your Java class, which is a bad idea), you are faced with two issues: how do you pick the class to be invoked, and which method is to be invoked?

There are few solutions to this issue:

• when using URL-binding, the HTTP request URL basically tells you what service to invoke. So if the url is http://example.com/MyService, the class will be named MyService.
• the SOAP Action HTTP header offers another solution: this header is mapped to a specific service instance. Microsoft .NET uses this method to resolve request to services.
• the Root Element of the Payload tells you which method to invoke. When faced with the aforementioned problem, Microsoft introduced the so-called Wrapped style, which basically combined RPC with the Document style. In a wrapped message request, the SOAP message looks something like:

  <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Header/>
      <SOAP-ENV:Body>
      <myMethod>
        <argument>42</argument>
      </myMethod>
    </SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

  which tells a wrapped service to invoke the method myMethod with the argument 42.
• Because it is bad idea to rely on a transport to relay important binding information, the wise people of W3C conceived the WS-Adressing specification, which solves binding information within the message itself.

Unfortunately, most SOAP containers, both Java and .NET hardly offer any insight in these issues, and make the choice for you. In my opinion, when you develop you web service, you need to have insight in these issues, and pick a technique that suits you situation.

I’ll be doing a session on Service Oriented Architectures at J-Fall, the fall Java conference hosted by the NL-JUG. The session is entitled Putting the Service back into SOA. In it, I’ll be talking about my pet peeves regarding SOAs, and make a strong comparison between regular web user interfaces and web service interfaces.

The session might end with a bit of bang, but you will have to be there to find out .

You can register here. Hope to see you there!