Gateway

Integration Patterns

Contents

Context

Problem

Forces

Solution

Example

Resulting Context

Testing Considerations

Security Considerations

Operational Considerations

Related Patterns

Acknowledgments

Context

You have an integration solution that consists of several applications that are provided by different vendors and that run on a variety of platforms. Some applications use an external resource and therefore have to communicate with it.

For example, consider the software that insurance carriers use to rate insurance policies. Although many carriers have upgraded to client-server or service-oriented architectures, some still rely on mainframe code for lines of business and for jurisdictions where the upgrade is not feasible. For example, quoting uses mainframe rating code to quote premiums. Endorsing uses the mainframe rating code to endorse policies. Renewal also uses the mainframe rating code to renew policies. In other words, several applications must integrate with the mainframe code.

Problem

How can you make the applications of an integration solution access an external system without introducing many-to-one coupling between the applications and the external system?

Forces

Accessing an external resource from an integration solution involves balancing the following forces:

• All applications that communicate directly with the external resource must have intimate knowledge of communication details such as application protocols, messaging protocols, and communication protocols. Each connection to the external resource adds dependencies between the integration solution and the resource.
• The external resource may use a different communication protocol than the communication protocol that the applications support natively. Implementing communication protocols and protocol translators is difficult and error-prone.
• Testing the integration solution involves both the external resource and the internal applications. However, because the external resource may not be accessible from the testing environment, it may not be possible to involve the external resource in tests. Also, including the external resource in tests may prevent testing error or boundary conditions.

Solution

Add a Gateway component that abstracts the access to the external resource. The gateway presents a single interface to the integrated applications while hiding the external resource interface. In addition, the gateway encapsulates any protocol translation that may be necessary to communicate with the external resource.

Figure 1 shows the gateway replacing direct access to the external resource. The applications that collaborate with the gateway and with the external resource are highlighted in blue, and the shapes at the end of the connectors denote different interfaces.

Figure 1. Gateway abstracting access to the external resource

The applications that need to communicate with the external resource do so by sending messages to the gateway interface. The gateway handles any protocol translation that is needed and then passes the message to the external resource. In effect, the gateway encapsulates all access to the external resource. Consequently, the applications do not require information about what it takes to communicate with the external resource.

The gateway also catches errors signaled by the external resource. The gateway may be able to handle errors such as communication timeouts and retries internally. Otherwise, it passes any errors that it cannot handle locally to the appropriate application. In effect, the gateway centralizes some error processing, but it probably does not centralize all that error processing. This frees applications from dealing with these errors. Moving the error handling logic from applications to the gateway guarantees consistency.

The communication through the gateway is asymmetric. The control flows from the applications to the external resource. In other words, the gateway only provides a point through which applications call the external resource. The gateway does not support inbound access to the applications. Table 1 shows the responsibilities and collaborations of the gateway.

Table 1: Gateway Responsibilities and Collaborations

After you decide to use a gateway, you have to decide where the gateway will reside. The following are two possibilities:

• Internal gateway for enterprise integration. An internal gateway resides in the same jurisdiction as the applications. Therefore, external applications do not use the gateway, and you have full control over it.
• External gateway for business-to-business (B2B) integration. An external gateway serves other enterprise applications. An external gateway may even be provided by a third party, such as the resource owner. This configuration, which is shown in Figure 2, means that you no longer have to implement the gateway. However, using an external gateway adds a dependency on an outside component.

Figure 2. An external gateway that resides outside system boundaries (B2B integration)

An internal gateway provides the most flexible solution. You make the decisions about its interface, about the protocol translations it performs, and about the errors it handles. If you have an external gateway, and you want to reduce the coupling with it, you can use an internal gateway and regard the external gateway as the resource. This configuration is known as gateway chaining. Figure 3 illustrates this configuration.

Figure 3. Gateway chaining: removing dependencies between applications and an external gateway

Gateway chaining translates into functional composition. If you have several gateways, and each gateway is specialized to handle a different aspect such as protocol translation or encryption, you can chain them together to create a composite gateway that handles each aspect sequentially. Chaining gateways might be complicated if the gateways make conflicting assumptions about tasks in the environment such as error handling.

Example

Consider a property and casualty system where separate applications implement policy management, general ledger, accounts payable, billing, and claims functionalities. The policy management, the claims, and the billing applications connect through sockets to an external print system to print policies, claims, and statements. This configuration is illustrated in Figure 4.

Figure 4. Property and casualty system without a gateway

In Figure 4, the billing, claims, and policy management applications access the print system directly. The round connectors denote a socket-based interface. Print system upgrades, such as replacing the socket-based interface with a Web service interface, require upgrading three systems: the policy management system, the claims system, and the billing system. These changes are expensive. Additionally, if the print system belongs to a different organization, the owners of the property and casualty system cannot control the timing of the upgrade. An upgrade during the peak renewal season would have a negative impact on the business.

