If SOA and AJAX is the Killer App, Who is it Killing?

Dietrich Kappe, Friday, October 13, 2006 @ 12:45 pm

Over at SOA Digest, AJAX + SOA is hailed as the new Killer App:

We have business functionality represented in a reusable form - SOA services. We have ubiquitous connectivity - the Web. We have what's turning out to be the new application container - the browser. We have a programming model in the application container/browser - JavaScript. What I really want is a user-based composite application, not a middleware-based composite application.

I'm seeing this more and more, the idea that the browser becomes not just the interface from some middleware powered app that orchestrates the services, but that the browser, by means of Ajax, becomes the orchestrator of services, cutting out the middleman. I see this trend in the stated desire of Tibco to have it's GI product drive the demand for services in the enterprise. It is a trend that worries me.

I think the author of the post misunderstood the original article he was referring to:

What I really want is a user-based composite application, not a middleware-based composite application. To make this happen, I need a development and runtime platform that not only speaks AJAX and SOA, but governs the two as well. Some vendors promote the concept of AJAX applications calling WSDL-based Web services directly from the browser, essentially making SOAP calls. This approach even has a name - "client/SOA." This may be fine for simple non-enterprise or pure consumer applications, but it's a no-go for the enterprise. Why? Because when you call Web services directly from the browser, governance is left to the browser - which is another way of saying, there's no governance.

That article goes on to talk about a "service gateway," a fuzzy notion that sounds a little like a web proxy with some security. Even if workable, that still doesn't solve the drip, drip, drip at the heart of Ajax+SOA: orchestrating and composing services is a form of the dreaded Business Logic Leak. You are leaking both data (from the services) and logic (how you are composing them). This past April I described why it was a bad idea:

There are two kinds of information leak -- what and how. "What" is your customer data, your orders, your accounts receivable, your employee database. The "how" is your secret sauce, the special way of pricing or quoting or doing that gives you a competitive advantage. Reports can leak the "what," and many businesses can survive a leak of quite a bit of "what," but leak the "how," your secret sauce that makes you money, and you're cooked. Javascript can leak the "how" if you let it.

Even Tibco will tell you that it's GI product is intended only for the corporate desktop (where the ability to control access to data and logic is much greater) and not for the great unwashed on the open Web.

For the actual service providers there is a risk too. If you publish an SOA interface of some kind (SOAP, REST, etc.), your competitors can clone that interface and undercut your offering. See the Google Maps clone for down under for evidence that this is already happening. Building in switching costs becomes a difficult task which runs counter to the whole principle of SOA.

Finally, cross domain Ajax is still a problem with either JSONP (essentially JSON with a callback function) or a web proxy being the only viable solutions for orchestrating web services across domains in the browser. Right now, Yahoo! is the only major service provider to offer JSONP.

In my cynical view, Ajax + SOA is just another way of saying "mashup" -- a clever if innocuous pairing of two or more web services. And right now, given the nature of things, that's all it will be until the browser platforms change in some major way.

Technorati : ajax, soa

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment