Click here to Skip to main content
Click here to Skip to main content

Application Core Messaging

, 18 Oct 2006
Rate this:
Please Sign up or sign in to vote.
This article explains how you can use messaging to solve dependency and crosscutting problems

Introduction

Application Core Messaging is a technique I developed to disconnect components inside applications, by applying messaging. The idea is that components communicate with each other through the messagebroker. Components that generate events post messages in the messagebroker. Components that need events subscribe to a messagebox on the messagebroker and get notified when a message has been delivered to their messagebox.

Background

During the middleware project at school, I noticed that the principles are really simple when it comes to messaging in a message oriented middleware program. Messages get delivered to topics and queues on a messagebroker, which notifies subscribers that a new message has been arrived. The subscribers pick up the messages and process them. This was the first time I ever thought about this and I wasn't thinking about applying it in a desktop application, because the projects I did then were much bigger and of a different nature.

Yesterday, we had a discussion about AOP (Aspect Oriented Programming) and Marc Clifton noticed right away that most of the problems AOP solves, could be solved using other techniques like messaging. I will explain the how and why later on, but this idea let me back to my middleware project and the notes I've taken back then.

So to make a long story short, I made a prototype to test the theory Marc had and he’s right: it can be done and it really works well.

Why Use Messaging

Most of us will think: Why would I use messaging in a desktop application. I can live without it, because I can just call methods on the other components. This is exactly the problem that is bothering developers for a long time. Applications get more and more objects with links between them and it all gets tangled up in one big pile of wires and objects. Replacing components is a really hard job, since there’s links between that component and the others everywhere. Also logging, tracing, enforcing contracts, etc. gets real hard to do.

The solution to the first problem is as obvious as it is with building middleware applications. Untangle the lines by linking them to a central messagebroker, which routes all communication between the components. Replacing a component is then as simple as writing a new one, throwing out the old component and linking the new component to the messagebroker. If it processes the delivered messages in the right way and sends the right messages, all is fine.

The second problem is a lot harder to solve. You could of course use AOP to solve this, you find a tool to create and weave in an aspect, write the aspect and weave it into the application. There is however a downside to this. Debugging isn't a trivial thing anymore, as far as it ever was. There’s weird code in the methods you are debugging, that doesn't belong to you but is weaved in by the AOP compiler. Your program is probably a mess by now and you won't find your problem easy. This is one of the biggest downsides to using AOP in applications. The second problem is the tooling, there are no good tools at the moment that make it possible to use AOP in its full strength. There are tools for Java like Aspect/J, but there are no good tools for .NET which I use for my applications. Compose* is only available for .NET 1.1 and I use .NET 2.0, so that isn't really an option, besides the tool isn't stable enough to be used in production.

Another solution to solve the problems with tracing, etc. is to use message filters on the messagebroker. Each message passes through the filter and the filter decides what to do with the message, a filter can decide to reject a message or add additional properties to it. As long as you can apply multiple filters on the various messageboxes, you are all set for a bright future using Application Core Messaging.

Functional Design

The design of Application Core Messaging is really simple. There’s an image below that shows what the functional design of Application Core Messaging is.

Functional design

All components deliver their message to the broker, which routes the message through a set of filters into the desired messagebox. As soon as the message gets delivered in the messagebox the subscribing components get a signal that a message has been delivered. The component can then process the message.

It is important to note the difference between the topic and the queue here. The queue keeps track of the messages posted and delivers the message only to one component. The topic however doesn't keep track of messages delivered, but has the capability to deliver the messages to multiple components at once.

Depending on what you want, you either choose the queue or the topic. If you want multiple components to observe another, you can use the topic to achieve this behavior. If you want a component to only communicate for example to print a document, you choose the queue.

Implementation Details

My implementation is a very basic one. I use a single threaded messagebroker that doesn't need its own thread to deliver messages. Instead the components that communicate with the broker provide some kind of heartbeat to the messagebroker, so that it can notify subscribers when a message has been delivered. This way you keep the amount of threads low in the application, which leaves more room for other components to create new threads.

What Can Be Sent

At this point, you can pass everything that extends the message type as a message into a messagebox on the broker. You can choose to either deliver it to a topic or a queue, depending on what you want to do. Creating a messagebox is easy, call CreateTopic or CreateQueue, provide a name for the messagebox and you're done.

Creating a custom message is simple:

