Business scenarios

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Business scenarios

The following scenarios show how different business situations could benefit from using Message Queuing. They also serve as representative examples of the different options available when you use Message Queuing.

Because the differences between using Message Queuing servers and clients affect implementation details, not actual business scenarios, the scenarios have been kept simple. It is recommended that application developers see the Message Queuing SDK for representative samples of Message Queuing applications.

Floor automation scenario

You can use Message Queuing to control the automated manufacturing of any product that is produced by a numerically controlled industrial machine that is, in turn, controlled through a computer. In the example in the accompanying figure, Message Queuing is used to collect work orders and manage the information flow for production.

The following Message Queuing features are critical to the success of floor automation:

• Guaranteed message delivery. Ensures that each message is delivered and helps ensure a reliable messaging system.

• Message prioritization. Efficiently routes messages. For example, although quality assurance (QA) messages need to be delivered eventually, they should not obstruct the efficient delivery of time-critical messages.

• Connectionless messaging. Enables all computers and machines to interact as a single system.

• Multiple-platform support. Integrates personal computers and legacy systems. For example, an accounting package can reside on an IBM mainframe MVS system and can communicate with Message Queuing applications residing on personal computers using Microsoft MSMQ-MQSeries Bridge. For more information, see Foreign computers and sites.

• Performance. Because messages can be delivered quickly, they can control real-time production processes, such as cooking temperature.

• Asynchronous delivery. Makes it possible for faster devices to continue processing without having to wait for slower devices to respond.

Ticket sales scenario

The accompanying figure shows how multiple clients can access a ticket sales Web server using the Internet. Web clients view HTML pages that show ticket availability, pricing, and seating diagrams.

A business selling tickets to events can use the following Message Queuing features to improve its system:

• Internet connection. Accepts orders over the Internet by using a Message Queuing application and COM components in conjunction with Active Server Pages (ASP) and Internet Information Services (IIS). This is done through Web forms, which provide security and multiple-platform support.

• Connectionless messaging. Account updating and ticket shipping, performed asynchronously.

• Multiple-platform support. Integrates personal computers and legacy systems. For example, the ticket sales server might be running on a UNIX computer. For more information, see Foreign computers and sites.

Publish-and-subscribe scenario

Message Queuing can be used to simplify the development of typical publish-and-subscribe programs, such as news wire services and financial data subscription services. Although a server program must continuously send updated data of a specified type to the client, the server does not have to resend the data if the client is offline or unavailable.

The accompanying figure shows a publish-and-subscribe scenario that keeps a mobile sales staff current on the status of available goods. A Message Queuing application can also be used to take orders, and the two systems can be integrated. However, to simplify the details of the example, this publish-and-subscribe scenario covers only the dissemination of information.

In this figure, mobile clients retrieve data in the field. Regional servers retrieve data from the main server only for the types of information to which the clients subscribe. Each client then receives only information it subscribes to receive. This reduces both intersite communication and mobile communication costs.

In this scenario, the regional servers and the data center are located in different sites. Messages are routed between the data center and the sites along routing links in which the main server in the data center and the regional servers are configured to be site gates.

The following Message Queuing features are critical to the success of traditional publish-and-subscribe programs:

• Connectionless messaging and message prioritization. Places the burden of message delivery on Message Queuing. You do not have to deal with information that expires (which, therefore, is no longer useful) or with information that cannot be delivered in a timely fashion.

• Security. Ensures that the information is delivered to the correct client, and ensures that services are not used without payment.

Banking scenario

Financial transactions require both security and transaction-based programming. Automated teller machine (ATM) transactions also require connectionless messaging. In the accompanying figure, each ATM has its own local database. Even if the local, regional, or headquarters database is temporarily offline, the ATM can still process transactions.

In this scenario, the regional data centers, each of which has direct connections to multiple local data centers that communicate directly with several ATMs, are located in different sites. Messages are routed between the headquarters data center and the sites along routing links, in which the main server in the headquarters data center and the servers in the regional data centers are configured to be site gates.

This banking scenario uses these Message Queuing features:

• Connectionless messaging. For communication between ATMs and regional centers.

• Transactional messaging. For sending messages that occur synchronously with the updating of the financial databases. Messages are delivered only once.

• Security. For ensuring the integrity of the system. Would-be thieves cannot impersonate an ATM, and transactions cannot be monitored by persons attempting to steal account numbers and personal identification numbers.

Stock brokerage scenario

In the example shown here, customers communicate by telephone with traders who make trade requests on their behalf. The trade server performs the following tasks in the following order:

1. Queries the account server to verify that the transaction can be completed.

2. Verifies the transaction with the risk-management server.

3. Places the trade request with the stock exchange server.

The stock exchange server makes the stock transaction and then asynchronously updates the customer account and risk-management server.

This stock transaction scenario uses these Message Queuing features:

• Security. For message authentication, encryption, and access auditing to ensure a secure environment.

• Multiple-platform support. Integrates personal computers and legacy systems. For more information, see Foreign computers and sites.

• Transactions (exactly once delivery). For guaranteed message delivery, ensuring accurate accounting.

• Connectionless messaging. For updating accounts and making risk assessments asynchronously.