3.3 Process-focused Application Integration patterns

 < Day Day Up > 



3.3 Process-focused Application Integration patterns

Process-focused Application Integration patterns are observed where multiple automated business processes are combined to yield a new business offering or to provide a consolidated view of some business entity with many representations in the corporate business systems. An often quoted example is the consolidated view of the state of all relationships of the business with a particular customer.

This mode of integration is highly flexible. In its more sophisticated form it enables "late binding" of the targets of integration and is particularly useful in tying together different platforms and technologies. However, it represents a more difficult design and development task compared to data-focused integration and often requires complex middleware.

The Process-focused Application Integration patterns are presented here in order of increasing flexibility and sophistication. As the Application patterns build on each other, their capabilities and reliance on middleware increase, and they require less application development effort. From the following Application patterns, select the one that best fits your requirements:

  • Direct Connection application pattern

    • Message/Call Connection variations

  • Broker application pattern

    • Router variation

  • Serial Process application pattern

  • Parallel Process application pattern

Business and IT drivers

Table 3-1 and Table 3-2 summarize the business and IT drivers for the Process-focused Application Integration patterns and their variations.

Table 3-1: Business drivers

Business drivers

Direct Connection Message variation

Direct Connection Call variation

Broker Router variation

Broker

Serial/Parallel Process

Improve the organizational efficiency

ü

ü

ü

ü

ü

Reduce the latency of business events

ü

ü

ü

ü

ü

Support a structured exchange within the organization

ü

ü

ü

ü

ü

Support real-time one-way "message" flows

ü

 

ü

ü

ü

Support real-time request/reply "message" flows

 

ü

ü

ü

ü

Support dynamic routing of "messages" to one of many target applications

  

ü

ü

ü

Support dynamic distribution of "messages" to multiple target applications

   

ü

ü

Support more flexible, time-sequenced business and human process flows

    

ü

Table 3-2: IT drivers

IT drivers

Direct Connection Message variation

Direct Connection Call variation

Broker Router variation

Broker

Serial/Parallel Process

Leverage existing skills

ü

ü

ü

ü

ü

Leverage the legacy investment

ü

ü

ü

ü

ü

Enable back-end application integration

ü

ü

ü

ü

ü

Minimize application complexity

ü

ü

ü

ü

ü

Minimize enterprise complexity

  

ü

ü

ü

Exploit parallelism

   

ü

ü

QoS concerns

This section highlights Quality of Service (QoS) capabilities that are of particular concern in the Process-focused Application Integration domain.

In 2.3, "QoS capabilities framework" on page 26, we described a QoS capabilities framework for Process Integration based on the following general concerns:

  • Autonomic

  • Availability

  • Federation

  • Performance

  • Security

  • Standards compliance

  • Transactionality

The following QoS concerns are of particular importance when working in the Process-focused Application Integration domain.

Important: 

This profile is intended as a very rough first guide to QoS concerns which differentiate this domain, suitable for high-level architectural design. It is not a substitute for thorough analysis at a later design stage.

Autonomic

The complexity of IT infrastructure is increasing, so autonomic computing capabilities are needed to ensure that Application Integration solutions can be managed effectively. For example, clustering solutions may be a consideration for availability management and reducing operational costs.

Performance

High volume workloads are often experienced in the intra-enterprise integration domain, so there is generally a need to carefully assess the expected workload and to plan for future growth in workload.

Standards compliance

Rather than using different approaches for each application integration exercise that an organization performs, standards need to be identified and applied in order to control development and integration costs.

Private standards are also acceptable when beneficial. Adopting WebSphere MQ, for example, as intra-enterprise message-oriented middeware provides assured, once-only delivery messaging that can be widely used across the organization.

Transactionality

Transaction services are often important in intra-enterprise application integration scenarios in order to preserve data integrity and to avoid data loss. Consider using transaction management products that work with XA-compliant resource managers to provide a commit and rollback facility, ensuring that either all resource updates are completed or all updates are rolled back.

3.3.1 Direct Connection application pattern

The Direct Connection application pattern represents the simplest interaction type and is based on a 1-to-1 topology. It allows a pair of applications within the organization to directly communicate with each other. Interactions between a source and a target application can be arbitrarily complex. Generally, complexity can be addressed by breaking down interactions into more elementary interactions.

More complex point to point connections will have modeled connection rules such as business rules associated with them, as shown in Figure 3-2. Connection rules are generally used to control the mode of operation of a connector depending on external factors. Examples of connection rules are:

  • Business data mapping rules (for adapter connectors)

  • Autonomic rules (such as priority in a shared environment)

  • Security rules

  • Capacity and availability rules

