Patterns , Request and Response – Why

Recently i was asked by members of my team why we used the Request and Response Messaging pattern, it lead to a interesting conversation form which we resolved number of high level points, i thought i might share them here.

When dealing with 2 systems with defined edges such as a group of services which perhaps form a SOA [Service Orientated Architecture] , it is quite often advantageous to implement strict communication standards.

In the physical world when we enter into a conversation with another person it is considered good manners to wait for a response when we have made a statement or asked a question in short we have spoken and set by convention a expectation that we will receive some form of response.

We often that this is form of communication collaboration is more constructive than constantly communicating in such a fashion as to demand things form our audience as if they are in fact slaves to our every wish as opposed to collaborators in a well mannered interchange.

These two social interchange patterns can be summarised in the following definitions:

# Ask don’t tell
# Tell don’t ask

We see both these communication constructs in the software world.

Tell Don’t Ask
Traditionally in classic code we consume objects and call there methods directly passing to them parameters. The expectation with this style of programming is that the object will just do what we say when we say it as a consumer.
The object becomes a slave to the consuming code.

Ask Don’t Tell
There is a alternative to the demanding style of code we demonstrated with the ‘Tell Don’t Ask’ methodology. We can make a active choose to communicate with other objects in a way which treats the objects with good manners.

We can request the object to perform an operation for us and then wait for a well mannered response form the object.

When work in this way we can establish a convention that say in simple dialect.

When i send a request to an object, that object is guaranteed to make a response even if the object has nothing to say back to me other than it has completed my request and the status of that request at the point it was completed.’

Why would we want to do this?
By engaging in a collaborative relationship within the domain space with other objects we achieve a number of thing.

# We protect the object interface and give the object room to grow and evolve as all it is expecting is a Request and all we are expecting form it is a Response.

# We make the object a collaborator in a domain relationship and therefore we honour its right to control its own state and to hide form us its implementation.

# We guarantee a response from the object by convention , therefore we are free to engage in other conversations while listening for our object to come back and talk to us.

#We can ask the object to enrol in a group chat were perhaps we have multiple collaborators who are responsible each other and to our initial object for the overall context of the conversation. We can even become the orchestrater of the group and direct the flow of the conversation to a active a collective result.

#We are implementing a true black box SOC [ Separation of Concerns] paradigm at a object level with this pattern.

#Messages can be made durable and persisted if need be

#Messages can take part in a retry type pattern

#We are modelling the real world with this relationship

I hope this post gives food for thought and provokes deeper conversations into collaborative code relationships as opposed to slave based enforced patterns.

About Beth Martin
software developer

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 )

Google photo

You are commenting using your Google 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

%d bloggers like this: