Messaging Mapper	Pattern Catalog  Previous   Next
	Site Home • Patterns Home • Table of Contents

When integrating applications using messaging, the data inside a message is often derived from domain objects inside the integrated applications. If we use a Document Message, the message itself may directly represent one or domain objects. If we use a Command Message, some of the data fields associated with the command are likely to be extracted from domain objects as well. There are some distinct differences between messages and objects. For example, most objects rely on associations in the form of object references and inheritance relationships. Many messaging infrastructures do not support these concepts because they have to be able to communicate with a range of applications, some of which may not be object-oriented at all.

How do you move data between domain objects and the messaging infrastructure while keeping the two independent of each other?

Create a separate Messaging Mapper that contains the mapping logic between the messaging infrastructure and the domain objects. Neither the objects nor the infrastructure have knowledge of the Messaging Mapper's existence.

The Messaging Mapper accesses one or more domain objects and converts them into a message as required by the messaging channel. It also performs the opposite function, creating or updating domain objects based on incoming messages. Since the Messaging Mapper is implemented as a separate class that references the domain object(s) and the messaging layer, neither layer is aware of the other. The layers don't even know about the Messaging Mapper.

Related patterns: Aggregator, Canonical Data Model, Command Message, Document Message, Message Router, Message Translator

For a full description of the pattern see:

Enterprise Integration Patterns Gregor Hohpe and Bobby Woolf ISBN 0321200683 650 pages Addison-Wesley

Home • Patterns • Table of Contents

Previous   Next

© 2003 • Bobby Woolf • All rights reserved.