Figure 5 shows the property and casualty system modified to use a gateway. The billing, claims, and policy management applications no longer access the print system directly. Instead, the billing, claims, and policy management applications access the print system through a gateway. The round connectors denote a socket-based interface, and the square connectors denote a Web services-based interface. This configuration reduces the costs that are associated with a print system upgrade.

Figure 5. Property and casualty system with a gateway

Resulting Context

Using a gateway to provide a single point of access to an external resource has the following benefits and liabilities:

Benefits

• Reduced coupling**.** The gateway encapsulates access to the external resource. Applications that use the resource no longer require information about how to access that external resource.
• Reduced application complexity. Individual applications do not have to implement the communication protocols required to communicate with the external resource. In addition, the gateway can implement some of the error handling that each application would otherwise have to perform.
• Improved integrability. The gateway provides a single point of access for the external resource. This facilitates integration with external resources such as an Enterprise Resource Planning (ERP) system, a Customer Relationship Management (CRM) system, or another similar system.
• Improved security. A single point of access represents a single point of control. You can use this single point of access to implement security policies and to bridge between different security realms. It also allows you to meter access to the external resource and to implement business rules that control access.
• Improved performance through optimization. The gateway provides a logical place to optimize the communication protocol for use with the external resource. Optimization might include batching similar requests or caching results.

Liabilities

• Reduced performance through overhead. The gateway replaces direct communication, adding an intermediate layer. This translates into increased latency compared to direct communication.
• Increased maintainability effort. A gateway extends your integration solution with another component. This translates into additional implementation, configuration, testing, deployment, and management work.
• Dependency of the gateway interface. Designing the gateway requires foresight about the interactions between the applications and the external resource. If you have to change the gateway's interface in a way that breaks compatibility, you have to change all the applications that access it.
• Reduced availability. All access to the external resource passes through the gateway. From an availability perspective, the gateway represents a single point of failure.

Testing Considerations

Using a gateway improves testability on both sides in the following ways:

• Applications access the external resource solely through the gateway. A mock gateway can receive messages, return predefined responses, and exercise error handling logic. In other words, you can test the system without accessing the external resource.
• Because the external resource receives requests from the gateway, you can test the gateway by relaying requests to the external resource independent of the applications.

Figure 6 shows these test areas. The top diagram shows a mock gateway for testing the interaction with the applications. The bottom diagram shows a mock gateway for testing the interaction with the external resources. The shaded arrows indicate the test areas.

Figure 6. Using a mock gateway for testing

A gateway also facilitates load testing. Testers can use the gateway to insert test loads into the integration solution to measure the external resource's performance.

Security Considerations

Accessing an external resource through a gateway has the following security implications:

• A single point of access facilitates enforcement of a uniform security policy. However, it also represents a central point of attack.
• A gateway allows bridging between different security realms. For example, a gateway can mix different security context management policies, such as impersonation on one side and consolidation on the other. However, the gateway only provides a place where the mapping between the two can be handled. You must implement the mapping separately.

Operational Considerations

A gateway represents a single point of access and may cause contention among the applications that communicate with the external resource. You should monitor access to the external resource and act proactively when the first signs of contention appear. This single point of access also helps you to meter access to the external resource, to monitor the external resource, and to audit the external resource.

Related Patterns

The Gateway pattern described here relates to the following patterns:

• Implementing Gateway with Host Integration Server 2004 This pattern uses the Global Bank scenario to show how you can use Host Integration Server 2004 to implement Gateway.
• Gateway [Fowler03]. Martin Fowler discusses Gateway in the context of enterprise applications. He also covers the relationship with Façade and Adapter [Gamma95]. Fowler's Gateway is fine-grained at the object level. However, in the context of integration, Gateway is coarse-grained at the platform level.
• Messaging Gateway [Hohpe04]. Messaging Gateway wraps message-specific method calls, exposes domain-specific methods, and encapsulates access to the messaging system. Hohpe and Woolf also explain how to create composite gateways by using gateway chaining. A composite gateway permits you to use a gateway that encapsulates a single aspect together with other gateways to deal with several aspects.
• Remote Proxy [Buschmann96].Gateway can be regarded as a refinement of the Remote Proxy pattern. Remote Proxy deals with distributed components in the general sense and provides the interprocess communication (IPC) mechanisms for communication with remote objects. Gateway is designed for integration solutions and therefore assumes that the integration infrastructure is available.
• Service Interface [Trowbridge03]. Service Interface exposes functionality as a service and provides an entry point for inbound requests. In effect, the control flows in the opposite direction compared to Gateway.

Acknowledgments

[Buschmann96] Buschmann, Frank; Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons Ltd, 1996.

[Fowler03] Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.

[Gamma95] Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

[Hohpe04] Hohpe, Gregor, and Bobby Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2004.

[Trowbridge03] Trowbridge, David; Dave Mancini, Dave Quick, Gregor Hohpe, James Newkirk, and David Lavigne. Enterprise Solution Patterns Using Microsoft .NET. Microsoft Press, 2003. Also available on the MSDN Architecture Center at: https://msdn.microsoft.com/en-us/library/ms998469.aspx.

Start | Previous | Next

© Microsoft Corporation. All rights reserved.