public class StringMessage: Message
{
    private string messageText;

    public StringMessage(string messageText)
    {
        this.messageText = messageText;
    }

    public string MessageText
    {
        get { return messageText; }
        set { messageText = value; }
    }
}

Messagefilters

Applying messagefilters can be done by subscribing to the MessageDelivering event on a messagebox. In the eventhandler, you can choose to either cancel the message, let it be delivered or change properties of the message.

Program.Broker.MessageBoxes["QueuedMessages"].MessagePosting += 
                new EventHandler<CancelMessageEventArgs>(Form1_MessagePosting);
                
void Form1_MessagePosting(object sender, CancelMessageEventArgs e)
{
 e.Cancel = true;
}

Processing the Messages

One important thing to note is that because queues keep track of the messages delivered, you have to remove the processed message from the queue.This must be done due to the way in which the topics and queues were implemented. Removing a message for processing is done with the following code:

Message msg = (Program.Broker[e.Destination] as 
                MessageQueue).GetMessage();

Incomplete and Missing Features

There are still a few things that aren't optimal or are simply missing from the implementation. Here’s a short list:

  • Better implementation of the messagefilters
    While I choose for the implementation as it is currently, it isn't a very optimal one. Instead of implementing the MessageDelivering event by hand, it would be better to have a MessageFilter type that you can add to a list of filters on a messagebox. This way, the filters can be reused and are easier to use.
  • Standard messagefilters
    There are a couple of standard messagefilters that I want to implement in the future, like Rule Validation Filters, Authorization Filters and Log Filters.
  • Optimization of the topic messagebox
    At this point the topic delivers all messages one after another, this can be optimized by using delegates to deliver messages asynchronously to the subscribed components. This way, you can achieve parallel behavior that you may expect when using topics.
  • Standard adapter components
    Webservices can be adapted into your application by generating a proxy for it, but I think it would be even better to have webservice adapter component that you can attach to the messagebroker and communicate with the webservice by using messages. The same can of course be done by creating a remoting component.

Conclusion and Further Reading

Application Core Messaging is a method to decouple components in your application by applying messaging. This then leads to even more possibilities, like filtering messages much like you would do in AOP. Although messaging techniques aren't widely used in desktop application, it holds a great potential to solve the problems explained earlier in this article.

Marc Clifton did a great series on application automation and has designed a pretty good system that can enhance your application architecture. It goes even further in decoupling components.

History

  • 19th October, 2006: Initial post

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

WillemM
Web Developer
Netherlands Netherlands
WillemM is a 25 year old software developer working for Info Support. He loves new technology and spends most of his free time finding new ways to do things with his computer.
 
When not working on computers you can find him outside with his camera taking pictures.

Comments and Discussions

 
GeneralMessageTopic vs MessageQueue Pinmembersailu_tp13-Nov-06 10:30 
GeneralRe: MessageTopic vs MessageQueue PinmemberWillemM13-Nov-06 20:49 
GeneralLooks good but. Pinmembersailu_tp13-Nov-06 10:15 
GeneralRe: Looks good but. PinmemberWillemM13-Nov-06 20:52 
GeneralRe: Looks good but. Pinmembersailu_tp15-Nov-06 6:58 
GeneralNice article Pinmemberpjd100131-Oct-06 16:54 
GeneralRe: Nice article PinmemberWillemM31-Oct-06 20:12 
JokeRe: Nice article Pinmemberpjd10012-Nov-06 14:39 
GeneralRe: Nice article PinmemberWillemM2-Nov-06 20:52 
GeneralI suggest that you look into the Smart Client application block Pinmembertetsujinoni24-Oct-06 2:26 
Generalexisting frameworks PinmemberHerre Kuijpers22-Oct-06 22:56 
GeneralRe: existing frameworks PinmemberWillemM22-Oct-06 23:07 
GeneralThe project has fundamental errors PinmemberDewey20-Oct-06 20:09 
GeneralRe: The project has fundamental errors PinmemberWillemM20-Oct-06 21:54 
GeneralRe: The project has fundamental errors PinmemberDewey21-Oct-06 9:50 
GeneralRe: The project has fundamental errors PinmemberWillemM22-Oct-06 5:42 
GeneralRe: The project has fundamental errors Pinmembertingku08132-Jul-09 19:46 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140709.1 | Last Updated 19 Oct 2006
Article Copyright 2006 by WillemM
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid