Home
    1. What are the current issues with our "Message"?
    2. How might we fix these issues?

What are the current issues with our "Message"?

Not a lot really! Just a number of little things that add up to a lot in terms of a not-so-positive user experience! I'd just be proposing a few tweaks. The following issues have been raised by others too.
  1. The concept of multiple named body locations is definitely something that is causing problems. Just look at all the anti-patterns that have developed around it - ActionUtils.setTaskObject etc. This issue cannot simply be documented away!! I think a single "primary" un-named payload location in the message would help aleviate some confusion/frustration. That's not to say that the code using the message can't set a collection of data as the payload.
  2. It's Interface based. This means we require Factories etc. Since it's just a relatively simple/lightweight Value Object, why should we define it as an Interface? Serialization/Deserialization etc could (and IMO should) be handled orthogonally. Lets try to keep logic out of our message!!

    I'm not so concerned about this one. I'd just like us to be more clear about why we're using an interface. If it's for flexibility, then what sort of flexibility? When? Why? If we do go with an interface, then lets have some visible implementations of that interface e.g. "BasicMessage" or something that people can create and work with directly.

  3. The current Message model misses out on a number of opportunities to use "well known" types e.g. java.util.Collection types. Apart from the fact that people recognize these types and are very comfortable working with them, they would make the Message easier to work with using expression and scripting languages such as OGNL, Groovy, Jython etc, simply because many of these tools have explicit usability optimizations around most java.util.Collection types (java.util.Map, java.util.List, java.util.Properties etc).

    In fact, we have our own "Properties" type on the message. This is bound to cause confiusion/frustration wrt java.util.Properties.

  4. Addressing info done as EPRs is too low level. In the case of replyTo etc, it also makes assumptions about the entity that may eventually use the EPR i.e. that they can use it. What if the entity/service that eventually uses the replyTo address is a C, perl etc based entity and the EPR is JMS based? Sure there are ways around this, but if the Addressing info was just Service cat:name, then the entity/Service could look up an EPR that better suits. Call these "Logical EPRs" Vs "Physical EPRs" if the idea of dropping EPRs from the message is too difficult for us to swallow.
  5. We have no explicit MIME support on payloads (body or attachments). This of course is not really an architectural issue.

How might we fix these issues?

See Message for one approach.