(Editor’s note: This is the fourth part of a continued series of transcriptions from a conversation secretly recorded at an “after” party in San Francisco thrown by a company who shall remain nameless but rhymes with “oogle” during the JavaOne 2007 conference between Ted Neward and Adrian Trenaman, who were discussing the SOAP-vs-REST debate. Ted had just suggested the idea that SOAP was inherently RESTful, and Adrian needed a break to drink more while he revelled in the implications…)Ted: Now, I probably should be fair here, and point out that there are definitely going to be people who would spontaneously combust at this description of REST, but I think it’s fair to say that a lot of the egregious errors of the original SOAP specification have been corrected in the SOAP that finally got ratified by the W3, meaning that SOAP 1.2, in of itself, is inherently RESTful.

Adrian: That’s pretty heavy stuff.

Ted: REST is a good architectural style. We just need to recognize that we’re not always exchanging hypermedia documents.

Adrian: But the nice thing with SOAP is, since it’s transport-agnostic, it would work even if you wanted to send the message over other transports beyond HTTP, like JMS messages.

Ted: Or over God’s original mesaging system, SMTP/POP3.

Adrian: Or ICMP, or Jabber, or… the possibilities are endless!

Ted: Yep. And the beautiful thing is, all those WS-* specs operate on the message, not the underlying transport, which is important for things like security. The encryption is in the message itself, so even if the message is resting someplace on a server waiting to be sent on to another server, the data’s not floating around in an unencrypted format waiting to be sent onwards. Combine that with the fact that HTTPS only works point-to-point, not across intermediary machines, and I think you come to a point where you realize that the overhead that SOAP adds to the XML you want to send back and forth is pretty miniscule compared to the future-proofing you buy with it, particularly given that vendors are slowly coming out with pre-canned WS-* stacks that I don’t have to build myself.

Adrian: So you think everybody should use SOAP?

Ted: Well….

Adrian: (Laughs) Not ready to go that far? Neither am I. I’ve run across applications where, quite frankly, SOAP just isn’t required. For example, if you’re a pure JMS house, then you can make use of JMS transport attributes to cover security, transactionality and addressing. Or, if you’re sending XML over HTTP and need it to be secure, then you could just secure the transport using HTTPS and then send any additional credentials using HTTP Basic Authentication.

Ted: But that only works if you’re going point-to-point, remember.

Adrian: Oh, sure. But in general, I’m a big fan of parsimony: if there genuinely is no use for SOAP in an application, then we shouldn’t force it in. I’m all in favour of concientious objectors. I think it’s important though every now and again to revisit design assumptions. SOAP can still be hugely helpful in existing POX applications: for a start, you’ve got the concept of a SOAP fault: very handy for dealing with bad payload in a polite way.

Ted: And an extensible way. Rather than having to rely on a finite set of error codes defined by the HTTP protocol, which don’t always map over to your application’s needs, you get to extend and describe the errors in an open–but arguably more complicated–way. Plus, your multi-transport discussion comes into play here, too. If you’re sending messages in multiple hops across different transports (HTTP, JMS, AMQP, and so on) then it’s good to put the headers in the message payload, rather than depend on features that are present in one transport and not in the next.

Adrian: You realize, of course, that if this conversation ever got out of this room, you’d probably be lynched at the next conference you go to?

Ted: That’s why I’m making very sure that we’re not standing next to any waiters, floral arrangements, CIA agents, ceiling fans, or attendees as we do this.

(Laughter)

(Editor’s note: At this point, our agent, cleverly disguised as a company-branded blinking-light pin resting on Ted’s T-shirt, Gmailed the conversation back to his handlers at the secret headquarters of TheServerSide, completing yet another dangerous mission.)

Read Part 3

This entry was posted on Thursday, June 7th, 2007 at 10:43 am and is filed under XML/Web services. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.