3.2 Defining the Application Integration patterns

< Day Day Up >

This section defines the Application Integration patterns by documenting the Business and IT drivers that lead to the selection of this pattern, the context within which it can be used, the proposed solution, and examples of its usage.

It also discusses typically observed application integration requirements that can help determine which of the two Application Integration categories (Process-focused or Data-focused) you should use in designing your e-business solution.

3.2.1 Business and IT drivers

Typical Business and IT drivers that result in the selection of this Integration pattern are:

The business processes need to be integrated with existing business systems and information.
The business activity needs to aggregate, organize and present information from various sources within the organization.

3.2.2 Context

Application Integration patterns can be observed in solutions that call for close integration with systems and databases that exist within the organization. It serves as a back-end integration pattern, and is critical for the successful implementation of certain Business patterns. For example, solutions that use the Self-Service business pattern or Extended Enterprise business pattern often rely on these same application integration techniques. Similarly, many Custom designs and Composite patterns use Application Integration application patterns.

For example, take the case of a company that wants to integrate their retail and wholesale departments. Currently, both departments have proven IT infrastructures but have no inter connectivity. The Process-focused Application Integration patterns address this problem. These patterns can be applied in a case where the business process needs to be integrated between existing business systems within the organization. The Process-focused Application Integration patterns can be used to integrate the retail ordering and wholesale inventory systems, eliminating ordering lag and providing an up-to-date inventory.

3.2.3 Solution

The Application Integration pattern typically consists of the following elements:

Business applications and data that need to communicate, interact, and integrate with other business applications and data within the organization
A network which:
- Is based on TCP/IP and other Internet technologies, or on proprietary protocols
- Can be a dedicated LAN or WAN connection
Other business applications and data which can be:
- Custom developed systems (old and new)
- Enterprise Resource Planning systems and other packaged applications, such as SAP, BAAN and PeopleSoft
- Databases
Application integration services, which include:
- Protocol Adapters
- Message handlers
- Data transformation
- Decomposition/recomposition
- Routing/navigation
- State management
- Security

3.2.4 Putting the pattern to use

This is probably one of the most commonly used patterns and it can be observed in any solution where an application needs to integrate with other applications, legacy systems and databases. Examples include:

An electronics retailer/wholesaler, ABC Electronics from our sample scenario, needs to integrate their retail ordering process with their inventory management system.
A telecommunications company needs to integrate their online sales systems and their core provisioning systems to improve efficiency and customer service.

3.2.5 Application Integration considerations

Choosing the right Application Integration pattern can only be done in the context of specific solution requirements. These requirements encompass not only the specific needs of application integration to be deployed, but also the constraints posed by the enterprise's existing IT infrastructure and technology investments. This section details considerations to be made and questions to ask in determining the best integration technique for a solution under consideration.

Request for information versus request for processing

Is the integrated solution for informational access only or is it intended to integrate requests for processing? The Process-focused Application Integration patterns are concerned with integration of the functional flow of processing between applications. The Data-focused Application Integration patterns are concerned with integration of the information used by applications.

Foreground versus background integration

Is there a user awaiting the outcome of the operation or is this operation running behind the scenes? An example of a foreground (or real-time) process may be a user retrieving a price quote for the purchase of product whereas a background (or batch) process would be the synchronization of pricing information from the central office out to all of the local stores.

Scope of integration

Does the integration project involve only a single Business pattern, multiple Business patterns, or the creation of an entire e-infrastructure for multiple e-business solutions?

Operation latency (applications and/or data queries)

How long will it take the operation to complete in the application? Operations that can not complete in less than a few seconds typically dictates the need for asynchronous methods of integration. A query on product inventory may be a quick operation whereas the computation of the production plan for the manufacturing of that inventory could take minutes to hours to complete.

Geographic proximity

How close do the applications being integrated reside to one another? Similar to the idea of operation latency, an often overlooked element of the EAI design is the proximity of the participating applications in relation to each other. Integration of applications residing in the same data center has a much smaller integration latency than integration of applications spread around the world.

Process re-engineering

Is there a need to re-engineer business processes or extend an existing business process? Most legacy business processes are embedded within the applications themselves. Business Process Management (BPM) is performed by the existing application(s). Sometimes the EAI effort is merely trying to better integrate functional operations of a disconnected, narrow (or "stovepipe") business process. Other endeavors are more ambitious with the desire to improve business processes through integration.

There are varying degrees of process extensions for application-based BPM:

Extending the reach of the business process by integration with other applications.
Joining together two separate application-based business processes into one unified process.
Separating BPM from application logic by implementing the process in a Process Manager. This option extends the domain of the process by allowing it to encompass any participating application under any specific sequencing and process flow control.

Application portfolio

What is contained in the mix of applications? This might include pre-packaged software, legacy applications, or newly developed applications. One of the most important elements of an EAI project is to survey the application landscape. Some environments are heavily based on pre-packaged software. Other environments are completely homegrown custom applications. Other environments may be a mixture of pre-packaged applications working with legacy homegrown applications.

This survey will detail several key points about the enterprise environment:

Can the application interfaces be extended as part of the integration activity? Homegrown applications may have standardized interfaces or can be extended to implement standards. Interfaces into pre-packaged applications typically can only be standardized through implementation of sophisticated adapters.
Is there a central cornerstone application in the enterprise environment or a portfolio of peer applications? Is the business processing focused around one key application (perhaps an ERP system) with all other applications being subservient to that application?
How many applications are being integrated? For instance, a typical Self-Service application may be integrating the Web application server with one back-end system. At the other end of the spectrum would be a project creating a centralized customer information system that may require feeds from 100+ different applications. There is a significant difference in the selected solution for integrating two applications versus integrating 100+s of applications.

Key characteristics of the application portfolio and enterprise architecture that affect the EAI approach include these:

Number of applications
Degree of centralization of the data repositories
Completeness of the application interfaces
Conformity of the participating applications to the EAI data and interface model.

Tight coupling versus loose coupling

What is the level of independence between the application implementation and the EAI interface? How likely is it that changes to the application will require changes to the interface or changes to the integration approach? The degree of invasiveness not only affects the application adapter. It can also affect the integration hub processing and even require changes to the partner application. The further across the application integration topology a change ripples, the more expensive this change will be. The degree of invasiveness is often described in terms of coupling (loose coupling versus tight coupling) or black box versus white box approach.

Ideally, the less invasive the integration, the more successful the integration will be in the long-term. This is the primary reason for the use of messaging based integration to isolate as much of the integration processing from any application-specific dependencies. EAI best practices should be employed to ensure that the integration is as non-invasive as possible.

However, EAI projects will vary in the level of independence available based on the completeness of the participating applications functionality and interfaces. For environments with heavy application-specific processing required, it is best to implement these using a sophisticated integration broker component supported by easy to use application development tools. This ensures that future extensions to the integration can be implemented quickly and easily.

3.2.6 What's next

If you have determined that the Application Integration pattern is appropriate for use in your solution, the next step is to select an associated Application pattern based on your specific Business & IT drivers.

If the Application Integration pattern is not appropriate for your development efforts, review the Business patterns to determine which pattern best addresses your e-business needs.

< Day Day Up >