Businesses today must be able to embrace changing markets faster than their competitors, without being limited by their technology infrastructure. The ability to ensure rapid implementation of new and existing applications to meet new business demands is the key. Ajax technology is one way to achieve a Rich Internet Application. This article clears some the misconceptions surrounding Ajax technology and the practical functionality it has over older and outdated languages.

Introduction
Ajax, or Asynchronous JavaScript XML, communication offers a lightweight approach to integrating applications in portals, traditional clients with an HTML browser and mobile devices. The principle of Ajax is straightforward – snippets of JavaScript code are embedded in pages and communicate data back and forth. It is thus transparent to the user that a hidden frame or a JavaScript communication object is used to transfer data. As much has been said about the popularity of Ajax in relation to developing enterprise-wide web applications, the following section discusses four commonly asked topics on Ajax, which include:

• Is Ajax only hype?
• Ajax @ work
• Ajax and a return to the fat client
• What is behind Web 2.0?

Is Ajax only Hype?
Hype needs a defining moment – a killer app! Google is a trendsetter – GoogleMail and Google Maps are two applications that are attractive to use: a mix of ‘I want to see’ and ‘I need to use’. And hype does require a real need, a shared awareness of a problem. For Ajax, this is the span between the ‘reach’ and ‘rich’ aspect of a user surface (loosely taken from Gartner). Classic browser applications are easily accessed via URL and show users quite clearly that their interactivity is determined by the underlying HTTP protocol – pages are permanently built in the browser, with browser applications ‘flicker’.

Hype also needs a certain history. The technology should have the attribute of being ‘mature’. It should be widespread and well tested. This is true in Ajax’s case. It is based on browser technologies (JavaScript, HTML) that have been known for years. This sentence is a nice illustration: “We have been using Ajax for years, but we just didn’t call it that.” This incites a bit of annoyance, as the anticipation of Ajax has never really been properly valued. On the other hand, without the anticipation, there also would not be any hype in many individual locations. There has to be enough developers who immediately understand, almost by instinct, what it is all about.

Now that we have the Ajax recognition, we can undertake programming in standard browser surfaces. We have a programming language (JavaScript), we can render (HTML controls) and we can transfer data from a browser to a server and back again with the aid of certain communications objects or ‘hidden frames’. Considered dispassionately, you can use Ajax to program surfaces from server-based applications just as easily as Java, Delphi, and Visual Basic.

All the same, a completely dispassionate consideration only allows for comparison with a touch of goodwill. In comparison to UI programming, with structured, objectoriented
programming languages, using JavaScript with direct programming is not recommended. It begins with characteristics of the language itself. The dynamic typing concept is always an open door to run time errors – and the way in which object oriented programming is implemented is truly labour intensive. It goes on with the fact that access to HTML objects is, indeed for the most part, standardised via the W3C. It has, however, been made easy to programme for a certain type of browser only. Furthermore, tool-support for JavaScript is archaic: The alert() message as a debugger replacement is the daily bread of a JavaScript developer.

In short, Ajax programming based purely on ‘HTML and JavaScript’ brings with it a high fun factor from the development perspective but is indeed something for professionals and calls for some real experience! In order to make Ajax more accessible there is now a range of frameworks.

Among these are JavaScript libraries that make abstract controls in the form of JavaScript objects available from the browser. The user must set up and characterise these controls from his or her JavaScript programming. The insides, meaning the rendering and eventing in a DOM tree remain hidden behind the interface of the controls. The libraries are now springing up in droves – causing the call for unification to only become louder. As every library depends on its own defined environment, its reputation is dying out at the moment. Retrograde communication is likewise being made available via abstracted objects. For example, it is possible to transmit SOAP Calls directly from an Ajax programme.

In the area of frameworks you often find a generation procedure that constructs an Ajax page from a layout specification. This means JavaScript is not needed at all from an application developer’s perspective. A page to be displayed is created, for example, from an XML definition and communicates its data content to an appropriate object representation on the server page during run time to which application editing is attached.

The www.ajaxmatters.com page contains a nice collection of links to various products and libraries – and to all the news in the Ajax world.

Ajax @ Work
Ajax supplies desktop-user quality in a browser. This makes Ajax attractive for all applications for which ‘cost of ownership’ of the client installation is relevant. The typical decision-making process for Ajax is thus: for a plan, the interactivity of classic web frameworks, in which pages are repeatedly brought from the server to the browser, is insufficient. Three alternative approaches are then up for discussion. First, the explicit installation of a client by the user, for example, supported by Java WebStart; second is the use of plug-ins in a browser such as macromedia plug-ins or third, the use of own, original browser technologies like HTML and JavaScript, that is to say, Ajax.

