Messaging Patterns | |
HOME PATTERNS RAMBLINGS ARTICLES TALKS DOWNLOAD BOOKS CONTACT |
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 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.
|
© 2003, 2019 • Bobby Woolf • All rights reserved. |