Jaa

On Atlas/Ajax and SOA

  • Artikkeli

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.

Comments

  • Anonymous
    August 20, 2005
    The comment has been removed
  • Anonymous
    August 20, 2005
    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.
  • Anonymous
    April 09, 2006
    PingBack from http://blogs.ebusiness-apps.com/dave/?p=32