(Editor’s note: This is the second part of a continued series of transcriptions from a conversation secretly recorded at a party in San Francisco during JaveOne 2007 between Ted Neward and Adrian Trenaman on the SOAP/REST debate. Ted was just finishing up discussion of SOAP encoding when they were interrupted by a burly black-suited-and-sunglassed “G-man” mumbling “Continue or Cancel?”.)Adrian: So we’re happily agreed! The SOAP-encoding is dead, may it rest in relative discomfort.

Ted: Yup! It was by far and away the biggest reason for SOAP incompatibility in the early days. If I remember the stats right, the SOAPBuilders website used to track compatibility of SOAP toolkits, and if you picked two SOAP toolkits completely at random, you had about a 50/50 chance of them working together.

Adrian: Right, but that’s my point: in the early days, SOAP was responsible for a lot of the incompatibility mismatches, but we’re past that now, right?

Ted: Yep. Cheers to that.

(Sounds of glasses clinking.)

Adrian: So that’s all in the past: SOAP-encoding has long since bitten the dust, we’ve all moved to using literal XML data, defined by schema. What that means, then, is that after removing the SOAP endcoding stuff, SOAP really boils down to just two things: one, a wrapper around your XML payload, called Body, and optional headers to the message, to carry out-of-band information, like security credentials, transaction IDs, session IDs, or whatever.

Ted: Yep. A buddy of mine once remarked that the SOAP specification is the specification that doesn’t really specify anything.

Adrian: (Laughs) So, if I can borrow your cocktail napkin for a bit–

Ted: Sure.

(Editor’s note: Again, our agent, cleverly disguised as a coktail napkin, was able to capture the text of the example.)

Adrian: –it looks something like this:

So, let’s say I want to send some XML from me to you. I can just drop the XML into the Body element, and that’s it. If I want, I can put fancy headers in the Header element with security, reliabiliy or transaction information, as per the multitude of WS-Everything specs. Alternatively, I can just put my own custom headers in there: maybe I’ve got my own, in-house military strength encryption headers, or my own session management scenario.

Ted: Though I’d strongly suggest you not try to create your own encryption. Bad juju there, baby.

Adrian: Agreed.

(Sounds of glasses clinking again.)

Adrian: So, here’s my question to you, why do people oppose SOAP so much?

Ted: Well…. That’s actually kinda hard for me to argue effectively, because I tend to side with you on this one: I like SOAP, simply because at the end of the day, it’s just a messaging format designed for framing and extensibility. Once we pull the SOAP-encoding bits out of the specification, there’s really nothing all that complex about it anymore.

Adrian: Aha! We agree!

Ted: Shush! Don’t let anybody hear you say that! You’ll lose respect!

(Laughter)

Ted: Seriously, though, I’ve heard a couple of objections, which I’m happy to argue with you about, if you like.

Adrian: Fire away.

Ted: Well, the first one that’s commonly tossed off is that SOAP is too complex, and REST, or perhaps we’re better off calling it POX-over-HTTP, is a much simpler way to go and therefore much more approachable.

Adrian: Hmm. I’d have to argue that this is a pretty weak objection, given the example I just wrote a few minutes ago. Assuming no headers, you’re talking two extra XML elements around your XML payload data, and that’s hardly an unmanageable increase in complexity, if you ask me.

Ted: I’d have to agree, particularly if you use XPath to extract the data from a parsed Infoset structure or model it using JAXB or XMLBeans or one of the other toolkits.

Adrian: I’ve heard people accuse SOAP of being slow - but that’s hardly a credible argument if you’ve bought into XML in the first place!

Ted: Yeah - honestly I’ve never benchmarked the XML parser against a binary parser, and in general I don’t care much, because we’re generally talking about out-of-process communication anyway, and the time spent marshaling and unmarshaling the data to and from XML is going to get lost in the noise of sending the data across the wire.

Adrian: So what’s the principal argument, then?

Ted: YAGNI.

Adrian: Bless you.

Ted: (Laughs) No, thanks anyway. YAGNI is the acronym agile folks love to toss at things they think are too complex or overengineered: You Ain’t Gonna Need It. It’s a term that basically suggests that if it’s not something we need right away, then don’t bother building it in, because You Ain’t Gonna Need It.

Adrian: They don’t believe in evolving systems?

Ted: No, they believe that engineers have this tendency to gold-plate stuff on the murky grounds of “I know that we’ll need this someday”. Then, about half the time, customer needs change, or projected phases to the application don’t happen, and they never end up using that stuff they built in–

Adrian: –which makes all that work they did completely meaningless.

Ted: Right, because, as it turned out, they didn’t need it in the end.

Adrian: Hmmm - yeah. Still feels week though - I really can’t accept that using a SOAP envelope is dragging us into The Marsh of Unwarranted Flexibility.

Ted: Speaking of which, let’s not get too bogged down ourselves. I believe I spot the open bar in the corner, and the other phrase that comes to mind is IAGNAGOW.

Adrian: IAGNAGOW?

Ted: I am gonna need another glass of wine. You want one?

(Laughs)

(Editor’s note: At this point, our agent, cleverly disguised in no disguise at all but looking like an attendee at the party, was ejected from the party for being too quiet and not drinking enough.)

Read Part 1 - Read Part 3

This entry was posted on Tuesday, June 5th, 2007 at 3:21 pm 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.