News
Improve Business Productivity With AJAX and SOA
AJAX rich Internet applications (
RIAs) on clients and service-oriented architecture (
SOA) on servers are combining to produce more effective business software. There's a learning curve, but commercial AJAX toolkits are helping to make it less daunting. So said Kevin Hakman,
Tibco's director of developer evangelism, in his talk, "
How To Get Richer Faster With an Ajax and SOA Strategy," which he presented at the recent AjaxWorld conference in Santa Clara, Calif.
AJAX (Asynchronous JavaScript and XML) lets you update Web pages incrementally. This approach improves Web site performance enough to support RIAs that look and perform like desktop business applications, but only have enough code on the client to maintain the user interface (UI), with data and state information mostly residing on the server.
Users and their companies benefit from such software, but it does present programming challenges. That's where commercial AJAX toolkits come in. Hakman was involved in the development of one such toolkit, now called Tibco General Interface (GI), and his talk centered on how you can use toolkits like GI to develop AJAX RIA apps.
The GI Framework
Hakman started his talk with a pitch for his company's toolkit entry, Tibco GI, saying that it doesn't require a server component, and works on top of any infrastructure. Hakman characterized GI as a kind of custom application development environment built on top of SOA. It's an open source AJAX toolkit supporting the development of stateful, event-driven RIAs with the look and responsiveness of desktop apps.
The GI Framework comprises a set of runtime libraries built on an object-oriented JavaScript (JS) foundation. Six libraries provide data caching, communications, data bindings, publish/subscribe events, logging and debugging, and graphic user interface (GUI) components -- all available through an open source BSD license.
How AJAX Came To Be
Hakman contextualized the discussion with some history, going back to the time of mainframes and dumb terminals. Back then, software was easy to deploy but feature poor. With the advent of client-server systems, there was a gain in features but a loss in ease of deployment. However, the general evolution of HTML pages -- moving to AJAX pages and now to AJAX RIA -- has enabled developers to produce feature-rich software that's also easy to deploy.
The original HTML page was a good start, Hakman said. However, the page-based paradigm is based on taking the user to the data, when what you really need to do is take the data to the user. He added that much of current AJAX development still consists of enriching existing HTML pages, which means sticking with the good old three-tier paradigm.
For an example, he cited Google Adwords, which uses a partial page refresh with HTML from the server. On the other hand, the Yahoo Mail! beta provides a full stateful client with messages, he said. He also showed screens from apps using a true client/SOA paradigm (all powered by Tibco GI, coincidentally) used for drug research, integrated services in a call center, stock data, GPS chat and business process management.
A plethora of AJAX libraries has evolved to support everything from simple communications to full desktop GUIs. However, these libraries still center around two paradigms:
- Enriched HTML "AJAX pages," aligned with three-tier models; and
- AJAX RIAs in the client, aligned with SOA on the server.
Hakman cited the OpenAjax Alliance as a good place to look for vendors and projects.
Application Demos
Hakman showed a utility call center application built with Tibco GI and Dojo Offline Toolkit (for creating offline Web apps). This is a mashup -- what used to be called a composite app, an application that transparently integrates data from multiple sources. For example, the call center application Hakman showed integrates information from customer service, field service and financial systems, composited into a single GUI. This app provides end users with a 360-degree view of the customer at the point of service. The app sets up a bus to let the apps with the data talk to each other, putting a call center agent on top of it.
You initialize the app, load up the classes; you can do sorts and re-sorts. The app sends out five different queries to five different services and then aggregates the results -- all organized in chronological fashion to support customer interactions and all running in a browser. If you want to schedule a field request, it tells the user the available dates. And you can drag something from one app into another window of another app.
Next Hakman showed a drug matrix used by FDA drug investigators. Its architecture resembles a thick client in the Visual Basic world, with 180 modules that a single HTML page can load and unload. It requests information from a variety of sources while allowing users to interact with the software while waiting for data to load. Even using client side vectors, it can load numerical data from the client side data cache, which gets sent off to the server to persist. You can do drag and drop interactions which it also sends off to the server.
Then Hakman showed an app used by railroads that uses GI along with Tibco Business Events. The app collects, filters and correlates relevant events to deliver real-time operational insights. It provides a real-time, zero-install dashboard for monitoring rail traffic and system load. A key use is to determine when and where to swap train engineers. The problem is that engineers aren't permitted to drive trains more than eight hours. Moreover, if they have to go off shift in the middle of nowhere, it creates costly work stoppages. The application uses Adobe Scalable Vector Graphics to render a map of the United States with Union Pacific Railroad's routes superimposed, which plugs into the browser, alongside charts powered by the GI kit.
The last product demo showed an app used by the Marine Corps for battlefield support. This app was built several years before Google Maps let you drill down geographically. It combines real-time GPS data points rendered on top of a map combined with all known information about the area.
Reasons to Shift to AJAX RIA/SOA
After the demos Hakman went into more detail about the shift from traditional Web page architecture using static HTML pages to AJAX RIA architecture with client-side processing and SOA. He pointed out that there's a clear synergy between them because AJAX RIA is optimal in consumption of services. This architecture distributes processing to the client, whereas other approaches rely on server generation of presentation.
He added that there's also a blended model, usable when the client framework can support it without server dependency. This can be done within an HTML page or within multiple portlets.
The evolution to RIA/SOA brings half a dozen key changes to the old three-tier model: from homogeneous to heterogeneous; from language dependent to independent; from centralized application tiers to massively distributed services; from code-centric apps to flexible composite ones; from a simple request/reply-driven model to one that uses pub/sub and events as well; and from HTML pages to AJAX RIA apps.
Hakman claimed that the RIA/SOA evolution provides a new level of solution manageability for business solution developers. The RIA/SOA model provides unified messaging through a service bus, in which you publish/subscribe real-time data -- events and messages. Tibco has productized this concept with something called PageBus. The shift to pub/sub enables two-way events.
With RIA/SOA, developers can create services with different development environments, such as Java or .NET, and have them all play together nicely. One protocol useful in an RIA/SOA environment is HTTP data streaming, known as "Comet" in AJAX-speak, which Hakman said is scalable and firewall-friendly.
You also get local data persistence. According to Hakman, local JavaScript data stores for offline use are coming, but "the reality is that this will create demand for data synchronization services." This resembles the challenges of OCC (occasionally connected computing) client-server apps. Either way, coding for apps where the client isn't always connected is still nontrivial, but it does leverage message queue architectures consistent with messaging architectures.
Another advantage to RIA/SOA is that you can distribute services across many servers while administering policy centrally to govern rights, restrictions and software license agreements.
RIAs can communicate directly with point services or to the service bus. The upside to this approach is that it enables greater reuse of service assets, increased scalability and higher performance Web app GUIs. The downside is a potentially mind-boggling heterogeneity of services, locations, protocols, APIs, formats and policies. Hakman said a service bus helps you get a grip on all of this because events and messages flow across systems subject to policies. He concluded his talk by noting that Tibco GI was designed to work well with an enterprise service bus architecture.
About the Author
Lee The's first computer was a state-of-the-art unit with 48K RAM and a 1MHz processor. He has been writing and editing computer magazine articles since then, in between scuba diving trips. He's based in the San Francisco Bay Area.