Enterprise Integration PatternsConversation Patterns
HOME    PATTERNS    RAMBLINGS    ARTICLES    TALKS    DOWNLOAD    BOOKS    CONTACT

Proxy

Conversation Patterns

Previous Previous   Next Next

A participant engages with a conversation partner.

How can a participant communicate with a partner that is not visible or not reachable?

  • In widely distributed networks not all services may be reachable directly, for example because services use different addressing schemes or are intentionally separated into multiple segments.
  • Access to a set of participants may be restricted so that a direct connection is not allowed.
  • A central component may want to screen communication between participants or limit which participants can engage in a conversation.
  • A participant may want to stay anonymous by not connecting so another participant directly.

Send messages through a Proxy, who forwards them to other participants.

The Proxy conversation involves the following participants:

  • The Initiator initiates the conversation by sending a message to the Proxy.
  • The Proxy listens for messages and forwards them to the Partner.
  • The Partner waits for incoming messages and replies accordingly.

While only the transmittal of a single message is shown in the solution sketch, a Proxy can support any two-party conversation. For example, to implement Asynchronous Request-Response", the Proxy has to forward the response message back to the Initiator. Most conversations supported by a Proxy are point-to-point conversations, meaning the Initiator exchanges messages with a specific, well-known Partner.

Most Proxy are uni-directional, meaning they allow the Initiator to establish a conversation (which can include response messages), but it does not allow the partner to do so. This protects participants that are behind the Proxy from inbound conversation requests.

While a Proxy does not buffer messages, a Proxy that engages in a conversation may have to track the conversation state in order to forward messages appropriately. For example, if the Initiator uses a HTTP connection to connect to the Proxy, which in turn connects to the Partner via HTTP, the Proxy has to maintain the relationship between those two connections so that incoming responses are forwarded to the right Initiator.

Typically, Proxys are involved in many concurrent conversations.

Initiators may intentionally use a Proxy to hide their true identity or to appear as being from a different locale. This is the principle behind many proxy servers, which for example allow Internet access to location-restricted media content because the Proxy resides in a different location.

A Proxy "sees" all messages exchanged between the participants. The participants must therefore trust the Proxy or use additional encryption on the messages.

A Proxy may require the Initiator to identify itself or to authenticate to the Proxy. This is the case in environments where communication between the groups of participants is designed to be restricted. This setup is often used to separate corporate networks from the Internet.

A Proxy generally increases latency because two hops are necessary. A Proxy also needs to handle many concurrent conversations between different participants and can become a bottleneck. Depending on the underlying protocol, a Proxy may need to be stateful in that it needs to understand the state the conversation is in. In the simplest case it may need to be aware of whether an Initiator has already authenticated or not.

The Proxy needs to deal with time-out and error conditions on the Partner side and relay such errors to the Initiator. This is simplified if the protocol already includes the transport of error conditions as is the case with HTTP.

Example: Cross-domain Proxy for AJAX Applications

For security reasons, JavaScript running in a Web browser can only connect to services in the same domain where the script originated ("same origin policy"). Many browser mash-ups and other JavaScript applications need to access external data sources, though, for example, a housing map needs to access a housing listing service. To gain access to this external service, the JavaScript connects to a Proxy within the same domain as the JavaScript source. The Proxy relays requests to the external service. (see Ajax Design Patterns)

Example: Internet Proxy

Many corporate environments restrict access to the Internet by limiting the sites that are available to be connected to or by actively monitoring traffic. This is typically enforced by not allowing direct outbound connections from the corporate network, but forcing clients to first connect to an Internet proxy, which relays the request to the destination. In most cases, users must authenticate to the Proxy so that site visits can be attributed to the logged-in user.

Related patterns: Asynchronous Request-Response



Introduction
Overview
Preface
Table of Contents
Introduction
Describing Conversations
Choreography
Orchestration
Hypermedia State
Conversation Vocabulary
Discovery
Dynamic Discovery
Advertise Availability
Consult Directory
Referral
Leader Election
Starting a Conversation
Three-Way Hand Shake
Acquire Token First
Rotate Tokens
Verify Identity
User Grants Access
Basic Conversations
Fire-and-Forget
Asynchronous Request-Response
Request-Response with Retry
Polling
Subscribe-Notify
Quick Acknowledgment
Intermediaries
Proxy
Relay
Load Balancer
Scatter-Gather
Managing Distributed Systems
Heartbeat
Resource Management
Incremental State Build-up
Lease
Renewal Reminder
Ensuring Consistency
Ignore Error
Compensating Action
Tentative Operation
Coordinated Agreement
Appendices
Bibliography