MSMQ Part 1/2: Architecture and Simple Implementation Using VB
MSMQ is a messaging solution that uses the store-forward style of distributed computing to share data across networks in terms of messages. In part one of this two part series, Liviu explains the architecture of an enterprise system in relation to MSMQ. He also shows us how to implement a simple message queuing application using Visual Basic 6 and the MSMQ COM objects.
MSMQ Part 1/2: Architecture and Simple Implementation Using VB - MSMQ Architecture (Page 2 of 5 )
Imagine the typical scenario of a server pulling data from workstations and then uploading that data to a central repository such as a remote server: it all works fine, just as long as the local server can talk to the remote server. What happens though if the connection between the local server and the remote server fails? You might say "that's ok, we will store the data locally and then when the remote server comes up again we will upload that big chunk of data in one go". That could work in some cases, but what happens if you only want to process that data within a certain time interval from the moment it has arrived from the local server?
Furthermore, what if the workstations can't connect to the local server anymore? And if they can, what if we need to be notified by the remote server that the data we have submitted has either been processed successfully or failed? The list of requirements can continue to grow with more and more possible failure scenarios.
One thing becomes obvious the moment that computing networks start to be considered in terms of reliability and stability for real world use: they aren't always reliable, and furthermore, there are cases when we might need a different approach to the classical "live link" between the client and the server. MSMQ doesn't offer the all-in-one solution to these problems, but instead it offers an API for programming distributed applications using a messaging paradigm. By using MSMQ however, we can't expect our applications to be 100% fault tolerant 100% of the time, but we can expect our applications to fail a lot less than they would without the use of a messaging system.
MSMQ is part of the Microsoft DNA architecture, and it was designed with the idea of the enterprise in mind. In a normal enterprise architecture, we can have more than one "site" interconnected with other "sites". Think of a site if you would in the same way that you would think of an office: a company can have offices spread throughout the whole world. These offices are normally connected to each other to allow better communication between them; each office has its own servers (mail, web proxy, backup NT Domain Controller, etc.).
Getting back to our MSMQ architecture, an enterprise is divided into sites; each site will have at least one MQ site controller (SC), which handles the messages sent to or from that particular site. Each of these site controllers communicates to a central MQ server the primary enterprise controller (PEC). The PEC stores details about the queues created, the other servers in the enterprise, clients, queue locations etc. The SC on the other hand will only store read-only copies of the messages in the queue.
Each site will also have a message router that is responsible for routing messages between queues, networks, or sites. Message routers don't store any information (as opposed to a PEC or SC), and they only do exactly what their name says: they route messages between servers.
Sending messages using MSMQ eliminates the need for a persistent connection to a server. Let's again consider the example of a big corporation with offices worldwide. The company's headquarters are in New York, but they also have an office in Boston, one in London, and one in Paris. All of these offices have to be connected to allow each of them to communicate with each other. The typical way for employees in these offices to exchange information with each other is via email. This means that their enterprise requires a mail server. Where would this mail server be located though? Common sense tells us that it should reside at the company's headquarters in New York. That's absolutely fine, but what happens to the poor employees in Paris, Boston and London? Every time they need to send or receive emails they will have to connect to the central server.
Connecting to the central server in New York every time can raise problems in terms of cost, network delays (Boston is not that far from New York so the network trip will be quite short, but Paris and London aren't exactly close), and also the server load balance (imagine what would happen to the server if it had to put up with hundreds of employees trying to read their emails simultaneously).
Because of this, the typical approach would be to set up a mail server for each office. This mail server would talk to the central mail server or to each other mail server to route mail to and from the appropriate employees. Now, if one of the employees in London wants to send an email to an employee New York, he/she will talk to the local mail server and post their email there; in turn, the local mail server will connect to the central mail server in New York and deliver the message there. Note that the local mail server will not necessarily forward the message straight after it has received it, as by that time the network link might be down or the server at the other end might be too busy to accept the email.
Getting back to our PEC and SC, in a typical enterprise architecture the PEC is playing the role of the central mail server, while the SC and message routing servers are playing the role of the local mail servers. Of course it's not necessary to implement all of this architecture - there are cases (for example a small office) when you dont need to divide your MQ structure into sites and install message routers and SC's. The minimum set-up you need to develop MSMQ applications is a primary enterprise controller clients can then connect directly to this server and send/retrieve messages in the queues.
Shown below is a diagram of a possible MSMQ architecture as you can see, if you eliminate the external sites from the game then you will be left with the simplest scenario where you only need a PEC and the client computers:
To manage your MSMQ architecture effectively, your PEC (Windows 2000 server) includes a program called Message Queue Explorer. This program gives you an in-depth view of your enterprise set up, configured queues, site controllers and clients, etc. We wont explore the use of this program in this article, but we will make references to it as a debugging and monitoring tool for the code snippets we will look at later. To learn how to configure MSMQ on your PEC and also how to setup the Message Queue Explorer, visit Microsoft's MSMQ website.