On Atlas/Ajax and SOA

re: On Atlas/Ajax and SOA

Dion Hinchcliffe — Sun, 21 Aug 2005 01:27:58 GMT

Hi Nick,

Thanks for your comments about my article. I did take care to point out that Ajax may inadvertently drive SOAs, not intentionally drive them. And usually in a way that IT departments will not intend or want. I agree that SOA services are more course-grained and document-centric than Ajax application would generally prefer, but that certainly doesn't mean that many people won't try to use them from their Ajax apps, and then blame both Ajax and SOA when it doesn't work.

Organizations will likely end up providing one set of web services to support Ajax apps and different ones to support SOA orchestration and coordination (even though they'll often lead to the same place).

But the nuances of this will be lost on most folks (as it was apparently lost on you), and the result will be that Ajax will often hijack SOA services as folks publish web services that then end up flooding back end systems with UI load.

It's a governance problem in the end and organizations with immature or purely technical SOA efforts will feel the pinch I think.

And yes, Ajax applications will have to interact at some level with an organiation's SOA, even if just to drop data into a business process pipeline, it is about integration and intermediation in the end.

re: On Atlas/Ajax and SOA

NickMalik — Sun, 21 Aug 2005 10:23:33 GMT

Hello Dion,

You failed to catch my point entirely, I'm afraid. Web developers will not be able to use SOA web services. It won't be possible. You see, the services that web developers will attempt to use will need to be called by a client browser, either on an intranet or an internet. The SOA service won't be available on the Internet, and it won't be available to the person in the intranet.

In my wildest dreams, I wouldn't consider giving access to an enterprise web service directly to an end user. Within the walls of Microsoft, attempting to put something like that onto a production server wouldn't make it past either the Architecture review or the Security review. Dead on arrival.

To say nothing of the fact that it wouldn't work. You couldn't MAKE your app work using an enterprise service from a browser, not matter how hard you try. Developers are in the habit of delivering working code. If they hit a wall, they go around it. In this case, they would put in an application to consume the service and present the data for human interaction.

In other words, it is simply not possible. Not that it would make sense anyway.

No, internal IT departments will have NO difficulty with hijacked SOA services.

Governance is necessary, of course. Security audits and architectural reviews don't occur in every organization. However, the fact that any service intended for browser consumption would not be USEFUL for a SOA would quickly differentiate the two.

There would be no "swamping" either way, any more than there currently is. For the most part, A/A interactions get less data than current web apps do, since they can put some into memory on the client and re-use it. Therefore, if their current infrastructure is capable of handling the browser to server traffic, then introducing Atlas will have no negative impact whatsoever, because existing apps will be used less as the Atlas apps are used more.

Beating a Dead Horse: What's a SOA Again? All About Service-Orientation...

Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems — Sun, 28 Aug 2005 18:02:08 GMT

The Connection Between XML Web Services, Service Orientation and AJAX

Dare Obasanjo aka Carnage4Life — Fri, 09 Sep 2005 16:53:06 GMT

Dave Johnson » Blog Archive » SOAJaX: Where SOA Stops and AJaX Begins

Dave Johnson » Blog Archive » SOAJaX: Where SOA Stops and AJaX Begins — Sun, 09 Apr 2006 18:19:08 GMT

PingBack from http://blogs.ebusiness-apps.com/dave/?p=32