Can you believe it? There was a day when "This Site Best Displayed in [BROWSER]" was common on pages. Now you go to a page, you just assume that it speaks to the major browsers. It may look a bit different in IE, and there may be some browser sniffing going on the in the back room. (That back room might even be Dojo.) But you certainly don't make the user worry about it.
SOA had that compatability baked in. If your SOA server box said, "Best used with an IBM Database," what would be the point?
Here's the thing. All SOA servers can talk SOAP over HTTP. JavaScript can assemble SOAP packets, which are just strings after all, and send them via AJAX over the wire. That's a lot of overhead. If you control both of the endpoints - the browser and the SOA server - you'd be crazy not to use the "most native" transfer you can afford. That's what'll stop hourglasses on your CEO's browser.
In the Dojo Universe the most native file transfer format is REST and JSON. So it's a no-brainer, right? Get an SOA server that talks REST and JSON to your browser, and SOAP to the rest of the Service-Oriented World.
Not that simple, muh friend. REST is a buzzword-de-jour, and now every SOA server says they can do it. The ease of doing it is highly variable. If your Enterprise Service Bus talks XML across all the components, how do you translate the incoming and outgoing packets to query strings and JSON? If most SOA servers, the answer is "by writing code".
Ick! You mean I have to write a program for each and every translation? Well yeah. It may be a more specialized language like XSLT or XQuery, and hence easier than C++. But it's still code. And unlike translations between XML formats, which can be done with a visual editor, no one seems to have a visual XML-to-JSON designer bundled with their SOA server.
Let me be candid. I am the world's laziest programmer. Of course I want all the exception handling, logging, and asynchronous scheduling ... but I want to hand this over to the Business Analyst to do. I am too busy writing Dojo widgets. Those are fun!
So it's interesting. There are open source SOA servers that do what $100K/CPU SOA servers cannot. That's what I'll talk about next.
