Your MOM sucks and doesn't belong here has a few thoughts on deploying MOM.
For me, one of the major benefits to using a MOM architecture (or specifically, an ESB architecture) is the decentralizing of future development/integration efforts.
If a particular process over MOM has an input and one or more outputs, we can put a very succinct set of data in the input and evolve the process itself over time to pull in missing information so that it can fulfill its job.
In other words, a client on the MOM can inject a message with simple routing information (identifying a target) and a high level verb (one of a few, think REST). The process can make decisions on how to fulfill the verb for a given target, and in the process of doing so, talk to any number of back end systems to get data it needs. It is the target + verb that is significant.
The converse of this is to update the client to support additional functionality in a permutation of target endpoint and verb by adding more data to the message (that could be easily discovered by the process). While still modifying the process to use the new data.
Of course some data can't be discovered, and must be given by the client. This data is usually identifiable early on.
So now the onus of fulfilling events is on the MOM process, which can be re-configured at runtime or with a quick bounce, and this being MOM, you won't lose any messages, unlike what could happen with a client redeployment.
Leave a comment