Introduction

Ajax

Ajax (Asynchronous JavaScript and XML) means many things to many people. However, one thing is certain: To users it implies a higher level of functionality and an improved experience. To the developer, another certainty follows: More work. The only question is how much work and to what end.

There are at least three separate tracks to consider: Communications and messaging, user interface components, and client side scripting. Since in the Ajax world the server no longer sends down html to the browser, your developers need to agree on a message format. The user's expectations of a dynamic UI are high. They want a desktop experience and Web simplicity. You will need to develop or obtain components to meet many requirements: Legacy integration, micro-content, predictive fetch, drill down, visual effects, specialized and generic UI widgets.

Finally, your developers need to integrate all of the above and inject your organization's value add and business rules.

You can start by downloading random chunks of JavaScript and integrating them with the browser's XMLHttpRequest object using Notepad or vi as the main productivity tools. Certainly five years ago this was the case. Some organizations produced great work; others produced un-maintainable hodgepodges unreadable to all but the original authors.

Where GI fits in

Alternatively, you can take advantage of mainstream adoption of Ajax by leveraging others' work. TIBCO Software's Ajax tools, known as TIBCO General Interface and "GI" for short, provide a solidly engineered set of JavaScript libraries to power Ajax solutions. In addition the GI libraries also power the visual tools TIBCO provides for rapidly authoring these solutions. GI's individual JavaScript class objects are integrated into a unified framework that executes at the client, not the server, using MVC principles to generate and update the GUI. Accordingly, DHTML and JavaScript generation occurs using the client CPU, not the server CPU. The Ajax framework is comprised of a well thought-out class structure that provides an intelligent abstraction of the browser event model, a wide variety of UI components, a client-side data cache and a service architecture for messaging.

Solution Objectives

Below we will examine in detail how GI MVC running in the client works with Spring MVC, a leading Java server framework. You will see how GI can extend and coexist with your Spring JSP investment.

Before we jump into it lets review the technical requirements of this use case. Application owners and developers alike predictably want to increase productivity and reduce time to market. This type of rapid implementation gives us several imperatives:

    •     No wholesale replacement of our Spring investment.
    •     Incremental change of existing server code as opposed to wholesale change to, for example, SOAP            Web services
    •     Continued support for non-Ajax clients
    •     Re-use of existing code wherever we can. Develop the GI application along side the JSP layer.

Since GI generates the view at the client, Spring need no longer generate HTML at the server. Instead, we'll modify our Spring configurations such that Spring can also return raw data in form of XML that can be consumed as a service by the Ajax processes in GI.