I ran across a blog entry that attempts to link Atlas/Ajax to SOA. What absolute nonsense!
The technology, for those not familiar, is the use of XMLHTTP to link fine-grained data services on a web server to the browser in order to improve the user experience. This is very much NOT a part of Service Oriented Architecture, since the browser is not a consumer of enterprise services.
So what’s wrong with having a browser consume enterprise web services? The point of providing SOA services is to be able to combine them and use them in a manner that is consistent and abstracted from the source application(s). SOA operates at the integration level… between apps. To assume that services should be tied together at the browser assumes that well formed architecturally significant web services are so fine-grained that they would be useful for driving a user interface. That is nonsense.
For an Atlas/Ajax user interface to use the data made available by a good SOA, the U/I will need to have a series of fine-grained services that access cached or stored data that may be generated from, or will be fed to, an SOA. This is perfectly appropriate and expected. However, you cannot pretend that this layer doesn’t exist… it is the application itself!
In a nutshell, the distinction is in the kinds of services provided. An SOA provides coarse-grained services that are self-describing and fully encapsulated. In this environment, the WS-* standards are absolutely essential. On the other hand, the kinds of data services that a web application would need in an Atlas/Ajax environment would be optimized to provide displayable information for specific user interactions. These uses are totally different.
If I were to describe the architecture of an application that uses both Atlas/Ajax and SOA, I would name each enterprise web service. All of the browser services would be named as a single component that provides user interface data services. The are at different levels of granularity.
Atlas/Ajax, for better or worse, is an interesting experiment in current U/I circles. Perhaps XMLHTTP’s time has finally come. However, A/A it will have NO effect on whether SOA succeeds or fails. Suggesting otherwise demonstrates an amazing lack of understanding of both.
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.
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.
PingBack from http://blogs.ebusiness-apps.com/dave/?p=32
PingBack from http://blogs.ebusiness-apps.com/dave/?p=32
PingBack from http://blogs.ebusiness-apps.com/dave/?p=32