Finally, you want to remember your deployment target when choosing a composite application toolset. Today's estimates are that around 75% of browser installations support AJAX. While this may be less of an issue inside corporations that have constant maintenance/upgrade programs, it's important to know this in advance. While this issue isn't exactly unique to AJAX, it can become a real issue when you want to deploy your new composite application to 10,000 business users.

The 'Composite' Side of 'Composite Application'
Perhaps not coincidentally, Service Oriented Architectures (SOAs) fit nicely into the AJAX-based composite application design goal. SOAs, in case you've missed the buzz so far, bring value to an organization by enabling it to expose important business information and logic in a readily accessible way. Technically SOAs are collections of standardized interfaces, or "services" to and from business applications and data sources allowing loosely coupled access to this data and logic through standardized mechanisms such as XML-based messaging over HTTP. (In fact, if you're reading this journal you likely already understand the ubiquity and utility of an SOA.) There are many parts to an SOA, so we'll restrict ourselves to the SOA principles and technologies that are most relevant to composite applications.

The behind-the-curtain component of composite applications loosely corresponds to the higher-order functions of the Web Services protocol stack. Described top-down from the highest to the lowest these are functions that include:

• Orchestration is functionality that lets the composite application define and execute a "flow" between services Today, this kind of functionality is usually found in Enterprise Service Buses and some BPM products. Popular relevant standards include BPEL (Business Process Execution Language) and BPML (Business Process Modeling Language). BPEL, in particular, is increasingly accepted as an interoperable standard for orchestrated process flows. It emphasizes a loosely coupled orchestration solution that reuses lower-level services (instead of hand-coding an orchestration that is tightly coupled to lower-level APIs). BPEL also includes native functions to persist long-running orchestrations.
• Choreography, or the interaction between independent processes, can be more complex, involving business rules rather than simple conditional logic, and is often laden with elaborate rules for handling exceptions. Because of these factors, it's a tougher nut to crack than orchestration. Relevant standards include the well-supported BPEL, the less popular WSCI, the newer WSCDL, and even human-centric standards like XPDL and the proposed "BPEL for People." There may not be a perfect fit within the standards world for choreography, , as evidenced by recent attempts to "abstract" BPEL for this type of purpose.
• Composition creates coarse-grained services from fine-grained services. The purpose of composition is to eliminate direct application-to-application connections and instead create "composed" services that are reusable many times. For example, fine-gained data services "Get Name," "Get Balance," and "Get Credit Score" can be accessed by every AJAX composite application that needs customer information. But it's smarter to compose a corresponding coarse service, "Get Customer Info," accessible by all applications, particularly if this new service has extra logic like the resolution of data semantics or data rules. BPEL can be used appropriately for composition assuming that your "services" are Web Services only; if your environment includes other "services" such as a SQL interface or JMS API, you may want leave the composition functionality to a tool other than your AJAX tool, such as an Enterprise Service Bus.
• Finally, transaction control manages a reliable relationship between two or more services. Although you could explicitly connect to the source systems yourself and perform your own transaction management, this is hard enough even when connecting to two instances of the same type of system, like two Microsoft SQL Server databases. However, in real-world situations, transactions are just as likely to span multiple, heterogeneous systems over multiple communication channels and APIs such as JDBC, SOAP over HTTP, JMS, and so on. For these reasons, you'll probably want to rely on the more sophisticated, dedicated transaction management capabilities of an Enterprise Service Bus or TP monitor. > Looking forward, a standard you might employ is WS-CAF, a draft OASIS standard "for supporting coordinated and transactional compositions of multiple Web Services applications," that is composed of three existing OASIS specifications: WS-Context, WS-Coordination Framework, and WS-Transaction Management. When complete and approved, WS-CAF could eliminate much of the custom coding inherent in today's approaches to Transaction Control.

In addition to the above, you want to remember a few fundamental areas of technology:

