Some Interesting History

Here's a little bit of fiction for you, with a prefaced disclaimer. I'm not anywhere near claiming that these thoughts are moderately well-formed.

"Hey, this web stuff is cute. OK, back to the real stuff. [CORBA, DCOM], anyone?"

"Hey, what the !*@&#^#? I can't connect my [CORBA, DCOM] over the net. Hmmm...."

"Hey! If I could just go through port 80, I could connect my [CORBA, DCOM] bits over the internet. Cool!"

"HEY!?!?! Why is this firewall looking at my content? Argh."

"Hey! What if, instead of IIOP, I encoded this stuff as XML? It'll be slow, but .... COOL!"

 "Hey, what would be great is if I had a generalized envelope so that I could add in a bunch of orthogonal features like transactions and security and reliability! But what to call it? ... How about, um, SOAP? Cool!"

"Hey. What would be great is if I had a nice, generalized OM for distributed programming that sits on top of all of this infrastructure so that I can almost transparently switch between programming models and stuff. That's be cool! I'd rule the world! What do I call it? Hmmm.... how about, um, 'Indigo?' Cool!"

"Hey -- how the $&%^% to we do HTTP GET?"

D'oh. I find this interesting. So, basically, at the end of the day, there is a baseline understanding of how the web was designed and currently works that was largely ignored/dismissed in the soap world and specifically in the Connected Systems Division until this Biztalk SDK. Many of us, myself included, drank to kool-aid on soap early on, because we wanted to connect systems together, and we liked messaging or we liked distributed objects, and we didn't stop long enough to grok fully the web. As I did more web stuff, I realized that I didn't really care about a lot of the stuff that was layered into the SOAP/WS stack, and I did really need and love the beauty of GET and friends.

Do we need SOAP? Sometimes. Maybe. It is nice for layering in security when transport security isn't good enough.

Do we need contracts? Sometimes. Maybe. It can help make the services and resources more accessible to the broad mass of developers. But in many cases, the service provider ships SDKs as well, and that makes the contract less necessary at the expense of coupling. Also, you often get a set of examples of documents, and you just 'hack something up.' Often, the contracts that are already out there (HTTP, RSS/ATOM, etc.) are good enough.

So, it is interesting to me to watch guys like Clemens Vasters and Don Box (and Steve Maine, though I think he was less heavily involved in 'expectorating' the WS-splat and a lot more heavily involved in consuming and evangelizing prior to getting into the big house) starting to shed the WS-Splat baggage and just GET it. And I think that they are being pragmatic about it and trying to scratch the 80% itch (GET) really well, but they are adding in a decent set of support for the REST (ha, pun, ha ha, er, um...) of the story without being to religious about being RESTful. And when questions come up like [paraphrased] "Well, shouldn't you layer soap into that?" they look very relaxed and calm as they say [paraphrased] "Nah, you're not going to need it here." From the outside, it looks a little cathartic.

Comments

[Patrick Logan]

"Do we need contracts?" Always. The misunderstanding is in answering "what is a contract?" Design-time checked overspecifications are not the only form of contract. For example, the HTTP spec is a contract. The Atom Protocol spec is a contract that builds on that. If I were to build an order management system on top of the APP, I could give you a specification that builds on APP. As you noted, an "SDK" or even just "a set of tests" is often a sufficient executable format for those contracts. Given my order management spec and a reasonable set of tests that excercise it, developers should not have any trouble using that order management system.