A part of the work we are doing on Mule 3 is to clean up and simplify the existing design. One thing I recently started working on is untangling the relationship between MuleMessage and MessageAdapter and review the use of message adapters throughout the code base.
The current design around these two is somewhat awkward: MuleMessage extends MessageAdapter. I consider this to be the exposure of an implementation detail rather than a good design choice. The MessageAdapter is a throwback from the first Mule architecture, but we’ve moved on from that so it is high time to revisit this approach.
One example of the problems we face with message adapters in general is the use of persistent queues. They are used e.g. in our high availability offering but also when you put a
Taking a step back and looking at our existing MessageAdapter implementations, we realized that most of them do not follow the adapter pattern anyway. Rather, most copy all of the transport message’s properties into the MuleMessage and some also transform the payload. So in Mule 3 we will get rid of the MessageAdapter altogether. Instead, we’ll formalize the current approach and we’ll introduce a MuleMessageFactory. The task of that factory is to take the transport specific message and build a MuleMessage out of it.
The good thing for Mule users is that API of MuleMessage will not change. MuleMessage will lose the relationship to MessageAdapter but that should not affect anyone just using Mule from config or the MuleMessage API.
Now, if you have written a transport you’d be interested to hear more about this change. I’m working on an update guide that will explain the usage patterns of the MuleMessageFactory. It should be available by the time we merge the message adapter removal work back into the main Mule 3.x development branch.
