DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


Uses of the service

Where, then, would you use the message queuing service rather than the ordinary DCOM synchronous method invocation? Message queuing services enable the developer to build “loosely coupled” applications, so any application which needed connection independence or time independence could be built using this service.

What do we mean by this? In message queuing, a message can be placed in the queue and processed once the receiver is available—messages can be queued even when the recipient process is not present.

Similarly, recipient processes can receive messages even when the originator is not present. But if sender and receiver are both present on the network, messages can be sent and received immediately. It is this feature that makes them different from RPCs, where both processes have to be available on the network before a call can be made. In message queuing products the processes do not both have to be available.

Message services are thus extremely useful for building applications which must run over unreliable lines, or where the processes to be connected are remote from one another—separated by a WAN, for instance, or in different locations. Many existing message queuing products (like MQSeries, VCOM, and BEAmessageQ) are being used today by large organizations with many centers of operation and a large base of legacy systems they need to integrate. Typical applications have not only included end-user applications such as order entry, warehousing, stock control, and so on, but generic applications such as work-flow. Let me provide you with some examples:

Replacing paper-Message queuing middleware can replace paper-based methods of information transfer between computer systems—often with improved reliability of data transfer and reduction in time taken. One user of an MOM product, for example, uses message queuing to connect their order entry system with their warehousing and shipping systems; another uses it to connect shop floor applications with inventory and accounting systems.

Replacing batch transaction systems-Message queuing middleware is also particularly well suited to supporting applications that would otherwise be implemented as traditional batch transaction-based systems. For example, the application on one machine gradually produces transactions during the day that are batched and then transmitted for overnight processing by another machine.

A programmer would normally have to write and design these sorts of systems from scratch, but with message queuing middleware, the transactions can be transmitted over the network as and when they are created to be processed whenever there is free capacity. The messaging middleware can be used to take care of the file control, recovery, guaranteed delivery, and so on. These sorts of applications occur frequently in banks, securities companies, and supermarkets and stores (EPOS data).

Applications needing strictly ordered processing-Some applications employ an architecture where a number of client applications seek the services of one server. The server needs to process the requests for service in the strict order in which they arrived, in order to guarantee fairness to the client and also to ensure the integrity of the data. Examples of this sort of application might be an airline bookings system receiving bookings from travel agents or a car rental company receiving bookings from agents.

Message queuing middleware can be used in these circumstances because its architecture is based on messaging and queues. The queues are sequenced—normally in FIFO order, so the order of processing matches the order in which they were received. We will also be seeing that MSMQ supports message prioritization, which means that urgent messages can be given priority and processed ahead of others in the queue, adding to the flexibility of this form of approach.

What Is MSMQ?

Microsoft Message Queue Server (MSMQ), code-named Falcon, is a Message-Oriented Middleware service that supports message queuing, message prioritization, broadcast and multicast, poll/pull and notification, guaranteed delivery, deferred delivery, and time expiration-based messages. In the following chapter I will be describing what each of these terms means and the functions they provide.

It is administered using MSMQ Explorer. Administration is possible from any computer running MSMQ Enterprise Manager.

MSMQ is based on a foundation of COM and can be accessed by ActiveX components using the normal COM interface together with the additional “commands” provided in MSMQ. The API provided with MSMQ supports components which have been developed in C or C++ or Visual Basic. The MSMQIC (Internet Connector) enables the developer to use a Web page as the interface, or the developer can use MAPI and Exchange as the interface.

A bit of background

Falcon was developed by Microsoft in Israel by the same organization that “owns” NT 5 and the Directory. All these people were led by Moshe Dunie, a VP of engineering based in Redmond. Work started on Falcon towards the end of 1995. It was released in December 1997.

There were two betas of Falcon. Beta 1 of Falcon supported all the features described in this chapter, except encryption and authentication, which were in Beta 2. It ran on Windows NT workstation and server. Beta testing of Falcon 1 began in August 1996, when the beta was shipped to selected customers and developers. The first copies of Falcon were provided to developers on a CD at the Microsoft Developer’s conference in Los Angeles towards the end of 1996.

Beta 2 not only supported security but also provided support for transactions (queues were capable of being placed under transaction control), as well as “exactly once delivery and end-to-end confirmation” using DTC. Falcon was released towards the middle to end of 1997 as part of NT, when it was renamed MSMQ.

Platforms

MSMQ runs on Windows NT and 95. Clients can be Windows NT Workstation, Windows NT Server, or Windows 95. The servers must run on Windows NT Server. Level 8 Systems are providing gateways from clients running on other machines to the MSMQ services on Windows.

The diagram below shows the platforms supported and the way the gateways will work. The platforms shown in the diagram are the main platforms to be supported initially; other platforms (OS/2, OpenVMS) are planned.


Figure 14.4  MSMQ platform support

Main concepts and modules

MSMQ consists of a set of DLLs and EXEs called the MSMQServices, which, along with the MSMQ Device Drivers, provide the core functionality and run on all machines whether these are acting as clients or servers.


Previous Table of Contents Next