Will Rich Internet Apps Catch the Bus?Will Rich Internet Apps Catch the Bus?

Rich Internet applications (RIA) have been the buzz in the applications development community as organizations look for ways to break out of primitive modes of Web services and applications and make better use of the power resident on the client side of most architectural implementations. RIA also are drawing attention as an important step in fusing "thicker" role-based and process-oriented user interfaces with distributed networks. That begs the question: How will RIA fit in as enterprise service bus (ESB) matures to play a central role in service-oriented architecture (SOA)?

One way or another, RIA will use ESB. Put differently, an ESB won't be considered effective if it doesn't support rich applications. Sludgy, blippy HTML page presentations are already unacceptable; soon, rich media (video, audio, animation) will be expected. An ESB will need to step up and make rich applications possible. But given where things stand today, how will this happen? Will user interface components ride inside the bus or hang like bags on the side?

Most ESB descriptions don't include significant user interface elements, although there is room for them. In theory, there's no reason why an ESB couldn't provide flexible distribution and utilization of UI elements, such as presentation engines, to improve performance. An ESB could even promote standardization of UI components and provide messaging services for UI activity. What RIA may look for most in an ESB is better information flow: that is, providing data dynamically and quickly from any source. That's a necessary condition for the success of a rich application; a fancy UI means little if it takes too long to access data.

At the moment, ESB and RIA seem to be running on different development tracks. However, a common ground does exist: SOA. Not surprisingly, SOA is the direction for vendors active in both development tools and middleware — from giants such as IBM to the smaller, more specialized companies such as Cape Clear. ESB providers are focused on SOA to enable standards-based integration. The RIA community cares about SOA for structure because Web services will be a primary means of delivering rich applications.

The emerging SOA environment provides a clutch of standards, especially those involving XML, that are important to both ESB and RIA development. The expression "birds of a feather flock together" applies, because the tools for developing ESBs will eventually converge (or cohabit) with tools for developing RIAs. One of the hotspots for this convergence is Asynchronous JavaScript and XML (AJAX), which uses capabilities of XML, JavaScript and DHTML to provide a browser-based environment with the desktop application experience users expect. AJAX is a good fit.

As a Cape Clear executive put it, "A lot of the principles around AJAX, namely its asynchronous model, are similar to the ESB model."

Although true to its habit of repackaging and renaming standards, Microsoft is showing it's serious about SOA, ESB and Web services in its emerging Windows Communication Foundation (WCF, formerly known as Indigo), which is a key piece of Windows Vista. WCF hooks up with Microsoft's most ESB-like products, in particular BizTalk Server. The company's newly invigorated embrace of AJAX shows in its forthcoming Atlas software development tool.

While AJAX, Web services and SOA are most often mentioned in the same breath, AJAX is not the only game in town for RIA. More proprietary approaches such as Adobe (Macromedia) Flash and Flex products have been doing RIA for years, and in recent versions Adobe tools have embraced Web services. Another example is TIBCO Software; it's BusinessWorks provides ESB components, such as Web services, XML, SOAP, UDDI support and other elements that developers can employ for UI management. The BusinessWorks engine can mediate between XML schemas and formats by using the Extensible Stylesheet Language Transformation (XSLT) standard.

XSLT is an important part of how organizations may bridge ESB and RIA. XML manipulation is notoriously resource-intensive. XSLT engines that, for example, translate UI descriptions from one application to another can develop into a server performance drain and throughput bottleneck. With an ESB, organizations can deploy the transformation engine as a service in its own ESB container; you can load balance multiple instances across many machines.

This is not to say that ESBs will become the sole repository of presentation elements. A lot of the UI functionality will remain in the client, and the balance of client and server elements will continue to be an ever-changing mix. Web and application servers will continue their role of providing the presentation layer for many applications. Nevertheless, ESB strengths play to some of the most critical demands of RIA. It's almost a sure bet that in the next year or two, at least some presentation elements will be riding on the bus. — Nelson King

Nelson King is a 25-year veteran of the coding wars. He has written nine books on application development, and his tool evaluations are widely published.