« In-game advertising: ready for prime time? | Main | The Indian vegetarian's rant »
October 04, 2006
Is Ajax appropriate for the enterprise?
Ajax, the catchy moniker coined for Asynchronous Javascript and XML content rendering technologies, is de rigeur in the Web 2.0 wave of online innovation. The more savvy users on the Web today are close to expecting Ajax as a given in the Web services they use. When they go to work and interact with Web applications on their corporate intranets, they may start expecting to see Ajax there as well. Is Ajax as appropriate for the enterprise as it is for hundreds of consumer-facing Web services? The answer: except for a few cases, it won't take the enterprise by storm.
Before we examine why, it is a good idea to take stock of the Ajax development scene today. After a heady 18-month period of growth, which has seen the release of tens of self-styled Ajax development frameworks, some winners are beginning to emerge. Enterprise adoption lags consumer-facing adoption by a little because Ajax frameworks for enterprise-grade environments are coming out of the woodwork only now. ICEFaces for Java Enterprise Edition was released in July this year, whereas Microsoft's Atlas framework is slated for an end-of-year release. Once a few Ajax bindings are available for the most common enterprise development environments, enterprise decision makers will be less guarded about Ajax adoption.
Ajax, unsurprisingly, is particularly suited for the majority of intranet applications that are delivered over the Web today. These typically include firmwide applications with a significant self-service component, such as employee performance evaluations or corporate travel booking. Portals too are suited for eventual conversion to Ajax. Not all enterprise applications, however, are suited to delivery over the Web (notably time-sensitive applications such as a real-time securities pricing and trading system, or multimedia applications, where a rich design and visualization experience is key). If these applications are wrongly delivered over the Web today, adapting them to use Ajax might prove to be a needlessly complex endeavor.
Ajax applications can lead to improperly authorized information disclosure in an enterprise environment. Many enterprises where the flow of information must be strictly controlled operate, for better or for worse, on a doctrine of security through obscurity. If an employee doesn't even know about the existence of resources they are not authorized to see, it is less likely they will see them. Ajax applications may thwart this objective because they are easy to reverse-engineer, thanks to the browser's pesky View Source function. Unless the Javascript source code in the browser is well obfuscated, sensitive details may well be downloaded and captured by insufficiently authorized roving eyes. The solution? Concentrate as much logic as possible on the server.
Wouldn't it then be a shame to move to a model dominated by thin-client Ajax applications, as desktop computers continue to gain processing power in their multi-core motherboards? There is something about concentrating logic on a server that seems to run counter to the spirit of virtualization, a direction in which a lot of enterprises are moving today.
Ajax toolkits in an enterprise setting might even prove too restrictive. Enterprise environments tend to be controlled, which means that application developers can make many more assumptions when developing applications for internal use. Security restrictions commonly associated with downloading and executing code external to a host are relatively lax inside an enterprise environment, due to a clearer demarcation between trusted and untrusted sources. These additional assumptions can be exploited judiciously to provide a computing experience that can be at once rich and effectively distributed between clients and servers. A Web browser's standard code execution safeguards are more likely to encumber a rich user experience than facilitate it.
Ajax applications may generate pages that are harder to index and discover in an enterprise search engine. As we have seen before, nowhere is the need for search bigger than within an enterprise full of information workers. Because they are more responsive to user actions, pages generated by Ajax applications are likely to fall under the purview of the Deep Web, an area in which current search engines publicly acknowledge their shortcomings.
Ajax frameworks undoubtedly have their place in an enterprise setting, especially in those applications that resemble consumer-facing Web services where Ajax is used successfully. Before latching on to Ajax to be buzzword-compliant, enterprise architects and decision makers would be well-advised to examine whether Ajax is really right for their situation.
Posted by Vishy at October 4, 2006 12:51 AM