The disadvantage of the first approach is the somewhat slow and complex installation. Furthermore, an explicitly installed client does not run in the browser but as a parallel application, meaning that it cannot be integrated with other browser applications. The second approach is often criticised as it makes use of a proprietary plug-in concept. The Ajax approach promises a real integration into the browser, meaning a complex application can be directly reached over a URL. The following section discusses the Ajax applications, which are currently viewed as a lot of hype.

First, there are applications dealing with geographic information, with Google Map and Microsoft Virtual Earth as the most prominent representatives. Huge volumes of data from satellite pictures are portioned into little tidbits the user wishes to see. Access is via comfortable navigation. These days, there is also a large selection of applications based on the core applications such as, for example, real estate agent systems in which one can view, by satellite, property offered in the same area.

There are also applications dealing with aspects of mail processing. In this case, the most prominent representatives are Google Mail and Zimbra. The former, in particular, stands out thanks to its very attractive surface that portrays all that is possible in an Ajax environment. As usual for mail clients, there are supplementary applications such as calendar management, contact management, and others. Mail applications increasingly play a ‘killer’ application role. Everyone needs them and every mail service provider must offer them; besides, user satisfaction with classic web-mail clients is very limited.

A growing trend is the editing of texts directly in a browser as the starting point for small office applications. The assumption of the ‘writely’ tool by Google leads one to think that Google will once again be a trendsetter in this area. In the meantime, there are also a number of manufacturers of WYSIWYG editors in which the user can create HTML texts directly in a browser. The online office applications naturally cannot keep up with their big brothers in terms of functions but they do have the potential to assume the role of ‘everyman’s office package’. Furthermore, they can offer further services such as memory, versioning, and document administration on the server right up to collaborative document editing (say hello to Wiki!), as they are server-based constructions right from the start.

Finally, there is the market for classic company applications – from bookkeeping to logistic systems. In this case, it is simply about bringing an application to the end-user affordably and with high user-quality. As a rule, these are intranet applications and therefore are little known by the general public. In particular, Ajax is attractive for running applications in application service provider mode (ASP) – a service provider provides the application and it is operated over the user’s browser.

Ajax is now seen as technology hype in the eyes of the public and it just finding its feet with users. Every day, there are new applications ranging from little tools to complex applications. Time is working in Ajax’s favour. The existing hunger for resources of JavaScript-based browser editing is being met through more powerful hardware. The demand to find a browser on the client’s side may create problems in exceptional cases while the frameworks simplifying Ajax development will continue to improve.

Ajax and a Return to the Fat Client
There was a time when complex software systems were operated via green-black terminals. These were very limited in terms of their presentation and interaction abilities. Then at the end of the 1980s, a graphic user surface celebrated its victory – good-looking and interactive. Programming became simpler through environments like Visual Basic and Delphi – and once the surfaces were developed, a large part of the application logic was directly attached. From the ‘thin client’ concept of the host environment, the ‘fat client’ concept desktop applications were developed.

Today, history seems to be repeating itself, even if with new buzz words and slightly different circumstances. Today, classic HTML pages are not giving the user what he expects from a modern user interface. Now, it is Ajax-based pages that are attractive and interactive. The new freedom of being able to develop within the front-end has led to an enormous release of creativity in UI development. At the risk of being a heretic, as one was able to develop an ODBC databank with Visual Basic in the 90s, today one can programme any SOAP interface with JavaScript.

Are we then experiencing a renaissance of the fat client? A client who is not only responsible for the appearance and the user interface but also brings along a lot of application logic? This is the case now. Driven by the Ajax UI hype, many systems will develop in which the client is far too ‘fat’ because it is so easy to build in the one or the other JavaScript routine that carry out logic within an environment where the client really does not belong.

Let us take the example of setting up an order. It would indeed be nice and interactive if, when the ordering position is entered, the complete price of the order was calculated. With a little JavaScript and a SOAP Call to the server, the article with price data is collected from the browser, calculations based on order sizes are carried out and the price of all ordering positions is added up. Then there are also customer-specific rebates for a specific order quantity so that one can also call up the client base via SOAP Call and calculate it in. Then factor in freight and delivery charges.

Hence, it does not take too long before an interactive front-end becomes a complex, JavaScript coded application programme that runs in the browser. All the known problems from the 90s are catching up with us. Competing application logic between the client and server as well as a substantial exchange of data between the client (browser) and the server with running abilities under WAN conditions that are difficult to control as the latency period of a round trip does not lie in the millisecond range.

