Feature

In the telecommunications industry there's a special phrase for that bit of technology that carries data from the last pole or relay box into the customer's home. It's called "the last mile" and it's often seen as one of the biggest challenges because this last step in the technology chain can be a considerable physical undertaking. In the IT industry we also have our "last mile": putting the right application in the hands of the end user. Composite applications address this "last mile", combining a rich user interface with SOA-driven application integration technology.

Composite applications are nothing new. Analysts have been talking about composite applications since the birth of the Internet and in more urgent tones during the Enterprise Application Integration (EAI) generation of integration technology. Today there are plenty of consumer-focused composite applications, colloquially referred to as mashups. Popular examples, fueled by the mapping-oriented Web Services provided by Google and others, have been growing at an exponential pace. These applications typically take data from one source of information and plot that data on interactive maps. Literally dozens of these are introduced every week.

One recent example plots Associated Press news articles by the location of the news story (http://asap.ap.org/fronts/newsmap.s - ASAP); another displays airports with their associated air traffic control delays (www.usaflightinsurance.com/gmap.htm - FAA Flight Delay Information); a third displays movies, theaters and show times by location (www.mashmap.com/ - Mash Map). Composite applications are useful for the consumer. This article will discuss the next logical generation of these applications - the business use of composite applications or, as one market analyst put it, "enterprise mashups."

The Basics of Composite Applications
Since the term "composite application" isn't subject to formal definition by any standards-setting body, there's considerable overuse and misuse of the term in software marketing. The "composite application" label has been applied by consumer and business-oriented software vendors alike in such diverse functional areas as Web portals, business process management, document management, knowledge management, and collaboration. A "true" composite application is probably not any one of these things but rather an application that combines services such as intranet-based search engines, applications and databases exposed as Web Services, messaging systems, business intelligence engines and data integration solutions with extranet services such as data sources and application utilities. Simply defined, a composite application combines functionality from multiple applications to support business tasks that span those existing applications.

Like two streams that join to make a large river, the composite application "buzz" is due to the convergence of two trends: Internet-based user interface technology that's rich (i.e., one that looks and feels like a desktop application but is delivered via a Web browser) and evolving open integration technologies and standards like XML and Web Services.

Read enough of the vendor case studies and you find that the current sweet spot for composite application implementations includes two or more of the following source applications: sales force automation, customer support, contracts/billing, content management, and the ever-present custom legacy application. Composite applications are still new enough that very few qualified and quantified ROI studies exist, but anecdotal evidence indicates that the benefits of composite applications can be great. For IT, composite applications are developed faster than previous integration approaches and can be easier to maintain and upgrade, while also improving the return-on-assets of the existing systems they are built on. For business users, they address issues as far ranging as data quality and data latency, throughput, and end-to-end cycle time, and qualitative areas such as customer service and enhanced ease-of-use.

Now let's take a close look at the underlying architectural components of composite applications.

The 'Application' Side of Composite Application
Internet application development tools have matured greatly in the last decade and they have made great strides towards the goals of true portability, ease of development, and most importantly, true user utility. Internet-based user interface technology has also improved, allowing a "smarter" client that has sophisticated client-side capabilities such as statefulness, fat client-like logic, local data validation, and client-side data control such as local caching and programmatic server interaction, without requiring large downloads or the installation and maintenance of native client-side code.

The most interactive of applications that fit this description are often referred to as "Rich Internet Applications" or RIAs. SOA analyst firm ZapThink estimates that the RIA tools market currently accounts for less than 10% of all application presentation tools but by 2010 will account for over 50% of that market and represent a $1.1 billion industry. There are a number of practical toolsets available to bring a RIA to the user. The three most popular approaches today include Java, Macromedia Flash, and a combination of native browser functionality referred to as AJAX (a combination of Asynchronous Javascript, XML and some supporting technologies). Table 1 compares some the more notable pros and cons of each technology.

In this article, we'll focus on the newest of these approaches, AJAX.

AJAX, or Asynchronous JavaScript and XML, is a Web development technique for creating interactive Web applications. According to the Wikipedia, "The goal of AJAX is to make Web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire Web page does not have to be reloaded each time the user makes a change. This is meant to increase the Web page's interactivity, speed, and usability." It's certainly a worthy goal.

Technically, AJAX consists of a combination of:

• Presentation using XHTML and CSS;
• Dynamic display and interaction using the Document Object Model (DOM);
• Data interchange and manipulation using XML and XSLT;
• Asynchronous data retrieval using XMLHttpRequest; and
• JavaScript binding everything together.

AJAX designs are commonly deployed to the user's browser in two parts a pre-built generalized AJAX runtime component, or "client," and your application-specific design specifications. The latter is typically in some XML format. With an AJAX runtime client, the initial download of "code" to the browser will be relatively larger (due to the dual download of AJAX runtime client and your application-specific design specifications) but will make the overall user experience better.

Once the AJAX runtime client is initialized in the browser, it loads the screen layout specification, generates dynamic HTML to render the screen accordingly, and starts to handle all the document object model (DOM) events generated by the user's interaction with the browser. The AJAX runtime client typically handles many user-generated interface events locally, such as field navigation and any associated simple data validation. When communication with the server is necessary (for example, to fetch additional information or to post a transaction), it mediates the network interaction with the server and may, for example, cache results in hidden data tables in the browser to optimize future data-centric activities and manage server interactions better. The AJAX runtime typically communicates with the server in an asynchronous fashion, without stalling a user's interaction with the application or requiring a refresh of the user's HTML interface.

The kinds of tasks an AJAX runtime can handle locally, without server interaction, are rapidly evolving from simple data "checkbox-type" validation constraints such as checking for the presence of mandatory data items or date formats to more complex business rules (perhaps originally represented as BPEL fragments) that are executed in the AJAX runtime. This is some of the magic of AJAX, as it lets you move functions from server to client as necessary. A good generalized architecture of AJAX, depicted in contrast with the more traditional Web application architecture, is shown in Figure 1.

Much like the early days of HTML, you can code AJAX-based applications by hand in Notepad or vi. But considering the many technologies in AJAX (DOM, CSS, HTML, XML, JavaScript, etc.), maintenance and debugging would be at best difficult. You certainly want to use an AJAX integrated development environment (IDE). A good IDE can generate some or most of this fairly complex code, both the server-resident code and the browser-specific code that's ultimately deployed with and executed by the AJAX runtime client.

AJAX IDEs are still maturing. Here are some important functions to look for when acquiring your AJAX toolset:

• Pre-built control library: Look for a large library of pre-built visual interface controls like those you would see in a typical client/server development tool. Ask whether the IDE lets you extend the toolset to meet your own unique needs. Business applications often require custom controls that are unique to your organizational needs and composite applications are no exception.
• Logic/Data binding: The tool should enable the automatic mapping of GUI controls directly to simple services and the generation of code stubs to bind controls to more complex services. In the latter case, this allows the separation of application interface development from business logic/data binding, which can be done in parallel.
• Code development support: Closely related to logic/data binding, code development support allows for that last bit of hand-coding you need to do in Java or .NET to bind a button to a custom application or API. Does the tool include some type of plug-in (or is entirely resident in) for a code development environment like Eclipse, Visual Studio, and/or Dreamweaver?
• Standards support: In the next section we'll outline a number of standards important to an AJAX-based composite application architecture. Choose an AJAX IDE that supports the ones that are important to you project. Get a feel for the product's roadmap for future standards and technologies by asking if the vendor participates in standards bodies like OASIS and W3C. And if the tool doesn't support WS-such-and-such today, when will it?
• Development repository: A repository can be the "lumber yard" from which your composite application engineers pick the raw materials they need to build their composite applications. A repository can store many things: application interfaces exposed as Web Services; logical software services like database tables, stored procedures, and reusable composite application "widgets" such as custom controls; or specialized application binding code. The real trick is to find a repository that makes the storage, searching, and retrieval of these objects easy through simple interaction standards like UDDI 3.0 and WebDAV, and perhaps even an API that allows for advanced programmatic interaction such as the XML Query for Java (XQJ) and the Java API for XML Repositories (JAXR).
• Odds and ends: Some final items to look for in your AJAX toolset include dynamic charts, multi-language support, style templates, and thorough installation and "getting started" documentation. Most but not all AJAX tools support these areas, so trust but verify.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...