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.
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.
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.
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.
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.