4.2 Application patterns

---

4.2 Application patterns

The Extended Enterprise application 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:

• Exposed Direct Connection application pattern

  • Message/Call Connection variations

• Exposed Broker application pattern

  • Router variation

• Exposed Serial Process application pattern

Note 

The Exposed Parallel Process application pattern is a further possibility, but it is not currently being observed in the Extended Enterprise domain. It is expected to appear at some later stage. In the Process-focused Application Integration domain, see 3.3.4, "Parallel Process application pattern" on page 51.

In this redbook we focus on the Exposed Direct Connection application pattern. A brief overview of the other Extended Enterprise patterns is provided. For full details on the other Extended Enterprise patterns, see the IBM Patterns for e-business Web site:

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

The diagram conventions shown in Figure 4-2 on page 75 are used to describe these successful approaches in the following Application patterns.

Figure 4-2: Application pattern diagram conventions

Business and IT drivers

Table 4-3 and Table 4-4 summarize the business and IT drivers for the Extended Enterprise application patterns and their variations.

Table 4-3: Business drivers

Business drivers	Exposed Direct Connection Message variation	Exposed Direct Connection Call variation	Exposed Broker Router variation	Exposed Broker	Exposed Serial Process
Improve the organizational efficiency	ü	ü	ü	ü	ü
Reduce the latency of business events	ü	ü	ü	ü	ü
Support a structured exchange with business partners	ü	ü	ü	ü	ü
Support real-time one-way message flows to partner processes	ü		ü	ü	ü
Support real-time request/reply message flows to partner processes		ü	ü	ü	ü
Support dynamic routing of messages to one of many target partners' processes			ü	ü	ü
Support dynamic distribution of messages to multiple target partners' processes				ü	ü
Support shared public process flows with partners					ü

Table 4-4: IT drivers

IT Drivers	Exposed Direct Connection Message variation	Exposed Direct Connection Call variation	Exposed Broker Router variation	Exposed Broker	Exposed Serial Process
Leverage existing skills	ü	ü	ü	ü	ü
Leverage the legacy investment	ü	ü	ü	ü	ü
Enable back-end application integration	ü	ü	ü	ü	ü
Minimize application complexity	ü	ü	ü	ü	ü
Minimize enterprise complexity			ü	ü	ü

QoS concerns

This section highlights Quality of Service capabilities that are of particular concern in the Extended Enterprise domain.

In 2.3, "QoS capabilities framework" on page 26, we describe 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 Extended Enterprise domain.

Important: 

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

Availability

High availability can be a particularly significant issue in the inter-enterprise integration domain. It is important that careful availability management be used to provide acceptable levels of customer service or, in some cases, to meet contractual obligations regarding the availability of the application service being provided.

Federation

To avoid overlap and inconsistencies in the implementation and management of an inter-enterprise application integration scenario, it is crucial to clearly define and agree to the responsibilities of each partner. In particular, agreed mechanisms are needed for passing resource and user authentication and authorization information between domains.

Performance

With inter-enterprise application integration, components of the end-to-end solution are outside the enterprise boundaries and cannot be directly influenced. As a client to an external application, it is difficult to control variables such as response time, workload, and availability.

To minimize such dependencies, loosely coupled and reliable communications should be considered.

Security

This topic includes a range of complex issues. To discuss each of them explicitly is far beyond the scope of this book. For the purpose of this discussion, we assume that the communication channel is secured by using firewalls as well as proper authentication, authorization, and so forth.

In addition, we have to secure the exchange of the data itself. In the case of an intra-enterprise scenario, it may be sufficient to use a trustworthy network. For inter-enterprise communication, this is not longer valid. There is a need to protect (encrypt) the data and be sure about the sender's identity (signature).

Standards compliance

To enable interoperability between enterprises, standards compliance is a key capability in the inter-enterprise integration domain. Widely accepted public standards normally are required in order to have agreement between partners. There is also usually a need for compatibility with standard firewalls when communicating between trusted private networks and untrusted networks, such as the Internet.

4.2.1 Exposed Direct Connection application pattern

The Exposed Direct Connection application pattern represents the simplest interaction type based on a 1-to-1 topology. It allows a pair of applications to directly communicate with each other across organization boundaries. 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 4-3. 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

Figure 4-3: Exposed Direct Connection application pattern

Note 

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

The Exposed 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 proceed 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 Exposed Direct Connection application pattern are to:

• Improve the organizational efficiency

• Reduce the latency of business events

• Support a structured exchange with business partners

• Support real-time one-way message flows to partner processes

• Support real-time request/reply message flows to partner processes

• Leverage existing skills

• Leverage the legacy investment

• Enable back-end application integration

• Minimize application complexity

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

Solution

This Application pattern, as shown in Figure 4-3 on page 79, 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 in another organization.

• 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.

