Author: csudhir
Posted: Thu Jun 16, 2016 1:10 pm (GMT 5.5)
Business environments are constantly changing. Applications that were written 20 years ago need to exchange data with applications written last week. The core data can be held in a database on a mainframe, but a user of a browser requires a front-end web application server to interact with that database. Messaging is an effective way to connect these systems. It hides many of the details of communication from the application developer and gives a simple interface.
Many mechanisms for communicating between applications require that both applications are available at the same time. Messaging uses an asynchronous model, which means that an application that generates messages does not have to execute at the same time as an application that consumes those messages.
Asynchrony is used in various ways. It can queue large volumes of work, and that work is then submitted once a day by a batch process. Or, work can be submitted immediately and then processed as soon as the receiving application finishes dealing with a previous request. Asynchronous processing does not imply long response times. Many applications were built and successfully execute by using messaging for real-time interactive operations.
Business transactions normally happen exactly once. Middleware needs to ensure all the systems that are involved in that transaction do their job, exactly once. There must be no loss or duplication.
Data is transferred between applications in messages. A message is a container that consists of three parts: WebSphere MQ Message Descriptor (MQMD): Identifies the message and contains additional control information. Message data: Contains the application data. The structure of the data is defined by the application programs that use it, and WebSphere MQ is largely unconcerned with its format or content. The nodes, within a WebSphere MQ message queuing infrastructure, are called queue managers. The queue manager is responsible for accepting and delivering messages.
Placing a WebSphere MQ infrastructure between the two applications allows this communication to become asynchronous. One application places information for the partner in a message on a queue, and the partner application processes this information when it is available to do so. If required, it can then send a reply message back to the originator. The applications do not need to be concerned with communication failures or recovery.
Posted: Thu Jun 16, 2016 1:10 pm (GMT 5.5)
Business environments are constantly changing. Applications that were written 20 years ago need to exchange data with applications written last week. The core data can be held in a database on a mainframe, but a user of a browser requires a front-end web application server to interact with that database. Messaging is an effective way to connect these systems. It hides many of the details of communication from the application developer and gives a simple interface.
Many mechanisms for communicating between applications require that both applications are available at the same time. Messaging uses an asynchronous model, which means that an application that generates messages does not have to execute at the same time as an application that consumes those messages.
Asynchrony is used in various ways. It can queue large volumes of work, and that work is then submitted once a day by a batch process. Or, work can be submitted immediately and then processed as soon as the receiving application finishes dealing with a previous request. Asynchronous processing does not imply long response times. Many applications were built and successfully execute by using messaging for real-time interactive operations.
Business transactions normally happen exactly once. Middleware needs to ensure all the systems that are involved in that transaction do their job, exactly once. There must be no loss or duplication.
Data is transferred between applications in messages. A message is a container that consists of three parts: WebSphere MQ Message Descriptor (MQMD): Identifies the message and contains additional control information. Message data: Contains the application data. The structure of the data is defined by the application programs that use it, and WebSphere MQ is largely unconcerned with its format or content. The nodes, within a WebSphere MQ message queuing infrastructure, are called queue managers. The queue manager is responsible for accepting and delivering messages.
Placing a WebSphere MQ infrastructure between the two applications allows this communication to become asynchronous. One application places information for the partner in a message on a queue, and the partner application processes this information when it is available to do so. If required, it can then send a reply message back to the originator. The applications do not need to be concerned with communication failures or recovery.