Enterprise Integration PatternsMessaging Patterns

Return AddressReturn Address

Messaging Patterns

Previous Previous   Next Next

My application is using Messaging to perform a Request-Reply.

How does a replier know where to send the reply?

The request message should contain a Return Address that indicates where to send the reply message.

This way, the replier does not need to know where to send the reply, it can just ask the request. If different messages to the same replier require replies to different places, the replier knows where to send the reply for each request. This encapsulates the knowledge of what channels to use for requests and replies within the requestor so those decisions do not have to be hard coded within the replier. A Return Address is put in the header of a message because it’s not part of the data being transmitted.


Example: Golang ChannelsNEW

In Go, channels are first-class language constructs, making it easy to specify a channel as return address by including a field of type chan in the structure to be passed as the request:

type Request struct {
  data        []int
  resultChan  chan int

A function handling requests can now publish responses to the channel provided in the Request structure:

func handle(queue chan *Request) {
  for req := range queue {
    req.resultChan <- sum(req.data)

Requestors can now specify the desired return channel with the request as in the following example:

reqChannel := make(chan *Request, 10)
go handle(reqChannel)
// Make two requests with separate return channels
request1 := &Request{[]int{3, 4, 5}, make(chan int)}
request2 := &Request{[]int{1, 2, 3}, make(chan int)}
reqChannel <- request1
reqChannel <- request2
// Receive results on respective channels
fmt.Printf("answer: %d %d\n", <-request1.resultChan, <-request2.resultChan)

Find the source for this code snippet on Github

Related patterns: Correlation Identifier, Emerging Standards and Futures in Enterprise Integration, Message Channel, Messaging, Request-Reply

Want to keep up-to-date? Follow My Blog.
Want to read more in depth? Check out My Articles.
Want to see me live? See where I am speaking next.

Enterprise Integration Patterns Find the full description of this pattern in:
Enterprise Integration Patterns
Gregor Hohpe and Bobby Woolf
ISBN 0321200683
650 pages

From Enterprise Integration to Enterprise Transformation:

My new book describes how architects can play a critical role in IT transformation by applying their technical, communication, and organizational skills with 37 episodes from large-scale enterprise IT.

DRM-free eBook on Leanpub.com

Print book on Amazon.com

Creative Commons Attribution License Parts of this page are made available under the Creative Commons Attribution license. You can reuse the pattern icon, the pattern name, the problem and solution statements (in bold), and the sketch under this license. Other portions of the text, such as text chapters or the full pattern text, are protected by copyright.

Table of Contents
Solving Integration Problems using Patterns
Integration Styles
File Transfer
Shared Database
Remote Procedure Invocation
Messaging Systems
Message Channel
Pipes and Filters
Message Router
Message Translator
Message Endpoint
Messaging Channels
Point-to-Point Channel
Publish-Subscribe Channel
Datatype Channel
Invalid Message Channel
Dead Letter Channel
Guaranteed Delivery
Channel Adapter
Messaging Bridge
Message Bus
Message Construction
Command Message
Document Message
Event Message
Return Address
Correlation Identifier
Message Sequence
Message Expiration
Format Indicator
Interlude: Simple Messaging
JMS Request/Reply Example
.NET Request/Reply Example
JMS Publish/Subscribe Example
Message Routing
Content-Based Router
Message Filter
Dynamic Router
Recipient List
Composed Msg. Processor
Routing Slip
Process Manager
Message Broker
Message Transformation
Envelope Wrapper
Content Enricher
Content Filter
Claim Check
Canonical Data Model
Interlude: Composed Messaging
Synchronous (Web Services)
Asynchronous (MSMQ)
Asynchronous (TIBCO)
Messaging Endpoints
Messaging Gateway
Messaging Mapper
Transactional Client
Polling Consumer
Event-Driven Consumer
Competing Consumers
Message Dispatcher
Selective Consumer
Durable Subscriber
Idempotent Receiver
Service Activator
System Management
Control Bus
Wire Tap
Message History
Message Store
Smart Proxy
Test Message
Channel Purger
Interlude: Systems Management Example
Instrumenting Loan Broker
Integration Patterns in Practice
Case Study: Bond Trading System
Concluding Remarks
Emerging Standards
Revision History