最近在使用IBM Websphere Message Queue,與WebService相比，同樣是跨平台的通信方式，那麼各種有什麼優勢呢？
Message Queue屬于比較重量級的應用，在規範化的企業流程中用的比較多。如果企業有很多部門，部門都有自己的系統，那麼不同的系統之間的內建通信，Message Queue是很好的選擇。MQ一般都做為企業級IT應用的中間件存在，有很多企業是作為标準IT基礎結構存在的。在市面上常見的MQ中間件有IBM websphere message queue service，Oracle
Advanced Queuing，Microsoft Message Queue(MSMQ)，Apache ActiveMQ等
如果使用WebService的話，就要寫很多的WebService的代碼，去建立這些WebServcie，然後暴露出這些接口，互相之間調用，很費事。但是如果使用Message Queue的話，隻要把這個中間件的伺服器搭建起來，隻要在需要的時候加入不同的Queue Manager就可以了，然後就可以通路了，就可以作為不同系統之間的橋梁了。
長耗時的報表，這個在程式中經常遇見，處理海量資料時，可能生成一個報表需要5分中或是更長的時間，客戶不能線上實時等待，報表處理比較耗費資源，不能同時處理很多請求，甚至同時隻允許處理一個，這時就可以使用MQ。用戶端将報表請求和一些必要的報表條件放到Queue中，報表由另一個服務一個一個的處理，處理好後再給使用者發一個消息（MSN消息，或mail等）使用者再在浏覽器或其他報表浏覽器中檢視報表。
線上商店，在客戶下訂單的過程後，系統隻需做減庫存、記錄收貨人資訊和必要的日志，其他的必須配送處理、交易統計等其他處理可以不同時完成，這時就可以将後續處理消息放入Queue中，讓另一台（組）伺服器去處理，這樣可以加快下訂單的過程，提高客戶的體驗；
WebService通常是實時性要求較高，Client端向Server端送出請求後，這是一個短連接配接，一個Http請求，這個請求發出後，Client端就會一直等到擷取到這個結果。但是使用MQ的話，因為有了中間的這一塊區域，當請求發出後，Client端可以繼續去幹别的事情。等到一段時間以後再去中間件的存儲區域上檢視一下有結果了麼，有了結果就取出來，沒有的話就再等會再看。
MessageQueue在于容錯處理保持資料一緻性上有很大的優勢。下邊的很好的說明了這一點。
Introduction
In this article, I will introduce a new and independent Open Source Message Queue system that is entirely built in C# and .NET framework 3.5. DotNetMQ is
a message broker that has several features including guaranteed delivering, routing, load balancing, server graphs... so on. I will start by explaining messaging concepts and the need for message brokers. Then I will examine what DotNetMQ is and how to use
it.
What Is Messaging?
Messaging is a way of asynchronous communication of applications running on same or different
machines with reliable delivery. Programs communicate by sending packets of data called messages to each other [].
A message may be a string, a byte array, an object... etc. Typically, a sender (producer) program creates a message and pushes it to a message queue and a receiver
(consumer) program gets the message from the queue and processes it. The sender and receiver programs dona€?t have to be running at the same time, since messaging is an asynchronous process. This is called loosely
coupled communication.
On the other hand, a Web Service method call (Remote Method Invocation) is a type of tightly coupled andsynchronous communication (both applications
have to be running and available during the whole communication; if the Web Service is offline or an error occurs during the method call, the client application gets an exception).
Figure - 1: Simplest messaging of two applications.
In the figure above, two applications communicate over a message queue in a loosely coupled manner. If the receiver consumes messages slower than the sender produces it, the message count on the queue will increase. Also, the receiver may be offline while the
sender is sending messages. In this situation, the receiver gets the messages from the queue when it becomes online (when it starts and joins the queue).
Message Queues are typically provided by Message Brokers. A Message Broker is a standalone application (service) that other applications connect
to and send/receive messages. A Message Broker is responsible to store messages until a receiver receives them. A Message Broker can route messages across machines to deliver a message to the destination application and can try delivering the message until
the receiver correctly handles it. A Message Broker is sometimes called a Message Oriented Middleware (MOM) or simply Message
Queue (MQ).
What is DotNetMQ?
DotNetMQ is an open source Message Broker that has several features:
Persistent or non-persistent messaging.
Guaranteed delivery of persistent messages even in a system crash.
Automatic and manual routing of messages in a custom machine
graph.
Supports multiple databases (MS SQL Server, MySQL, SQLite,
and memory-based storage for now).
Supports dona€?t store, direct send style messaging.
Supports Request/Reply style messaging.
Easy to use client library to communicate with the DotNetMQ Message Broker.
Built-in framework to easily construct RMI services upon message queues.
Supports delivering messages to ASP.NET Web Services.
GUI-based management and monitoring tool.
Easy to install, manage, and use.
Written entirely in C# (using .NET Framework 3.5).
I preferred to name DotNetMQ as MDS (Message Delivery System) when first creating it. Because it is designed not just to be a message queue, but also as a system that delivers messages directly to applications and an environment that provides a framework to
build application services. I called it DotNetMQ since it is entirely developed using .NET and the DotNetMQ name is more memorable. So, ita€?s original name (and internal project name) is MDS and the
applications have many classes with the prefix MDS.
Why a New Message Broker?
The Need for a Message Broker
First, I will demonstrate a simple situation where a message broker is needed.
In my experiences in business life, I‘ve observed really bad and uncommon asynchronous enterprise application integration solutions. Usually there is an application that runs on a server and performs some tasks and produces data, and then sends the result data
to another application on another server. The second application performs other tasks on the data or evaluates the result (the servers are on the same network or connected over the internet). Also, the message data must be persistent. Even if the remote application
is not working or the network is not available, themessage must be delivered on the first chance.
Leta€?s look at the design in the figure below.
Figure - 2: A bad solution to integrate applications.
Application - 1 and Application - 2 are executable applications (or Windows services) and Sender
Service is a Windows service. Application - 1 performs some task, produces data, and calls a Remote Web Service method onServer - B to
transmit data. This Web Service inserts data into a database table. Application - 2 periodically checks the table for new incoming data rows and processes them (and deletes them from the table or marks
them as processed to not process the same data again).
If an error occurs during the Web Service call or while processing data in the Web Service, data must not be lost and must be sent later. However, Application - 1 has other tasks to do, so it can not
try to send data again and again. It simply inserts data into a database table. Another Windows service (or a thread in Application - 1, if the application always runs) checks this table periodically
and tries to send data to the Web Service until data is successfully sent.
This scenario is really reliable (messages are guaranteed to be delivered) but is not an efficient way of communicating between two applications. This solution has some very critical problems:
It takes a long time to develop (to code).
Individual coding for all message types (or remote method calls). For a new Web Service method call, you must change all the services, applications, and
database tables.
Almost same software and structures must be developed (or copied and modified) for every similar service.
Testing and maintenance of too many services/applications/databases after coding.
Some applications and services periodically check the database even if there is no new message (if the database is not well indexed and optimized, this may consume serious system resources).
Message Brokers do all this job and takes all the responsibility to deliver messages to the remote application in the most efficient way. The same application integration using DotNetMQ is shown in the figure below.
Figure - 3: Simple messaging by using DotNetMQ.
DotNetMQ is a standalone Windows service that runs on both Server - A and Server - B. Thus, you just need to write code to communicate with DotNetMQ.
Using the DotNetMQ Client Library, it is very easy and fast to connect and send/receive messages to/from the DotNetMQ service. Application - 1 prepares the message, sets the destination, and passes the
message to the DotNetMQ Broker. DotNetMQ brokers will deliver the message toApplication - 2 in the most efficient and fastest way.