Request-Reply pattern

From COMMDP
Jump to: navigation, search
Next: Request-Reply with Acknowledge 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).


Request-Reply pattern

Name and Overview

Request-Reply(RR)

The RR pattern is perhaps the most pervasive protocol design pattern; instances or applications of this pattern can be seen in the vast majority of modern communication protocols, including protocols in layers below the application level. It simply involves one process sending a message (a request) to another and waiting for a reply from that process.

Intent

It addresses the problem where a process, A, needs to access or use shared resources in another process, B, with a reasonable degree of reliability and synchronicity. The solution consists of A sending B a message (i.e. a request) and B sending back a message (i.e. a reply) after processing the request. For A, this simple mechanism provides a modest level of reliability and synchronization, because the reply proves that B received the request and can provide relevant information about B’s state. Furthermore, if A does not receive a reply within a specific amount of time (i.e., a timeout), it can resend the request. It can continue to timeout and retry until it eventually receives a reply or it exceeds some maximum number of retries. This “timeout/retry” behavior is the essence of the request-reply pattern.

Description

Problem

One process A (client) needs to access a shared resource or service provided by another process B (a resource manager), with a modest degree of reliability

Context

There is no guarantee of “at most once” semantics needed for the execution of the requested service

Solution

The client initiates the conversation by sending a request to resource manager, which receives the request, processes it, and sends by a reply. The client waits for the reply for a certain amount of time, know as the timeout. If it arrives, the conversation finishes successfully. If not, the initiator tries sending the request again. The initiator will eventually give up after a certain number of retries, know as the retry max. This basic behavior is referred to as timeout/retry. A possible variation is that a Request is send and a Reply is not expected.

Participants

Initiator, Responder.
In a client-server architecture and in many distributed systems, in general, the client is a conversation initiator and The resource manager is a responder

Messages

Request, Reply

Scenario

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

Semantics and Behavior

  • After the Initiator sends the Request, it waits for the reply, up to x time units (the timeout)
  • If the reply does arrive with timeout, the Initiator response the Request
  • Attempts are repeated up to y times (the retry max)

Consequences

  • Because a message is sent from A to B and a reply is send back (when B is operating as expected and message are delivered successfully), then the pattern can provide a modest amount of reliability and synchronicity.
  • RR's simplicity allows instances of it to be aggregated into more complex protocols.
  • Also because of its simplicity, it can be easily combined with other patterns.
Consequences
Quality Rating Justification
Reliability
2
This pattern can provide a modest level of reliability. Specifically when A receives the reply from B, if the reply is not received, A may retry to send the request. Reliability is limited to the Initiator process, this pattern does not assure the reception of the reply, hence the Responder will have to either not save previous replies for saving time in processing, or discard its cached data after a timeout.
Synchronicity
2
This pattern provides a degree of synchronization. Specifically, when B receives the request from A, B knows something about the state of A and when A receives the reply from B, A knows something about the state of B. However, the amount or type of synchronization is limited to information that be derived from the request and reply messages and their receive event.
Longevity
1
This pattern is not directly concerned with long conversations, but could be combined with patterns that do address this quality
Adaptability for Scalable Distribution
1
This pattern does not directly address scalable distribution, but could be combined with patterns that do allow for scalable distribution

Known uses

  • Connectionless communications such as basic HTTP implementations
  • One way communications
  • Non-reliable communications
  • Asynchronous calls
  • Basic pattern to be reused in other communication patterns.
  • RPC implementations

Aliases and Related Work

Aliases

  • Request-Response[2]
  • Request-Reply [3] (Enterprise Integration Patterns)
  • Single-Request-Response [4] (Transport Message Exchange Pattern)

Related Work

  • Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions[5]
  • Request/Response Design Pattern [6]
    • Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services[7]
  • Overview of JMS Request-Response and Design Patterns [8]
  • RequestResponse API Design Pattern [9]
  • Request/reply patterns[10]
  • Remote Process Invocation-Request and reply [11]
  • Request and reply messages [12]
  • The request reply family of group routing protocols [13]
  • Request/Acknowledge [14]
  • RPC API [15] [16]