click to expand
Figure 3-2: Direct Connection application pattern

Note 

The Connection Rules component is not needed when there are no modeled rules associated with the connection.

The Direct Connection application pattern has two variations:

  • Message Connection variation

  • Call Connection variation

All applications of the Direct Connection application pattern will be one variation or the other. The variation required depends on whether the initiating source application needs an immediate response from the target application in order to continue with execution.

Both variations may be used either with synchronous or asynchronous communication protocols. However, there are preferences for a specific protocol type depending on the variation. For example, the Call Connection variation has a more natural fit with synchronous protocols while the Message Connection variation favors asynchronous protocols.

We examine these two variations in more detail later in this section.

Business and IT drivers

The business and IT drivers for choosing the Direct Connection application pattern are to:

  • Improve the organizational efficiency

  • Reduce the latency of business events

  • Support a structured exchange within the organization

  • Support real-time one-way message flows

  • Support real-time request/reply message flows

  • Leverage existing skills

  • Leverage the legacy investment

  • Enable back-end application integration

  • Minimize application complexity

The primary goal is to allow one application to gain direct and real-time access to another in order to reduce the latency of business events.

Solution

This Application pattern, as shown in Figure 3-2 on page 44, is divided into a number of logical components:

  • The Source Application represents one or more applications that are interested in initiating an interaction with the target application.

  • The Connection is the line between the source application and the target application representing a point-to-point connection between the two applications.

  • The Connection Rules represent any business rules associated with the connection, such as data mapping rules and security rules.

  • The Target Application represents a new application, a modified existing application, or an unmodified existing application. This application is responsible for implementing the necessary business services.

Guidelines for use

Direct integration between applications can be inflexible, in that any changes to one application may have knock-on effects on other applications. Changes to the target application may also require changes to the source application. Such changes can become both expensive and time consuming, especially when the target application is being accessed by a number of different source applications.

Different IT departments may also be responsible for developing and maintaining the source and target applications. Under such a scenario, development might be difficult to coordinate, especially if the interfaces between the applications being integrated are not properly defined and documented. Because of this, it is important to clearly define such interfaces in advance.

Benefits

The Direct Connection application pattern offers the following benefits:

  • It works with applications that have simple integration requirements with only a few back-end applications.

  • It increases the organizational efficiency and reduces the latency of business events by providing real-time access to business data and business logic, and avoiding manual synchronization of data between applications.

  • Direct access to back-end applications reduces the duplication of business logic across multiple tiers. As a result, changes to business logic can be made in one tier rather than in multiple applications.

  • It can enable re-use of investments already made with the organization.

Limitations

Although this is a reasonable starting Application pattern for integrating applications in a one to one relationship with one another, this pattern will result in a many to many "spaghetti" configuration with point to point integration mappings for each application pair. Also, the expansion of this implementation into a multi-point configuration will require additional application logic to handle the coordination.

This pattern cannot be used for intelligent routing of requests, decomposition and re-composition of requests, and for invoking complex business process workflow as a result of a request from another application. Under such circumstances, you should consider a more advanced Application pattern, such as Broker or Serial/Parallel Process.

Putting the Application pattern to use

ABC Electronics, an electronics retailer/wholesaler, wants to integrate their retail and wholesale departments. Currently, both organizations have proven IT infrastructures but have no interconnectivity. The first process ABC Electronics wants to focus on is the inventory and order replenishment process. Currently, the items sold are tallied at the end of the month by the retail ordering process and delivered to the wholesale organization by internal mail. This creates a lag in the inventory replenishment process and causes many out of stock situations. A primary business goal is to minimize the loss of sales due to out of stock situations. To meet these requirements ABC Electronics chooses the Direct Connection application pattern.

Message Connection variation

The Message Connection variation, shown in Figure 3-3, applies to solutions where the business process does not require a response from the target application within the scope of the interaction.

click to expand
Figure 3-3: Message Connection variation

Note 

We chose not to show the connection rules box in Figure 3-3 because we want to focus on the connection itself.

Business and IT drivers

The business and IT driver for choosing the Message Connection variation of the Direct Connection application pattern is to:

  • Support real-time one-way message flows

The main driver for selecting this variation is when the business process has no interest in the result of the operation. This variation also has the most natural fit when message-oriented middleware is used, such as IBM WebSphere MQ.

Putting the Application pattern to use

In our scenario the retail department of the ABC Electronics organization needs to notify the wholesale department to update their inventory records when a part needs to be ordered. The retail department does not require any acknowledgement of this request. To meet these requirements ABC Electronics chooses the Message Connection variation of the Direct Connection application pattern.

