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: Internet ProxyMany 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