Chapter 3. Application Integration pattern 35
3.2 Defining the Application Integration patterns
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:
36 Broker Interactions for Intra- and Inter-enterprise
? 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, ITSO 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.
Chapter 3. Application Integration pattern 37
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.
38 Broker Interactions for Intra- and Inter-enterprise
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
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.