A clean architectural definition of role distribution between browser and server-side logic is therefore of primary importance for all Ajax plans of any real size. There are two tendencies on behalf of the framework provider: Ajax Control Libraries providers completely relinquish architecture definitions to using developer along the lines of: Build your UI with the assistance of the controls made available and connect it to the server side logic via SOAP Calls. Other providers directly connect their controls to server-side processing. A page over which Ajax Controls is built has its server-side representation, for example, as a Java-class that more or less serves as a ‘net image’ of the user surface. A field on the page is represented by a property in the Java-class or a button on the page through a method in the class. Between the browser-side processing and the server-application processing, there is blocked communication, meaning the page collects data changes through user inputs and sends them to their server-side representations at certain synchronising points, in time where actual processing occurs. Through this method of separation between browser and server, the application logic remains entirely on the server side, the browser client is only used for optical preparation and input processing.

Whichever way you decide to go and all Ajax euphoria aside, it is advisable to pause for a moment. Otherwise you will also become part of a new, undesired ‘fat client’ generation.

What is Behind Web 2.0?
Be casual when using big words so that nobody listening dares to question you! This has been the sentiment behind the expression ‘Web 2.0’ in the Ajax environment, particularly when it comes to describing one’s products as ‘Web 2.0 compatible’. But what does it mean?

Today, technologists and developers alike seem to have problems approaching Web 2.0. One looks expectantly for a technology standard, an API specification. An Internet search comes up with protocols from conferences, blog entries in all shapes and sizes, analyst reports and descriptions of patterns. All contributions avoid a clean definition of the term. Quite to the contrary, a cloud of diverse technological definitions (with Ajax always in a prominent position!), the social aspects of cooperation (online collaboration etc.) and case examples (Wikipedia, GoogleMap) are created in the middle of which Web 2.0 is to be found.

‘Web 2.0’ is a term that covers everything relating to a certain perspective. This perspective shows the direction in which the Web and its participating software will develop.

First let us take a look at the core aspects of this perspective and how they are based on a concrete problem. Imagine that you want to write a bug tracking system and sell the software. What does Web 2.0 have to say about that?

‘Rich user experience!’ The UI must be running in the browser. It must not just serve up classic HTML pages to the users but instead let them have a little fun at work. It should feature drag user-open bug notifications from a list and allow them to drop in the workspace. There must be room for comfortable text input and output. Users should be able to move columns around as they wish. The technology for this is Ajax. While your users may not really need this, your competitor will introduce them to it.

‘Collective intelligence!’ Trust your end users. Consider how you can combine their creativity in your problem areas – to the advantage of both. For example, your users have, in the meantime, learned that one’s problem should often be shared with others and they have shown that they are very happy to cooperate on the basis of shared problems even if they do not know one another or are competitors. The frequency with which a bug report or technical question is dealt with more quickly and better via a forum is a case in point. High quality knowledge is collected and shared over Wiki-type systems by a collective. Consider then how you can creatively tie in the end users of your bug tracking system. You may want to reward users who help other users!

“Think in terms of services, not packaged software!” For starters, make your information available to others as a service. There are lots of people that want access. The solution to a problem should be made available by search engines as soon as possible. Partners should be integrated directly when there is a solution for a problem for end customers conduct a Google search when a solution is sought for a reported problem. Use the technical standards (web services, RSS, and such) to present yourself as an open service and tie in other open services.

A proposition – how should a customer who wants to use your bug tracking system access this software? As a package to be installed or as a service from the Net? Do you want to provide periodic upgrades to install or offer a service package that takes over running the software for the customer? Do you believe that GoogleMap would have been successful if availability had not been behind the application as part of the service, from gathering satellite images to running the hardware and software?

Sit back and observe the software systems you are building today. A bug tracking system develops into a community communications system. In what direction can you develop your software system? If you are of the opinion that the Web has developed from a document publishing to a peer-to-peer communication platform and is now on the way to becoming a collective collaboration platform, you at least are Web 2.0 compatible.

Moving Forward with Ajax
As organisations continue to explore ways to implement Ajax, they need to know that Ajax is not about adopting the latest technology or following the latest IT fad. It is about using technology to respond to specific business and IT needs. Ajax is the user interface concept behind the next wave of Internet applications and is particularly suitable for desktop-like interactivity in the browser. While Ajax as a technology can help to accelerate and simplify the design and deployment of rich internet applications, one has to note that it still needs to be supported by a framework in order for application developers and other IT professionals to make good use of it.

About the Author

Bjoern Mueller is Director of R&D, crossvision at Software AG. In his current role, Muller is responsible for developing Ajax based User Interface Framework. Prior to Software AG, Mueller founded Casabac Technologies in 2001, a company focused in the area of browser based Rich UI Frameworks and provider of DHTML framework. Mueller started his career at SAP where he has spent 10 years in application and technology development.