• Security: You should design your entire composite application stack to allow for security to be passed from the highest to lowest level service. This can be complicated by simple issues like different IDs, passwords, and rights. The solution is the management of identity through a "policy" that can be used in all parts of the composite application instance lifecycle. This complex area makes WS-Security and SAML must-have standards to include in your composite application project.
• Management: Once you've deployed your composite application, you'll want to know that it's running and available. Your AJAX runtime environment should include some kind of management interaction through SNMP or JMX.

It's important to realize from this long list of functions that there's unlikely to be any one AJAX IDE tool that addresses all of these functions unless you're willing to include a lot of homegrown code as part of the answer. For example, you might already own an orchestration tool (sometimes called an Enterprise Service Bus or ESB). But using more than one tool to complete your composite application project need not be a deal killer. Many vendors "pre-assemble" some or all of the tools you need, including an AJAX IDE, an ESB, a development repository, and other supporting software. And you may find that your tools interoperate through standardized protocols.

Obviously, all this talk of services means that the composite application development team has to be aware and involved in the service enablement of the source systems. Getting your legacy service enablement wrong will result in longer development times and less value for the ultimate user. Issues that a legacy service enablement vendor can help you address might include:
1.  Level of service enablement: Do you enable the legacy database, the legacy application, or the legacy user interface? These are complementary technologies that tackle legacy systems in different ways and with different tradeoffs.

2.  Type of service enablement: Service interfaces can be through pre-SOA standards like SQL, the exchange of XML-formatted documents, a more formal WSDL contract, or some sort of messaging system.

3.  Granularity of function: It's rare to find a match between the level-of-functional granularity natively offered by a packaged application and what your composite application would "prefer" to consume, so some kind of orchestration, choreography, or composition is often necessary to aggregate a set of lower-level functions exposed by an application into higher-level business services that can be used directly by other consumers.

Finally, keep in mind that not all of the technologies and standards may be relevant to your composite application. Equally important, we couldn't cover them all in this article, so we focused on the most popular and most formal of them. If you embark on a composite application project, you should try to keep up with the relevant technologies and standards.

Finishing the Last Mile
Composite applications benefit the businessperson and the technologist. Business users get a richer user experience. IT has a smarter way to create composite Web applications. Make sure you have a plan to walk this last mile. It's worth the trip.

Composite Applications and Portals

Portals were arguably the first generation of composite applications. Today composite applications can offer a much richer application development platform through service-based integration (instead of the kind of integration in the application server that runs the portal) and the highly interactive user environment offered by AJAX-enabled rich Internet applications. With this trend, some analysts have predicted that composite applications signal the beginning of the end for portal-based applications. In reality, the primary functions of portals and composite applications complement each other well. A portal can "wrap" and pass through users seamlessly to a composite application, containing it wholly. Conversely, a composite application can wrap a portal (or portlet more likely), as part of the application, perhaps even invoking it with parameters that tie it into the rest of the composite application. But they have their differences too.

Different tools for different problems -
Portals began by aggregating functions that typically didn't require coordination between them or transactions across them. For example, Web portals allow UI designers to assemble useful utilities for their user communities but the Company News portlet in Frame 1 doesn't connect to the Customer Reference Database in Frame 2. They don't focus on what one composite applications vendor described as "flow" and "wiring."

While portal technology has greatly matured in recent years, the "Functionality of Composite applications" section in the main article outlines a number of functions and standards that you won't likely see in everyday portal software. Examples of portal maturity are the OASIS WSRP Producer and Consumer and JSR-168 standards, which allow portals to consume portlets from other places (one through Web Services and the other via Java). This is not a service-oriented integration approach to a composite application but does let a portal vendor simulate it.

Pay me now or pay me later - Portal-based applications are typically HTML-driven and can be counted on for fairly lean-and-small sets of 'code' driven to the user's browser. In contrast, composite applications have a larger upfront "load" since there can be a certain amount of code (like the Ajax runtime client described earlier in this article) as well as data that needs to be cached. After this initial load, however, well-designed composite applications can have developer-controlled incremental exchanges with the server that compare favorably with the complete page or frame loads/reloads common to portals.