1. It needed to integrate seamlessly with our existing Cairngorm Extensions
2. It needed to allow for application level messages
3. It needed to allow for client specific messages

The trick was to create an abstract class that multiple departments could use, because internally we use ColdFusion, Java and .NET to produce and consume messages. In our department, we use ColdFusion, so I had to create a concrete implementation of the abstract class called ColdFusionMessagingDelegate which handles the construction and publication of an AsyncMessage to a ColdFusion Event Gateway.

Other departments’ implementation of this process will be different, so I couldn’t force an implementation in the abstract class.

Additionally, in the application I was using for testing, I wanted to have two categories of messages:

1. Messages intended to be produced and consumed by individual clients
2. Messages intended to be consumed by any client

To that end, I created another abstract class at the application level that simply passed along specific a Flex Producer and Consumer for each category. I then created two concrete classes. One specified the Producer and Consumer for the application, and the other specified the Producer and Consumer for that individual client.

Here’s a diagram showing the architecture.

Generic Messaging Architecture

So far, it’s working great in the development test lab, but I still need to get with my colleagues for a group code review and hopefully fine tune the code and the architecture a bit more.