Rich Internet Apps To Tie SOA To Desktops

In 2005, Rich Internet Apps (RIAs) will be an important key to unlocking the power of end-to-end SOAs, says Scott Cranton, an IT architect and consultant. See how RIAs will bring "loose coupling" between desktops and middle-tier services, and forge the crucial "last mile" link between PCs and next-gen SOA back office apps.

Tags: RIA, Client, Applications, Enterprise, SOA, User Interface, Deployment,

Director of Product Strategy,
Nexaweb Technologies
In 2005, enterprise IT pros will begin to unlock the secrets about how SOAs (Service-Oriented Architectures) can be used by enterprise IT to design, reuse and deploy new services.

But, even as IT pros learn more about how to tap into SOA's full benefits, 2005 will also mark the time when they will run into the next SOA hurdle — bridging the "last mile" from the back office to the individual end user. We see it this way:

Just as telcos in the late 90s fell in love with providing broadband Internet services, but ran into the problem of connecting the end user's household to their high-speed network pipes nearer the central office, SOA-loving enterprise IT pros will fall in love with the integration-enabling power of SOA for the back office and mid-tier, but find inefficiencies in exposing SOA apps to their end user client systems.

To bridge this "last mile," enterprise IT will look to Rich Internet Applications (RIAs) to provide an equivalent level of loose coupling between middle-tier services and the end-user's desktop. We define RIAs as the mid-tier-to-client complement to SOA, and, when combined with SOA, will provide a consistent way to design and deploy loosely-coupled solutions end-to-end across the enterprise.

How RIAs Will Efficiently
Tie Clients Into Backend SOAs

As is stated in the article, "Demystifying SOA for Architects, Devs" SOA is defined as "an architectural philosophy that promotes the development of applications not as single units with tightly coupled business logic but rather as loosely coupled services, each of which perform a logical, discrete, business function."

RIA, as an application category, represents a loosely-coupled presentation tier that provides a highly interactive user interface (a characteristic widely known in the client/server application world), with lower deployment and management costs of Internet applications.

First, let's answer two important questions:
(1) What are Rich Internet Applications? and
(2) How do RIAs operate in an SOA context?

All RIAs use some sort of client running on the desktop - originally this class of applications used the name "Smart Client" or "Rich Client".

Analyst firm ZapThink defines the requirements for RIA in the enterprise as follows:
  • Rich User Interface;
  • Two-way, synchronous and asynchronous messaging;
  • Integrate local and remote sources of data and logic;
  • Disconnected and connected modes;
  • Loosely coupled presentation and business logic;
  • Client access without install; and
  • Multiple web browsers and OS support

  • The following table compares and contrasts existing application approaches used to create applications front-ending SOA. What starts to become evident is that RIAs can define a "best of both worlds" from both traditional client/server and conventional web (HTML) clients. The richness and functionality of client-server applications with loose-coupling and low deployment costs associated with web applications.

    A growing number of F1000 firms are exploring RIAs. Among them: EMC (which has built an Internet-based management console for their storage devices); The Sheraton and Best Western hotel chains (which both use RIAs to manage customer satisfaction and hotel property management), and several large financial institutions (which are using mission-critical, yet browser-driven, Forex [foreign exchange] trading apps).

    Most enterprises have many operational applications that are used on a daily basis that effectively handle the maintenance and feeding of core enterprise business processes.

    These applications require a highly interactive, responsive user interface which enable users the quickly and efficiently perform tasks, especially those that involve interacting with customers via phone, or handling time critical operations, such as financial trading where seconds can represent millions of dollars.
    RIAs are deployed within application servers, typically J2EE, and can all interact with Web Services, JDBC and middle-tier business logic.

    What differentiates RIA vendors is their choice of implementation technology and overall design decisions as described below.

    3 Choices in the RIA Marketplace
    The RIA sector is already rich in choice. There are three basic architectural approaches that RIA companies use: (1) proprietary plug-ins [Flash], (2) HTML/JavaScript/DHTML, and (3) Java/VM based. Let's take a quick look at each one, and in what user scenario they offer the most value

    1. The Proprietary Plug-in Approach is best represented by Macromedia Flex, which uses Macromedia's Flash engine. A version of Flash [Flash 5] is shipped with most versions of Windows making it almost universally available, though Macromedia's new Flex product does require a newer version of Flash [Flash 7] to be installed.

    Flash enables RIA developers to create very rich user interfaces given Flash's heritage as a "movie engine." To date, Macromedia has targeted Flex for three use cases: guided selling, guided forms, and dashboards - primarily consumer facing or data visualization applications. Flex applications can access Java and .NET objects running on the server, but are limited in their ability to access client-side resources.

    2. The HTML/JavaScript/DHTML Approach is most used by developers looking to build applications themselves - Google's Gmail is an example of what can be done with this approach. It is also used by companies such as Isomorphic and JackBe. The core idea of this approach is to use the existing capabilities of the web browser to provide the widest range of support for client types, making it well suited for consumer facing applications. In general, this approach will require the download of (potentially large) JavaScript libraries to compensate for the differing capabilities of the client browsers. The resulting applications are as rich as the underlying browser will allow.

    3. The Java/VM Approach consists of a browser-hosted client, using either Java or .NET, which interacts with a middle-tier component deployed within a J2EE server. Although, this approach slightly decreases the set of supported clients depending on the availability and version of Java or .NET being used, the use of an enterprise class programming language presents a significant advantage on the application logic front.

    The application logic, running on both the client and middle-tier, is written in an enterprise class programming language (Java or C#), which is both strongly-typed and object-oriented. As a result, the Java/VM approach targets internal or virtual enterprise operational applications where the requirement for Java or .NET on the client is not an issue, and performance, maintainability and scalability requirements of these applications require technologies like Java and C#.

    [Ed Note: This Java/VM approach is the one used at Nexaweb. The firm's RIA client works in JRE 1.1 or later to maximize coverage.]

    Notably, all of these approaches use non-programmatic declarations, using either XML or HTML, to specify the user interface definition. For coding application logic, the first two approaches use scripting languages, ActionScript and JavaScript respectively, whereas the Java/VM approach uses programming languages like Java and C#.

    RIA in Summary -- Keys for 2005
    As SOAs continue to gain widespread acceptance as a framework for cost effectively re-using existing and deploying new application services, enterprises should also consider implementing complimentary RIA technology to bring those applications to their end users.

    The RIA approach provides a logical solution for enterprise developers looking for a loosely coupled presentation tier for delivering their newly deployed SOA. RIAs can be closely aligned with the enterprises business process, not just a specific system or service, and can be quickly and efficiently updated given their zero-install client capabilities.

    Therefore, enterprises will see even more value from their SOA projects while the IT shop will spend less time managing end-user application deployments and more time creating and updating applications that enhance bottom line results.

    Scott Cranton is Director of Product Strategy at Nexaweb Technologies, a RIA provider. Scott has over 14 years experience in the software industry, serving as software developer, architect, consultant, and product manager at Strategic Mapping, MapInfo, and ObjectStore. In 1996, Scott founded OpenMap, a software provider for spatially enabled business applications, and led its product strategy and development efforts. Scott participates in, and is a frequent speaker at, many industry forums; most recently he led the OSS through Java (tm) Initiative's Massive Scalability focus group.