Call Connection variation

The Call Connection variation, shown in Figure 3-4, applies to solutions where the business process depends on the target application to process a request and return a response within the scope of the interaction.

click to expand
Figure 3-4: Call Connection variation

Note 

We chose not to show the connection rules box in Figure 3-4 because we want to focus on the connection itself.

Business and IT drivers

The business and IT driver for choosing the Call Connection variation of the Direct Connection application pattern is to:

  • Support real-time request/reply message flows

The main driver for selecting this variation is when the business process does require a result message from the interaction.

Putting the Application pattern to use

In our scenario the retail department of the ABC Electronics organization needs to be advised by the wholesale department of the expected delivery date of a part on order that is out of stock with the retail department. To meet these requirements ABC Electronics chooses the Call Connection variation of the Direct Connection application pattern.

3.3.2 Broker application pattern

The Broker application pattern (also known as Aggregator/Broker), shown in Figure 3-5, is based on a 1-to-N topology that separates distribution rules from the applications. It allows a single interaction from the source application to be distributed to multiple target applications concurrently.

click to expand
Figure 3-5: Broker application pattern

The Broker application pattern applies to solutions where the source application initiating the operation starts an interaction that is distributed to multiple target applications that are within the organization. It separates the application logic from the distribution logic based on broker rules. The decomposition/recomposition of the interaction is managed by the broker runtime component using these broker rules.

The Broker application pattern was previously known as the Aggregator application pattern for read intent and the Broker application pattern for update intent.

Look for complete details on the revised Broker application pattern in a future redbook. Until then, refer to the Application Integration::Aggregator or Broker application pattern discussion on the IBM Patterns for e-business Web site:

  • http://www.ibm.com/developerWorks/patterns

Router variation

The Router variation of the Broker application pattern, shown in Figure 3-6, applies to solutions where the source application initiates an interaction that is forwarded to only one of multiple target applications. The selection of the target application is controlled by the distribution rules that govern the functioning of the connector component.

click to expand
Figure 3-6: Router variation

The Router variation of the Broker application pattern was previously known as the Router variation of the Aggregator application pattern.

3.3.3 Serial Process application pattern

The Serial Process application pattern, shown in Figure 3-7, is based on a 1-to-N topology where serial process rules are separated from the applications. It allows a single interaction from the source application to execute a sequence of target applications.

click to expand
Figure 3-7: Serial Process application pattern

The Serial Process application pattern separates the process logic from the application logic. The process logic is governed by serial process rules that define execution rules for each target application, together with control flow and data flow rules. It may also include any necessary adapter rules.

Look for complete details on the Serial Process application pattern in a future redbook. Until then, refer to the Application Integration::Managed Process application pattern discussion on the IBM Patterns for e-business Web site:

  • http://www.ibm.com/developerWorks/patterns

Serial Workflow variation

The Serial Workflow variation of the Serial Process application pattern, shown in Figure 3-8, allows for routable activities (operations requiring human interaction, for example) to be routed to a suitable resource. In addition to the serial process rules, the serial workflow flow rules are supplemented with resource definitions and task-resource relationships. In this context:

  • Tasks are activities or pieces of work.

  • Resources execute tasks. People, departments, applications, and so forth can all be resources capable of executing particular tasks.

  • The task-resource relationship defines which resources are capable of executing which tasks.

click to expand
Figure 3-8: Serial Workflow variation

3.3.4 Parallel Process application pattern

The Parallel Process application pattern, shown in Figure 3-9, is a combination of the Serial Process application pattern and the Broker application pattern. The interaction initiated by the source application may control concurrent (parallel) activities on multiple target applications. Each activity may consist of a sequence of operations executed in succession on a target application.

click to expand
Figure 3-9: Parallel Process application pattern

Similar to the Serial Process application pattern, the Parallel Process application pattern separates process logic from application logic. The parallel process rules must additionally allow for definitions of start and join conditions for activities executing in parallel. A runtime component is required that provides for the start, join, and management of these parallel activities as a unit.

Look for complete details on the Parallel Process application pattern in a future redbook. Until then, refer to the Application Integration::Managed Process application pattern discussion on the IBM Patterns for e-business Web site:

  • http://www.ibm.com/developerWorks/patterns

Parallel Work Flow variation

Similar to the Serial Work Flow variation, the Parallel Work Flow variation of the Parallel Process application pattern, shown in Figure 3-10, represents an extension of the Parallel Process application pattern to account for routable activities.

click to expand
Figure 3-10: Parallel Workflow variation



 < Day Day Up > 



Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net