Message Granularity

Posted by Dru Sellers on October 18, 2009

So, how big is a message? What all should you include in a message? What if you are in a bigger company, how do you roll messaging out across an enterprise? Honestly, I am still learning here too, but here are some rules of thumb I have picked up along the way:

  1. You want more than one uber message for the whole company
  2. You want a canonical message model (this means that messages aren’t tied to any one application)

    • This one I am still not 100% sure on, but I am pretty sure its correct
  3. Each message should be a distinct unit or event
  4. It should represent a business transaction as an atomic, self-contained and self describing unit of work (don’t pass primary keys around)
  5. Don’t worry about the size of the message unless you have to. I don’t even think about it anymore. The size (bytes) of the message should be considered as it can affect how fast your message can go across the wire. If this level of speed isn’t a concern, then I wouldn’t worry about it. ie if you can wait 0.10 of a second or more than I wouldn’t sweat it.

Fine grained messages create more overhead from a management perspective so each one needs to earn its place.

  • Governance
    • Build a way to track your messages. Even if its in excel.
    • Once a message is deployed, be careful about upgrades. I try to follow Udi’s advice that instead of modifying the message I make a new one.
    • Make sure that only one system / department owns the message. This will make changes a bit clearer to see who can initiate them.

Links:
http://www.eaipatterns.com/CanonicalDataModel.html
http://fuzzypanic.blogspot.com/2005/04/canonical-message-format-and-xml.html
http://fuzzypanic.blogspot.com/2006/05/eda-lessons-learned-canonical-message.html

About Dru Sellers

Sr. Software Engineer at Dovetail Software.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.jeromepineau.com Jerome Pineau

    I’m going to assume you are referring to an SOA message-bus type of architecture in which case I would like to offer the following comments.

    “Each message should be a distinct unit or event” – yes in a stateless system but within a coordinated workflow paradigm, not always realistic.

    “Don’t worry about the size of the message unless you have to.” – Naive. You will always have to worry about scalability issues in an enterprise architecture. Btw compression is not typically a long-term solution.

    “The size (bytes) of the message should be considered as it can affect how fast your message can go across the wire.” – Of course it will affect that as your users/traffic scales up and that’s not even considering latency issues. It’s not only about how much you can transport, but fast you can transmit. Message size affects both.

    “Build a way to track your messages. Even if its in excel.” – I don’t see how you track messages in Excel! Can you give a real-life enterprise example?

    “Once a message is deployed, be careful about upgrades” – Upgrades to the interface (contract) or to the content??

    “Make sure that only one system / department owns the message” – Doesn’t fit nicely with stateless systems, which garantee scalability. Or maybe I missed something there and you’re referring to metadata.

    Interesting post.
    Best,
    J.

  • http://www.neovolve.com Rory Primrose

    Hi Dru,

    I’ve always become stuck on #4. If a document doesn’t contain a primary key or equivalent ID concept then how can you identify it when it is passed around?

    I don’t have an issue with primary keys on the documents themselves so much as foreign keys on documents, especially when the related documents are returned in another message.

    If a document from message A needs to make a reference to a document returned in message B, how can this be done without these primary/foreign key identifies?

  • http://awkwardcoder.blogspot.com/ AwkwardCoder

    ‘Make sure that only one system / department owns the message.’

    definitely have an issue with this idea, departments should never own messages as they will corrupt the intent for their own gain – marketing’s definition of a product is different from the analysis team, engineering team etc.

    How you resolve these kinds of issue is more likely to determine whether your messaging architecture succeeds or fails…