4.3 Application patterns

< Day Day Up >

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: Also known as Managed Public Processes

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.

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

click to expand
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

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 that differentiate this domain, suitable for high-level architectural design. This is 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.3.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

click to expand
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 78, is divided into a number of logical components:

The Source Application tier 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 tier represents any business rules associated with the connection, such as data mapping rules and security rules.
The Target Application tier 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.

click to expand
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 a response within the scope of the interaction.

click to expand
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.3.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 partner applications concurrently.

click to expand
Figure 4-6: Exposed Broker application pattern

The Exposed Broker application pattern applies to solutions where the source application starts an interaction that is distributed to multiple target applications across organization boundaries. It separates the application logic from the distribution logic based on broker rules. The decomposition/ recomposition of the interaction is managed by the Broker Rules tier.

The Exposed Broker pattern reuses the Exposed Direct Connection pattern to provide connectivity between the tiers. The Broker Rules tier may support Message variation or Call variation (or both variations) of the Exposed Direct Connection pattern.

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

Business and IT drivers

The primary business driver for selecting this Application pattern is to allow one application to interact with one or more of multiple partner applications across organization boundaries. Using a hub-and-spoke architecture instead of a point-to-point architecture allows for the seamless integration of applications while minimizing the complexity. A request for information can be routed to one of many targets or simultaneously to multiple targets. The resulting request message can be decomposed into multiple request messages, and the reply messages then recomposed into a single reply message using appropriate recomposition rules.

This externalization of routing, decomposition, and recomposition rules from individual source and target applications increases the maintainability and flexibility and reduces the enterprise wide integration complexity.

The primary IT driver for selecting this Application pattern is to allow loose coupling of clients and services with minimum modification to each. The solution should allow for multiple transmission protocols to be used and for transformation of protocols between client and service.

Solution

This Application pattern, as shown in Figure 4-6 on page 83, is divided into a number of logical components:

The Source Application tier represents one or more applications that are interested in interacting with the target applications in another organization.
The Broker Rules tier reduces the proliferation of direct connections. In addition, it supports message routing, decomposition and recomposition, message enhancement and transformation. These rules are often captured as business rules that govern the behavior of the broker tier. This tier also uses a work-in-progress data store to retain the intermediate results from the responses coming back from target applications until all the necessary responses are received.
The Target Application tier represents new, modified existing, or unmodified existing applications in a partner organization. These applications are responsible for implementing the necessary business services.

Guidelines for use

To increase the flexibility of the solution and responsiveness to changing business requirements, it is recommended that particular attention is paid to definition of reusable messages/services that pass through the Broker tier.

Robust transaction processing systems should be used to implement the back-end applications to ensure availability, scalability, and performance.

A decomposition implementation (one source message to multiple target messages) requires state persistence and re-composition of the response messages.

Standards should be used where possible to minimize future changes required to the source and target applications. This is particularly important in an inter-enterprise solution.

Security is a primary concern when opening up business processes to external organizations. The solution should include robust security mechanisms to protect resources.

Benefits

The benefits of this Application pattern are:

It allows the integration of multiple, diverse applications between partner organizations.
It minimizes the impact to existing applications.
The broker provides routing services, relieving the source application from being aware of the target application.
The broker provides transformation services that allow the source and target to use different communication protocols.
The broker can provide decomposition/recomposition of messages, allowing one request from the source to be satisfied using multiple target applications. The fact that the response is a composite of multiple requests and responses is hidden from the source application.
The use of a central broker minimizes the impact of changes in location of the target application.

Limitations

Logic must be implemented at the broker for routing and decomposition/ recomposition tasks.

Putting the Application pattern to use

ABC Electronics consists of multiple Retail stores that depend on external Wholesale companies to supply inventory. The Retail stores need to request the delivery dates of those supplies before ordering in order to select the Wholesale company that can deliver the quickest. Currently, all interaction between the Retail departments and the external Wholesale companies are done over the phone or by mail.

A solution must be found to allow the Retail stores to request delivery dates from the Wholesale companies. To eliminate the need for the Retail departments to know which Wholesale company carries which supplies, a Broker is needed to take incoming requests and direct them based on part numbers to the Wholesale company that carries them. In the event that a part is carried by multiple Wholesale companies, the broker must get delivery dates from each and return the best date and the Wholesale company name that can supply it to the Retail department.

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.

click to expand
Figure 4-7: Router variation

Business and IT drivers

The requirements and their solution are less complex than those defined by the Exposed Broker application pattern in that decomposition of messages and transmission to multiple targets simultaneously is not required.

This pattern is also applicable to the 1:1 application integration scenario where source and target do not adhere to the same message and interface formats and therefore require a transformation service in the EAI Infrastructure.

Solution

This Application pattern, as shown in Figure 4-6 on page 83, is divided into a number of logical components:

The Source Application tier represents one or more applications that are interested in interacting with the target partner applications, one target at a time.
The Router Rules tier represents any business rules associated with the message handling, such as routing and transformation. It receives requests from multiple source applications and routes them intelligently to the appropriate partner applications. This tier implements minimal business logic.
The Target Application tier represents new, modified existing, or unmodified existing applications. These applications are responsible for implementing the necessary business services.

Guidelines for use

The guidelines for this application pattern are the same as those for the Exposed Broker application pattern.

Benefits

The benefits of this Application pattern are:

It allows the integration of multiple, diverse partner applications.
It minimizes the impact to existing applications.
It provides routing services, relieving the source application from being aware of the target application.
It provides transformation services that allow the source and target to use different communication protocols.
The use of a central router minimizes the impact of changes in location of the target application.

Limitations

With the Router variation, there is limited ability in the router to manipulate the requests. It performs intelligent routing and protocol transformation, but does not have the ability to send simultaneous requests to the target applications based on one incoming request, nor does decomposition / recomposition ability.

Putting the application pattern to use

ABC Electronics consists of multiple Retail stores that order supplies from external Wholesale companies. The Retail stores have a need to request the delivery dates of those supplies before ordering. Currently there is no integration of the Retail and partner Wholesale applications. All interaction between the two are done over the phone or by mail. A solution must be found to allow the Retail stores to request delivery dates from the partner Wholesale companies. To eliminate the need for the Retail departments to know which Wholesale company carries which supplies, a Router is needed to take incoming requests and direct them based on part numbers to the Wholesale company that carries them.

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

click to expand
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.

< Day Day Up >