In distributed applications sometimes two applications needs to communicate in an asynchronous manner that is one application shoots a message for another, another application which may not be available at the same time, but could get that message at a later time. This functionality can be achieved by storing the message sent by first application into a central database and then when later application becomes available to process this message, it could receive the message from the database. Let’s look a bit deeper. It is OK to use a central database when you need only two applications to communicate, but how if you have a thousand applications to send messages and only one application to process them?
For example, you want to accept data from multiple users and you have to do some operations on that data, after that you require writing data to some files. Then in this situation you don’t need the data to be stored in database, you just want to do some operations on that data and copy that to some files. Microsoft Message Queue (MSMQ) fills this need by providing a central location or pool where you can place or remove data. An application can place data in the queue and continue with its business while another application grabs the data when it is ready.
What is Message Queuing?
Message queuing is a communication tool that allows applications to reliably interconnect in a distributed environment where one of the applications may or may not be available at any given time. The queue acts as a holding container for messages as they are sent between applications. The applications send messages to and read messages from queues to communicate back and forth. An application writes a message to a queue, which will then be received and processed by another application at some point determined by the receiving application. This type of communication is designed for asynchronous use where the applications involved are not waiting for an immediate response from the other end. The key feature of message queues like MSMQ is the fact that it decouples sender and recipient applications so they do not need to run at the same time. This means that an application can place data in the queue and not deal with whether the item on the queue is delivered to the recipient.
MSMQ is a part of the Windows Server operating system. Originally MSMQ came with a native, COM-based programming interface. But Microsoft has added a.NET wrapper on top of it which makes the development of MSMQ-based systems quite easier.
a. Storing insignificant information in the message queue while your database server is busy with other real time processing.
b. Process user input which is given by the user after getting supporting information from other source or applications that are not active or ready at this stage.
c. Because of database server outage, you might require keeping user input in the message queue and processing it as and when the database comes online.
d. Exchanging data with a mainframe system like SAP. Personally, the real time communication with SAP is often a problem. In such cases, the SAP system uses message queue for storing and forwarding information where real time communication is not possible at that time.
So, in MSMQ there are two concepts – the Message and the Message-Queue
• Message: The actual message or data to be shared among applications.
• Message-Queue: The MSMQ message queue that will receive/send messages.
Types of Message Queues
• Outgoing: Used to temporarily store messages before they are sent to its destination.
• Public: Published in the Active Directory. Applications on different servers throughout the network can find and use public queues via Active Directory.
• Private: These queues are local to a server and are not available to other machines (thus, these queues are not published in Active Directory).
• System: Contains journal messages (sent from the system), dead messages, and transactional dead-letter messages. Dead messages are undeliverable.
continued..
No comments:
Post a Comment