Even when developing the most basic CRUD application, we ask ourselves a number of questions – whether we realize it or not – during the initial phases of development concerning the architecture and construction of the project.  Where will the data be persisted?  What mechanism will be used to communicate with the database?  How will data from the database be transformed into business objects?  Should separated interfaces and dependency injection be employed to maintain a clean separation of concerns between application logic and data access objects?  What UI components will be leveraged to speed development of the UI layer?  When developing message-based systems (see Message-Based Systems for Maintainable, Asynchronous Development for an introduction) it’s immensely helpful to formalize such questions about how the systems will be designed and developed.  Creating a checklist of such items to decide upon, and formalizing answers for the application context, helps to:

  • Standardize how components (applications participating in the message-based system) will communicate with the messaging middleware;
  • Provide architectural guidance throughout project development concerning how components will leverage message end-points;
  • Define the data model that will be used for sending commands and exchanging data among components;
  • Assist new developers on the team with getting up to speed with maintaining and extending the message-based system; and
  • Support consistency (and predictable maintainability) amongst the components of the system.

This post provides an addendum, if you will (I’m sure you will), to Message-Based Systems for Maintainable, Asynchronous Development for complementing the article with a checklist of questions and architectural topics that should be discussed, decided upon, and/or spiked before beginning development of your budding message-based system.  Accordingly, this does not describe a methodology for developing message-based systems, but simply a checklist of topics which should be taken into consideration before development begins.  Many of the checklist items below serve as good starting points for team discussion and for the development of architectural spikes for demonstrating implementation details.

Messaging Middleware

  • What messaging middleware solution will form the background of the message-based system?
  • How are channels addressed in the selected middleware?  (E.g., as a string or as a port number?)
  • How does the nomenclature of the middleware match up to standard elements of message-based systems and design patterns?  E.g., in Robot Operating System (ROS), a channel is called a “topic.”  Likewise, is their middleware specific nomenclature for elements such as component, publisher, subscriber, point-to-point channel, publish/subscribe channel, message, command message, request-reply message, router, message end-point, and other messaging design patterns?
  • What mechanism is available for peeking at messages going over a point-to-point channel?
  • What utilities are available for viewing active channels, publishers, and subscribers?
  • What other tools does the middleware provide for debugging and observing the messaging system?  Will custom utilities need to be developed to autment development and debugging capabilities?

Integration with Messaging Middleware

  • How will message end-points publish a messages?
  • How will message end-points subscribe to a channel for messages?
  • How will message end-points poll a channel?
  • What technique will be used to decouple the component (participating application) from the message end-point when sending a message?  E.g., dependency injection, separated interface, or other?
  • What technique will be used to decouple the component from the message end-point when receiving a message or polling a channel?  E.g., callback, separated interface, or other?
  • Should exceptions raised by the messaging middleware be wrapped in component specific exceptions for looser coupling?  If so, what will be the standard exceptions?  Additionally, how will such exceptions be logged and tracked for debugging; e.g., email alerts, logging, exception message channel?

Channels and Routing

  • What channels will be created and what data type should each channel carry?
  • Will a hierarchical naming strategy be leveraged for naming and organizing channels?  If so, what are the naming conventions for the project?
  • Has an invalid message channel been setup with a logger to capture and record invalid messages?
  • How should a predictive router be implemented, when needed?
  • How should a reactive router (e.g., a message filter) be implemented, when needed?

Message Elements

  • What data elements may the header of a message contain and how should each be specified?  E.g., return address, message expiration, timestamp, origin, format indicator, etc.
  • How should a message identifier and correlation identifier be generated and included in the header?
  • What is the messaging data model supported and/or enforced by the messaging middleware?  E.g., ROS supports http://www.ros.org/wiki/msg.
  • What canonical data model will be used to imbue message content with domain specific semantic meaning?  E.g., JAUS.
  • How will message translators and/or message mappers be leveraged for converting between each component’s domain model and the canonical data model?
  • How will a command, document, event and request-reply message be composed?

Other Topics

  • How will components maintain information that is associated with a correlation identifier?
  • Are there existing components which need to interact with the messaging middleware which cannot be modified?  If so, how will each communicate with the messaging middleware?
  • How will each component participate with the message based system; e.g., as a polling consumer, as an event-driven consumer, as strictly an event publisher, as a combination of these?
  • Should exceptions raised by a component participate in a global exception tracking and debugging mechanism?

As stated previously, this checklist is not intended to provide a methodology for developing message-based systems, but should serve as a good basis to make sure “T’s are crossed and I’s are dotted” when deciding upon the major architectural aspects and development techniques that will be leveraged throughout the development of your (team’s) message-based system.

Billy McCafferty