Composite Applications Pattern

A composite application seems to the user like a new application. It has some new functionality itself, plus functionality from multiple existing applications.

A composite (or “virtual”) application needs to be near zero in latency (usually under a minute, often within a couple of seconds). It may be implemented with any of a wide range of middleware technologies. Plain, direct gateways are the most popular choice for opportunistic, tactical, request/reply applications, especially when extending only one or two back-end applications with a Web front end. Gateways may operate with a remote procedure call (RPC) model (e.g., COM-CICS or COM-CORBA gateways), a screen scraping model or a database gateway model (e.g., JDBC, ODBC or OLE DB). For NIH, the preferred approach to composite applications will be through the use of web services and leveraging the Enterprise Service Bus (ESB).

The diagram shows the interaction between the composite application and the services leveraged via the ESB. The composite application itself is hosted within some kind of application container. This container could be an application server technology like J2EE or Microsoft .Net, or could even be a desktop application accessing remote services. In some cases, the application container may be a portal providing access to a variety of application services and facilitating the creation of composites. The ESB’s service orchestration capabilities may be leveraged to provide more complex flow between services. The ESB may be used to access a web service, to present a service interface to an existing application, or to provide access to a database via a web service.

Please view the Composite Applications Pattern below:

• NIH can use the composite application pattern to “glue together” some of its partially redundant applications and give users a much more convenient interface.
• Extension systems can use this pattern to construct an interface that uses and updates both enterprise and Institute and Center (IC)-specific data at the same time.

• Will be difficult to apply to monolithic applications, especially those that currently use no form of middleware. (The application architecture survey indicated that these types of applications are rare at the NIH).
• Coordinated and reliable transaction control (commit/rollback) can be a challenge.
• As with all Service-Oriented Architecture (SOA) applications, configuration management must be in place to ensure that dependencies between service providers and the composite application are managed effectively.

Recommended Usage

• The composite application pattern should be used when an end-user application is required to leverage the functionality of an existing system or service using a request-reply interaction. 
• This pattern can also be used directly (without an ESB) with middleware-enabled applications when the number of applications is small (four or less).