Key Capabilities for Building Composite Applications

From MIKE2 Methodology

There are a number of key capabilities needed for building Composite Applications. Delivering Composite Applications requires sophisticated capabilities across the integration architecture. These capabilities should be considered “best practices” to be followed in an integration effort, regardless of whether or not the objective is to implement a Composite Application. The solution maturity required for building Composite Applications mandates their use.

Contents 1 Reusable Services 2 Handling Asynchronous Transactions 3 Versioning 3.1 In-Flight Process Handling

Reusable Services

Composite Applications reuse existing integration infrastructure to assemble more significant capabilities. Building reusable services across the enterprise is not easy and federated organizations that lack a strong enterprise architecture group find this particularly challenging. Key success factors in building reusable services include:

• There is an architecture group within the organization that has visibility and authority to make decisions at the enterprise level.
• There is a common registry where services can be discovered.
• Services interact via common standards such as a Common Messaging Model.
• There is a common methodology for how services are to be defined and to be used.
• Services are well modelled and are no more technically complex than they need to be.

Handling Asynchronous Transactions

Transactions within the integration environment are often designed to be asynchronous. Although this provides a significant benefit – a decoupled architecture that is latency independent – the design and management of asynchronous transactions can be more difficult. Running implementations in parallel can increase this complexity. A properly design services-oriented architecture must be well designed for handling asynchronous transactions; making use of transaction handles from both the host applications and the integration infrastructure. One of the most important functions in supporting release inter-operability is that assignment of transaction handles is consistent across the release.

Versioning

There will typically need to be two different types of version numbers to support compatibility within the Services Oriented Architecture of the integration infrastructure.

• A version ID associated with the applications and their exposed interfaces
• A version ID associated with the process instantiated by the workflow process.

These identifiers are important metadata assets and can be useful in determining what should be done with a particular event when running integration components in parallel or when handling asynchronous transactions.

In-Flight Process Handling

In-Flight Process Handling describes the scenario whereby a process changes (due to a software release) occurs whilst there are still incomplete “in-flight” processes within the production system. Although there are less elegant mechanisms for handling this issue, mature Composite Applications should be able to handle this without significant downtimes or impact to the business. The capabilities required will often include:

• The integration infrastructure will need to support multiple processes running concurrently across releases.

• Depending on the approach taken by the implementation teams, there may be a need to run integration components that perform the same business functionality in parallel. The need to do this will depend on the functionality offered by the host applications, and their approach to providing Backward Compatibility. The rollout of software using parallel runs of integration components will mean that the same software will be available to service both releases and that generation of a workflow process can be instantiated for multiple releases.

• As applications will be “backward compatible” they will be able to support multiple versions of software. The may need to be facilitated through the integration infrastructure.