Do It Yourself E-mail

At first sight, MSMQ has much in common with an e-mail system, such as – say – Microsoft Exchange Server. For instance, there’s an obvious correspondence between message queues and mailboxes. However, the crucial difference is that MSMQ is about application to application communication, and e-mail is about person to person communication. E-mail systems are optimized towards passing human-readable information between one or more humans. Messaging systems like MSMQ are pitched at a lower level, and are much more generic in scope. MSMQ in fact has API functions built in for interconnecting with e-mail systems, using a subset of the standard MIME format.

Having said that, there’s no reason why you can’t build an e-mail system on top of MSMQ …

Before we start, however, we have a choice between two APIs:

The first is a standard C-type API, containing around forty functions with names that start off with the letters

MQ

(of which roughly half are for e-mail interconnectivity)

The second one consists of a set of twenty-odd COM objects (of which – again – roughly half are for e-mail interconnectivity)

We won’t be looking at e-mail interconnectivity here, but if you’re interested all the API functions and objects are described in the MSMQ SDK help.

The second API was actually developed expressly for use by VB developers, and to be frank, it doesn’t quite have the flexibility and depth of coverage of the C library. However, having tried both, I have to say that to seasoned COM heads such as ourselves, the COM one is actually nicer to use.

In case you’re having trouble making up your mind, I’ve written this example in Visual C++ using MFC and both APIs. The

SimpleMail

project is the COM version, whilst the NocomMail
project is, believe it or not, the no-COM version. Also, I think that the COM version is a pretty good demonstration of the power that the discipline of having to expose a good component interface gives to the API developer. Both of these projects are available to download from the Wrox Press website at http://www.wrox.com.

Actually, now that we’re a few pages into the chapter, you might be forgiven for wondering what MSMQ really has to do with DCOM. You might even be thinking that the only reason that I’ve mentioned the COM version of the MSMQ API in preference to the C version is just to work COM into it somehow. Nothing could be further from the truth. As we’ll see later on in this chapter, there are two crucial areas where MSMQ is beginning to work in tandem with other COM technologies to add enormous value. The first of these is its role as a resource manager (which we’ll look at later on in the chapter), and the second is as an alternative high-level transport for asynchronous “one-way” methods in DCOM (which we’ll look at right at the end of the chapter).

Of course, we could do this first example without using COM at all, but — well, you can never get enough practice, can you? I’ll go through the COM version of the project in some detail, and then I’ll make some brief comparison with the no-COM version.

We’ll start off by creating our e-mail message queues. We need one for each machine that we’re sending messages to. For convenience, we’ll give each of our queues the local name of smail. Each queue resides on one machine, and it can be referred to in a number of ways:

Its pathname, for example dipsy\smail
A user-friendly label, for example “Simplemail for dipsy”

(And if you really insist) a UUID,

58A4CE1C-A937-11D1-BA12-004095D103A0

(the UUID is automatically generated by MSMQ when you create the queue)

A format name, constructed out of the queue’s pathname, or its UUID; for instance

PUBLIC=<UUID>

or DIRECT=OS:dipsy\MyQueue

The MSMQ ‘C’ API only uses format names, although the MSMQ component set can use any of these.

Pathnames and UUIDs are guaranteed to be unique, but labels aren’t. This means that you can’t use queue labels for operations like sending mail, because MSMQ can’t necessarily tell unambiguously which queue you are talking about.

As well as this, you can assign a type to each queue, so that you can search for queues of a particular type.

As well as our previously created smail queue, we’ll create another one on each machine, called admin. This is going to be our queue for administration messages. This is a really neat feature. We can actually tell MSMQ to send us a message when something important has happened, like the message reaching the target queue, or if something bad has happened.

So that we can compare both the COM and no-COM versions, we’ll build our mailer as a dialog-based MFC application. This is what our main dialog looks like:

In this application, we’re going to enter messages by specifying a title, some text, and two queues, one to send the message to and one to which administration messages are sent back. We’re also going to set some options whenever we send a message. Take a look at these. We can:

Specify whether or not the message is to be dumped into a dead letter queue if it fails to get through for whatever reason;
Specify whether or not the message is to be copied to our local machine’s journal file; (it is also possible to attach a separate journal queue to each queue, although this isn’t demonstrated here)
Override the standard default timeouts (in seconds) for reaching the destination queue and being read. Timeouts are specified in seconds
Specify what kind of administration messages MSMQ is going to send us. For example, we can request that MSMQ gives us an acknowledgment (ACK) when a message is received (i.e. read) or a negative acknowledgement (NAK) if it isn’t received, or perhaps a NAK only if the message fails to reach the destination queue.

We’re also going to look out for messages coming back. We could, if we wanted, request asynchronous real-time notification. However, quite apart from the complications involved in getting MFC to accept events from COM objects, I think we’re better off keeping it nice and simple at this stage. We’ll see asynchronous notification in operation later on, anyway. For now, we’ll content ourselves with polling the message queue whenever the user hits the Refresh button.