Tech Ads
Back to Article List
Originally published March 2006 [ Publisher Link ]
Services with Ajax: Why, when and why not
Besides the term SOA, there is perhaps just one more new term that has made itself onto the development lists of many IT departments in the last few months: Ajax. Although the term is more inclined to stir excitement among Web usability and design professionals, it does bring its share of approaches that effectively cross into the realm of service-orientated architecture, some of which we will address in the following article.
The Ajax acronym stands for asynchronous JavaScript and XML. As Web services developers what should concerns us most about this technique is its asynchronous nature, followed by its JavaScript roots which imply knowledge of the environment in which the language is executed – namely a browser – and, a distant last, the visual effects it produces once in operation (not to say we should ignore this last point, but graphical designers are generally more adept at resolving this than programmers).
Asynchronous is a term used to describe the interaction between a client and server where the former does not have to wait – or block, as it is also often called – to receive a response from the latter. Messaging systems such as MQ-Series, Tibco Rendezvous and programming API's like Java JMS were among the first to use the asynchronous concept, but now Ajax is taking the same approach to Web-enabled applications.
The asynchronous concept with Ajax lies in the JavaScript function calls performed by the browser back to the Web service providers or server side application. When you interact with an Ajax application, the capability of updating pieces of information present on the screen without refreshing or reloading all of its content is the behavior referred to as asynchronous, since you are capable of making various calls to the server side without momentarily staring at a blank screen – blocking the client – while the server responds.
Even though it's the Web 2.0 proponents in the form of graphic designers and software marketers who most often use the term Ajax, many of the software written to enable Ajax applications should be done with the same mindset as reusable services.
Curiously, the data provided for an Ajax application need not be bound by the constraints of a Web browser client or the JavaScript language, as matter of fact an optimal Ajax design will surely be bound on the server side to a widely known Web service design approach: REST ( See more on REST on an earlier column REST: Simplicity in Web Services design ).
REST services, created with the intention of providing a simple access point in the form of an Internet URL, effectively mask the server side platform like you would expect of a Web service and offer the simplest design pattern used by the earliest Web services adopters like eBay, Yahoo! and Amazon. They are in essence Internet addresses that, instead of providing complete pages, provide granular chunks of data which can be consumed and generated based on the requirements provided by a client.
Since the life-cycle of an Ajax application is composed of updating particular pieces of a screen from server side calls, REST services provide a natural superset for creating Ajax based applications. So if you have an existing group of REST services, this will make a good starting point for your Ajax applications. Similarly, you are well advised to take the necessary steps to integrate whatever repository you are using for feeding your Ajax applications into a greater set of REST services in order for these assets to be reused in other service-orientated/non-Ajax applications.
On the other hand, being bound to a browser for consuming your services limits you to its environment, so this also has its implications when creating your Web services clients. Where as many Web services clients have the capability of pooling or manipulating data from many different sources, this is achievable because they are constructed from system platforms like Java EE, .NET or PHP. A browser – ubiquitous a platform as it may be – has evolved into a severely restricted environment compared to the aforementioned platforms.
Take the case of combining data from two different Web service providers. This scenario, simple as it may be in a non-browser environment, can prove to be a headache in Ajax applications, the reason for it being cross-site scripting. In an effort to crack down on malicious code execution, a browser is generally constrained to execute code logic belonging to only the site which its displaying. This avoids any unsuspecting requests that may be done in the background to non-trusted sites, but this same process avoids tapping into two or more different Web service providers unless considerably lowering browser security configurations – which is not a good overall IT security practice.
Finally, one more thing to take into account is the JavaScript language used for constructing Ajax applications. Every programming language used for Web applications has come to rely on some sort of framework to ease development tasks and accommodate the very nature of the Web. While many of these frameworks are used on server side platforms, with Ajax being a simple set of individual REST services on the server side, it's not that the functionalities offered by these other platform Web frameworks are not applicable to Ajax applications. Its simply a matter of these design concerns – such as standardizing request or controller classes -- being shifted to the browser. To this end, it's also important to do the corresponding research on the many JavaScript frameworks being developed to ease the creation of Ajax applications.
Ajax is indeed part of the next wave in Web development, but by no means should it be relegated as the Web's new eye candy. As you have probably realized, the implications of a well thought out Ajax design in conjunction with your overall service-orientated initiatives can go a long way in achieving a maximum return on your time and resources. So the next time your development initiatives tackle the effective use of Ajax, try to approach it with the same reusability mantra used for SOA.