Differences between MQ and Webservice and MQWebservice

Differences between MQ and Webservice and MQWebservice

Webservice and MQ (MessageQueue) are both common methods for cross-platform communication. What are the differences between them?

I personally think the most essential difference is that Webservice is almost real-time communication, while MQ is usually delayed communication. What does it mean? Because webservice is actually a method called by a local server program on a remote server, it is an interaction between the two. When a request is sent, it must wait for the requested server to respond before the other end can take some action, that is to say, if the service server you requested is closed or interrupted, you will certainly not be able to get a response, and your request will be lost. MQ, however, is equivalent to a Message Queue component. All requests sent by the middleware must be sent to this Message Queue Component first, and then the Message Queue component sends requests to another server, after a response is returned to the original request program, because the MessageQueue component stores the message persistently locally, the request message will not be lost even if it suddenly crashes. For example, for some complicated report generation requests, it may be quite complicated to generate a report. It may take a few minutes for us to do so. At this time, we will use MQ, send the request report to MQ as required. After the receiving program completes processing and returns the report, I will receive a notification, which is better. Common MQ components include MSMQ, Apache ActiveMQ, and some open source mq. Paste an example:

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 [1].

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 consumer Er (consumer) program gets the message from the queue and processes it. the sender and aggreger programs don â €™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 ).

 

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 caller may be offline while the sender is sending messages. in this situation, the caller 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 caller es them. A Message Broker can route messages into SS 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 ).

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 don â €™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, it â €™S original name (and internal project name) is MDS and the applications have classification classes with the prefix MDS.

Why a New 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.

Application-1 and Application-2 are executable applications (or Windows services) and Sender Service is a Windows service. application-1 performs some tasks, produces data, and Calla 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 CALS). 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 processing 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.

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.