Various topics from software architecture part 1: the RequestResponse messaging pattern


In this series we’ll look at a couple of topics from the world of software architecture. If you have read other architecture-related series on this blog then some of them will be familiar to you by now.

I’m planning to write an updated series dedicated to Domain Driven Design during/after the summer of 2015. I don’t want to rewrite everything that’s been said in the original series. Therefore I decided to factor some major chunks out into separate posts for easier reference. Most of them appear within the series but are “hidden”, meaning it’s difficult to just refer to them separately.

We’ll start by looking at a simple pattern used in messaging, called RequestResponse.

The RequestResponse

The Request-Response pattern is a common pattern used within messaging in SOA – Service-Oriented Architecture. Consider the following interface of a service:

IEnumerable<Product> GetProducts(string region);
IEnumerable<Product> GetProducts(string region, string salesPoint);
IEnumerable<Product> GetProducts(string region, string salesPoint, DateTime fromDate);
IEnumerable<Product> GetProducts(string region, string salesPoint, DateTime fromDate, DateTime toDate);

The consumer can communicate with this interface in 4 different ways to retrieve a set of products. You can imagine that this list can grow on and on making the maintenance of the service difficult. It’s easier to assign an object to hold all these criteria:

public class GetProductsRequest
    public string Region {get; set;}
    public string SalesPoint {get; set;}
    public DateTime FromDate {get; set;}
    public DateTime ToDate {get; set;}

You can then simplify the service as follows:

GetProductsResponse GetProducts(GetProductsRequest request);

…where GetProductsResponse may look as simple as the following:

public class GetProductsResponse
    public IEnumerable<Product> Products {get; set;}

All Response objects can derive from a base response to show e.g. if the search operation was successful, if there are any specific error messages etc. The Amazon SDK for .NET uses this pattern heavily. You can check out a couple of examples here and here.

The same pattern can be used for methods which require a lot of input parameters. Instead of writing a long method signature just create an object which holds all of them. The object can then be extended instead of messing with the method signature or creating 500 overloads.

View the list of posts on Architecture and Patterns here.


About Andras Nemes
I'm a .NET/Java developer living and working in Stockholm, Sweden.

3 Responses to Various topics from software architecture part 1: the RequestResponse messaging pattern

  1. Rajesh says:

    Is it not an issue, that this pattern will introduce some complex objects being passed between the client and server.

    Rather than passing a simple string parameter, we will end up passing an json object with additional properties and retrieve a complex response object which require additional parsing to get the desired value

    • Andras Nemes says:

      If all you ever need to return is a string then RequestResponse might be overkill. However, if you want to return an object such as a Customer and its orders then it will be a complex return type anyway. Also, you can have simplified view models returned by a Response, if you don’t want to return the full object with all its properties.

  2. Pingback: Architecture and patterns | Michael's Excerpts

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog


Once Upon a Camayoc

Bite-size insight on Cyber Security for the not too technical.

%d bloggers like this: