Proxy pattern

From COMMDP
Jump to: navigation, search
Next: Reliable Multicast pattern | Return to ACP Patterns

This pattern first appeared in the paper "A Pattern Language for Application-level Communication Protocols"[1] published at IARA-ICSEA 2016 by Jorge Edison Lascano and Stephen Wright Clyde (authors of the page).

Proxy pattern

Name

Proxy (PXY)

The PXY pattern is perhaps the most used to decouple the a conversation between a client and its resource manager(s). This pattern offers location transparency, authentication, data format conversions and protocols compatibility. Instances of this pattern can be seen in applications for login validation, in SOAP-REST-SOAP API conversion services.web services that provide different data formats such as: XML, JSon, Plain text, SQL.

Intent

Like the Front End, the Proxy pattern introduces a process between a resource client and a resource manager. However, the intermediate process, called a proxy, serves other functional purposes besides re-distribution of the requests, for example it may provide authentication, access control, audit logging, and data transformation functionality. Also, the resource manager returns replies through the proxy to client, completely isolating the client from the resource manager.

Description

Problem

A client needs to access a shared resource or service provided by one or more resource managers, but the resource managers are not directly accessible to clients.

Context

No “at most once” semantics needed. The resource manager needs to be protected against direct access or attacks. The system needs to be scalable or handle spikes in load.

Solution

The solution is similar to the RR with a Front-end pattern, except that the Front-end is replaced with a Proxy process and replies are returned through Proxy instead of directly to the initiator.

Process Roles

Initiator, Proxy, Responder

Messages

Request, Reply

Scenario

Initiator -> |Request| -> Proxy
(Proxy processes |Request|)
Proxy -> |Request| -> Responder
(Responder processes |Request|)
Responder -> |Reply| -> Proxy
(Proxy processes |Reply|)
Proxy -> |Reply| -> Initiator

Semantics and Behavior

  • The Initiator and Responder have the same behavior as in the RR pattern
  • The Proxy forwards messages from the Initiator like a Front-end, but no End point is needed.
  • The Proxy has to keep track of each conversation in progress so it can forward a Reply to the correct Initiator and in the correct conversation context. i.e. Proxy must handle initiator and Responder's end points.

Consequences

One message is sent from A to B with a certain level of reliability and synchronicity through a third process (Proxy) that handles A's request. B replies back to proxy and this sends the reply to AA. This pattern provides a high level of scalability, also it protects process B from attacks, by hiding its location, i.e. location transparency.

Consequences
Quality Rating Justification
Reliability
2
This pattern can provide a modest level of reliability, specially when A receives the reply from the proxy. Then A knows that its request was not processed and may send a retry.
Synchronicity
1
This pattern does not directly address Synchronicity.
Longevity
1
This pattern does not directly address Longevity.
Adaptability for Scalable Distribution
3
This pattern can provide good distribution since it provides location transparency . A knows that a proxy will forward its request, but it does not know anything about the location of the resource manager that will reply back its request. Also the proxy process can forward its requests to other resource managers when the resource manager that it needs is busy (load balancing). It can also provide untangling of cross-cutting concerns such as the case of validation services, or data format conversions.

Known uses

  • Login services
  • Security
  • Object Brokers
  • Middlewares design
  • Resources protection
  • In general, applications that need Access or Location transparency.

Aliases and Related Patterns

Client Proxy [2]

Related work

  • Message Translator [2]
  • Client Request handler pattern, as part of the Distribution Infrastructure section in Pattern-Oriented Software Architecture Volume 4, (POSA 4), chapter 10[2]
  • Client Proxy pattern, as part of Distribution Infrastructure section in POSA 4, chapter 10[2]
  • Proxy pattern, as part of Interface partitioning section in POSA 4, chapter 10[2]
  • Broker pattern, as part of Interface partitioning section in POSA 4, chapter 10[2]

Examples of Application

Introduction : HTTP Proxy, DNS (cached responses and reply back), VPN

Illustrate VPN, other option is HTTP proxy.

Next: Reliable Multicast pattern | Return to ACP Patterns

References

  1. Jorge Edison Lascano, Stephen Wright Clyde, A Pattern Language for Application-level Communication Protocols, in, Proceedings of The Eleventh International Conference on Software Engineering Advances ICSEA 2016, 2016, pp. 22-30
  2. 2.0 2.1 2.2 2.3 2.4 2.5 F. Buschmann, K. Henney, and D. C. Schmidt, Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing, Volume 4 edition. Chichester England; New York: Wiley, 2007.
  3. “Service Design Patterns - Request and Response Management - Service Controller.” [Online]. Available: http://www.servicedesignpatterns.com/RequestAndResponseManagement/ServiceController. [Accessed: 11-Mar-2017].
  4. R. Daigneau, Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services, 1 edition. Upper Saddle River, NJ: Addison-Wesley Professional, 2011.