Since this application is directly exposed across organizational boundaries, it must implement or exploit the necessary security features such as authentication, authorization, confidentiality, integrity, and logging for non-repudiation purposes.

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. This is especially dangerous when integrating across organizational boundaries. Any changes to the exposed target application may require changes to many partner applications. Such changes can be both expensive and time consuming.

Such knock-on effects can be minimized using document-based adapters that wrapper the applications in the exposed connection. Document-based adapters are small programs that convert the mutually agreed upon messages into API calls to existing or new backend applications. This layering technique isolates the exposed applications from partner applications and increases flexibility. Any changes to these exposed applications would only impact the adapter, provided there is no need to change the mutually agreed upon messages.

Message definition should be generalized to further promote flexibility. In other words, messages should not be tightly coupled with backend application APIs. Rather the message should capture all the necessary information required for that logical interaction across business boundaries. Such generalization will help cope with changes to the backend application API without having to change the agreed upon message format.

Benefits

The use of this pattern allows the complete integration of applications belonging to different companies, assuring a real-time and service-oriented access to external data and processes. Source and target applications are clearly decoupled, as are business logic and communication details. Therefore, it is possible to develop different parts of the whole system in an independent way.

Limitations

This pattern implements a direct connection between the source and target application. Hence, it 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 a partner application. Under such circumstances, you should consider a more advanced Application pattern, such as Exposed Broker or Exposed Serial Process.

Putting the Application pattern to use

With the successful integration of their internal retail and wholesale systems, ABC Electronics has now decided to integrate with their external business partners. The goal is to integrate the external resellers with the internal wholesale system. As with the internal retail system, orders placed by the external resellers will need to update the wholesale inventory system. To meet these requirements ABC Electronics chooses the Exposed Direct Connection application pattern.

Message Connection variation

The Message Connection variation (also known as Document Exchange), shown in Figure 4-4, applies to solutions where the business process does not require a response from the exposed target application within the scope of the interaction.

Figure 4-4: Message Connection variation

Note 

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

The Message Connection variation of the Exposed Direct Connection application pattern was previously known as the Document Exchange application pattern.

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, external business partners of the ABC Electronics organization need to notify the ABC wholesale department to update their inventory records when a part needs to be ordered. The external business partners do not require any acknowledgement of the request. ABC Electronics chooses the Message Connection variation of the Exposed Direct Connection application pattern to meet this requirement.

Call Connection variation

The Call Connection variation (also known as Exposed Application), shown in Figure 4-5, applies to solutions where the business process depends on the exposed target application to process a request and return an response within the scope of the interaction.

Figure 4-5: Call Connection variation

Note 

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

The Call Connection variation of the Exposed Direct Connection application pattern was previously known as the Application Integration::Exposed Application application pattern.

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 requires a result message in the interaction.

Putting the Application pattern to use

The final stage of the scenario is addressing any out of stock situations with the external resellers. As with the internal retail system, the external resellers require an immediate notice on any out of stock situations and a delivery date indicating when the order can be filled. To meet these requirements, ABC Electronics chooses the Call Connection variation of the Exposed Direct Connection application pattern.

4.2.2 Exposed Broker application pattern

The Exposed Broker application pattern (also known as Exposed Business Services), shown in Figure 4-6, is based on a 1-to-N topology that separates distribution rules from the applications. It allows a single interaction from a partner's source application to be distributed to multiple target applications concurrently.

Figure 4-6: Exposed Broker application pattern

The Exposed Broker application pattern applies to solutions where the partner's source application initiating the operation starts an interaction that is distributed to multiple target applications across organization boundaries. It separates the application logic from the distribution logic based on distribution rules. The decomposition/recomposition of the interaction is managed by the connector component using these distribution rules.

The Exposed Broker application pattern was previously known as the Exposed Business Services application pattern.

Look for full details on the Exposed Broker application pattern in a future redbook. Until then, refer to the Extended Enterprise::Exposed Business Services 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 Exposed Broker application pattern, shown in Figure 4-7, applies to solutions where the partner's source application initiates an interaction that is forwarded to, at most, one of multiple target applications. The selection of the target application is controlled by the distribution rules that govern functioning of the connector component.

Figure 4-7: Router variation

4.2.3 Exposed Serial Process application pattern

The Exposed Serial Process application pattern (also known as Managed Public Processes), shown in Figure 4-8, is based on a 1-to-N topology where serial process rules are separated from the applications. It allows a single interaction from the partner's source application to execute a sequence of target applications.

Figure 4-8: Exposed Serial Process application pattern

The Exposed 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.

The Exposed Serial Process application pattern was previously known as the Managed Public Processes application pattern.

Look for full details on the Exposed Serial Process application pattern in a future redbook. Until then, refer to the Extended Enterprise::Managed Public Processes application pattern discussion on the IBM Patterns for e-business Web site:

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

Note 

It is expected that the Extended Enterprise::Managed Public and Private Processes application pattern will be reclassified as a composite pattern, based on the public Extended Enterprise::Exposed Serial Process application pattern and the private Application Integration::Serial/Parallel Process application pattern.

---