Message Queue Part I - Using Message Queue for Connectionless Programming

Introduction

This artifact talks about the message queuing architecture while using Microsoft Message Queuing (MSMQ) system as an example. Message queues concept adds value to any distributed system when it deals with any disconnected environment. Presumably, an application server and a database server where there are no real time connections are applicable. We can use message queues as the basis of a fail safe mechanism whenever the regular database access fails. For example, a system which doesn't require any real time operation and only to store or accept customer input which can be processed offline.

Connectionless & Connection Programming

Connectionless programming involves using a queue to hold user input to another application or server. Here, we may not have a permanent connection to the application or server. Instead you log your input in a queue and the other application or server then takes it from the queue, processes it, and sometimes it may put the result back to the same queue or to a different queue. Unlike UDP, here there is no chance of message or data loss once you log it into queues.

The Connection oriented is different from the aforementioned and talks about any standard database system (DBMS, RDBMS, OODBMS and ORDBMS) available these days. Presumably, I don't think that there should be an explanation required for connection oriented programming. Unlike TCP/IP, there is no chance of data packet loss and it will bring the data packet to the required destination.

In short, message queue is purely connectionless and gives an assurance that it won't lose any data which is in the queue.

When to Use Message Queue?

1. Storing insignificant information in the message queue while your database server is busy with other real time processing.
2. Process user input which is given by the user after getting supporting information from other source or applications that are not active or ready at this stage.
3. Because of database server outage, you might require keeping user input in the message queue and processing it as and when the database comes online.
4. Exchanging data with a mainframe system like SAP. Personally, the real time communication with SAP is often a problem. In such cases, the SAP system uses message queue for storing and forwarding information where real time communication is not possible at that time.

In short, essentially application infrastructure and business requirements determine whether you should use a message queue or not. Personally, I would suggest that it’s a good idea to work with a tool for a while so that you can get to the solution in which you should use it.

Why Use Message Queue and Not A Database Table?

A message queue can be good in many situations, but what makes it different from a database table? When you call a DBMS or RDBMS, it is normally done synchronously, but with a message queue it is done asynchronously. This means it’s generally faster to access a message queue than to access a database table.

With synchronous access, client applications have to wait for the server process completion or respond. But in asynchronous access, the client will send a request and will continue some other process. The server will get back to the client after completion or process or request.

Working Principle Of Message Queue

FIFO (First In First Out) is the principle applied to how the processes are placed in the message queue, but priority take precedence over the arrival time of message. And the exception is that it’s possible to place a message on the top of the message queue or any other precedence even if other messages are already in the queue. Like you collect theater tickets using your girl friends if they have a separate queue or precedence over guys.

Where I Will Get This Message Queue?

Microsoft Message Queue (MSMQ) Server is the name Microsoft gave version 1.0 of its message queuing technology. It was originally included with the Enterprise Edition of Windows NT 4.0. But message queuing technology has been merged into the OS, as is the case with Windows 2000, Windows XP and the upcoming Windows.NET.

Different Types Of Message Queues

Private, Public and System Queues

There are three types of message queues in the Message Queuing Service. But we can access only the first two and I don't have much idea about the third System Queue. So I will not be sharing any thoughts on system queue. System Queues are generally used by operating systems for internal messaging.

Private queue is not published in the message queue information service (MSIQ) database. But public queues are published in the message queue information service database.

Private queues can only be created on local machines but public message queues must be registered with Directory Service.

Private queues can be created and deleted offline. We don't want to connect with active directory. Public queues can't be deleted or create without connecting to active directory.

Private queues can't be located by other message queuing applications unless they are provided the full path of the message queue. Public queues can be located by other message queuing applications through Message Queue Information Service database.

Installing Message Queue

By default, the operating system will not install a message queue service on your machine unless you explicitly specify. For the explicit installation, go to the Add/Remove Windows component in Add/Remove programs which is located in the control panel. Choose Message Queuing and install. For more information, you can refer to the Windows NT, 2000 or XP documentation for installing message queues. In the next part, I will surely include an extensive description on how you can programmatically configure, access, create message queues and various other operations.

History

• 24^th May, 2004: Initial post
• 17^th July, 2008: Article updated