Examples of Application

Instances of Request-Reply pattern occur frequently in ACP's, including in many standard TCP-based ACP's like Echo [17] [18], SNMP's Agent-Manager communication [19] and HTTP 1.0[20]. In some cases, a single instance of the Request-Reply pattern comprises the entirety for the ACP, as with the Echo protocol. In other cases, many instances of the Request-Reply are integrated into an ACP as in SNMP or they are combined with other types of communication. Following are some additional details for just two ACP's that use RR, namely Echo and HTTP1.0.

Echo protocol Scenarios

- As a Useful debugging and measurement tool
 "An echo service simply sends back to the originating source any data it receives." [18]
- An UDP Based Echo Service
 "Another echo service is defined as a datagram based application on UDP.  A server listens for UDP datagrams on UDP port 7.  When a datagram is received, the data from it is sent back in an answering datagram." [18]

HTTP1.0 Scenario

- A client establishes a connection with a server to send a request, the client sends the request containing a method, (either GET, HEAD, or POST), the URI, protocol version, client information, and maybe body content. The server responds with a message containing: protocol version, error (or success) code, server information, and perhaps body content [20].
Next: Request-Reply with Acknowledge 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. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Gregor Hohpe, Bobby Woolf, Published Oct 10, 2003 by Addison-Wesley Professional. Part of the Addison-Wesley
  3. http://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html
  4. https://www.w3.org/2000/xp/Group/1/10/11/2001-10-11-SRR-Transport_MEP
  5. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Gregor Hohpe, Bobby Woolf, Published Oct 10, 2003 by Addison-Wesley Professional. Part of the Addison-Wesley
  6. http://www.servicedesignpatterns.com/ClientServiceInteractions/RequestResponse
  7. 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.
  8. https://docs.oracle.com/cd/E11036_01/alsb30/interopjms/MsgIDPatternforJMS.html#wp1050154
  9. http://wiki.apidesign.org/wiki/APIDesignPatterns:RequestResponse
  10. M. Casciaro and L. Mammino, Node.js Design Patterns - Second Edition, 2nd Revised edition edition. Birmingham: Packt Publishing - ebooks Account, 2016. pp. 475
  11. “Remote Process Invocation—Request and Reply | Integration Patterns and Practices | Salesforce Developers.” [Online]. Available: https://developer.salesforce.com/docs/atlas.en-us.206.0.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_remote_process_invocation_state.htm. [Accessed: 26-Jan-2017].
  12. D. A. Chappell and R. Monson-Haefel, Java Message Service, 1 edition. O’Reilly Media, 2000. pp. 73
  13. J. A. Cobb and M. G. Gouda, “The request reply family of group routing protocols,” IEEE Transactions on Computers, vol. 46, no. 6, pp. 659–672, Jun. 1997.
  14. http://servicedesignpatterns.com/clientserviceinteractions/requestacknowledge
  15. “Service Design Patterns - Web Service API Styles - RPC API.” [Online]. Available: http://www.servicedesignpatterns.com/WebServiceAPIStyles/RemoteProcedureCallAPI. [Accessed: 11-Mar-2017].
  16. 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.
  17. “Echo Protocol,” Wikipedia. 09-Dec-2016.
  18. 18.0 18.1 18.2 J. Postel, “Echo Protocol.” [Online]. Available: https://tools.ietf.org/html/rfc862. [Accessed: 21-Feb-2017].
  19. “Simple Network Management Protocol,” Wikipedia. 18-Jan-2017.
  20. 20.0 20.1 R. T. Fielding, T. Berners-Lee, and H. Frystyk, “Hypertext Transfer Protocol -- HTTP/1.0.” [Online]. Available: https://tools.ietf.org/search/rfc1945. [Accessed: 21-Feb-2017].