Message queuing Message queuing is a middleware technology that greatly simplifies communication between the

nodes of a system and between the nodes that connect systems together. It allows services to communicate in a flexible way that does not require detailed knowledge of a target service or the current availability of that service Message: Piece of Information or Request is considered as a message. The message can contain simple character data, numeric data, complex binary data, a request for information, a command, or a mixture of all of these. Any target nodes that receive a message must understand the format of that message. The messaging infrastructure that connects those nodes does not require this same understanding. The infrastructure must only ensure that the integrity of the information contained in a message is maintained and that the message is correctly delivered to its destination

Queues
A queue is a container of messages. New messages are placed at the end of the queue, and messages are usually retrieved from the front of the queue Message Retrieval: Messages can be i) Retrieved using identifiers associated with those messages. ii) Given priorities so that high priority messages are retrieved before lower priority messages iii) Logically grouped so that one message is dependent on another message

Asynchronous communication: The producer can send a message without knowing whether the
consumer of that message is currently available. Synchronous communication: The producer must wait for the consumer to become available and complete processing on the message before being able to continue.

Batch processing: Instead of processing each message as it arrives a service might wait until a certain threshold of messages has arrived on a particular queue and process them in one batch, or perform processing of all messages that have arrived during a given time interval. Processing is performed at times when other related systems and services are quiet. Buffers between intermediate nodes in a system: A queue is placed as a buffer between each node in the system, so that messages can wait at any point in the system until a node or network link becomes available and then automatically flow through to the next node.

Point-to-point messaging
A message arrives once, and once only, at a single and correct destination. It can be split into the following two general categories: Send and forget messaging: A message is sent to a service that performs an action based on that message. In processing this message, the service might perform further messaging, but the originator of the request does not have direct knowledge of any further messaging that occurs. For example, the message might contain information to update a database. Or, the message might contain details of an event that has occurred and requires action, such as sending messages to system administrators. Request/reply messaging: A message is sent to a service that performs an action based on that message and then returns a reply to the originator of the message.

For example, the request message might contain a query for information in a database that is sent back in the reply. Or, the request message might contain details of an action to perform that can have multiple outcomes, the result of which is sent back in the reply.

Publish/subscribe messaging
State information: Some information can change over time, and a node within the system accessing that information might need to track changes to that information. These nodes need to gain the information initially when they begin processing and then be informed of any changes that occur to that information. This form of information is called state information. An example is the current share price of a company; this has a value at any point in time, but this value can also change at any point, and a node might need to track a stock price over time.

Event information: Some actions need to be performed by a service whenever a particular event occurs. Information that describes an event that has occurred is called event information. An example is each time an item held in stock is sold; a stock control service might need to update stock information when this event occurs, or reorder that item from a supplier

Publish/subscribe messaging In publish/subscribe messaging; any number of consumers of information can receive messages that are provided by one or more producers of that information. In this case, a producer of information is called a publisher and a consumer of that information is called a subscriber. It provides the concept of a topic on which any number of interested consumers of information can subscribe to the topics in order to register their interest. A publisher can send messages containing information about a particular topic to all subscribers to that topic, without any knowledge of how many subscribers there are, or the details of the nodes that host those subscribers. It completely decouples the provider and the consumer of the information. Broker : A broker is required to hold information about which subscribers have subscribed to which topics and how to deliver messages to them. A publisher can then publish messages using the broker to all subscribers on that topic without knowing the details of those subscribers. There can be multiple publishers for a particular topic, and a subscriber to information about one topic can also be a publisher of information about other topics.

A message queuing infrastructure provides application programmers more time to concentrate on the business logic involved in providing a service, rather than communications logic and complicated failure processing.

Reliability and data integrity

Data that passes through a message queuing infrastructure can be broadly separated into two categories: Query data: This is transient data being sent through a system, derived from data that is stored safely within the system. If the query is lost, it might be inconvenient to the requester of that information, but the original data remains in the system and can be requested again.

An example is querying the current status of an order; if the request for this information is lost, or the response is lost, it does not affect the actual status of the order and the request can be submitted again. Business-critical data: This is data that is not stored elsewhere in the system. If this data is lost, important information, or a change in state within the system, is lost. An example is a message confirming a payment for an order; if the message confirming the payment is lost, the status of that order can become inconsistent. The customer might have paid money, or been provided a receipt, but the state of the order in the system does not correctly reflect that.

IBM WebSphere MQ It is an established and reliable message queuing middleware platform. Provides flexible and reliable solutions that address the breadth of considerations introduced in the previous chapter. A message queuing infrastructure built on WebSphere MQ technology helps provide an available, reliable, scalable, secure, and maintainable transport for messageswith exactly once delivery assurance.

WebSphere MQ message queuing infrastructure:

The nodes within a WebSphere MQ message queuing infrastructure are called queue managers. Multiple queue managers can run on a single physical server, and queue managers can run on a large variety of different hardware and operating system combinations Queue managers on all platforms provide facilities for message queuing using a point-to-point model, including request/reply and send and forget messaging The queue managers maintain the queues of the message queuing infrastructure and all of the messages that reside on those queues waiting to be processed or routed. The queue managers within the infrastructure are connected with channels. Messages automatically flow across these channels, from the producer to the consumer of that message, based on the configuration of the queue managers in the infrastructure.

WebSphere MQ Explorer, is a graphical user interface (GUI) used to configure and monitor the queue
managers within a WebSphere MQ infrastructure from a desktop workstation MQSC is a scripting interface to perform administration on all platforms WebSphere MQ objects are defined on each queue manager. These configure the queues hosted on that queue manager and the interaction between that queue manager, and other queue managers within the WebSphere MQ infrastructure. Objects are used to configure specific routes between the individual queue managers or queue manager cluster within the infrastructure.

SupportPacs
Following functionality and documentation are provided within a WebSphere MQ SupportPac. _ Reports about the performance of WebSphere MQ _ Documentation and guides regarding particular areas of function _ Sample applications that interact with WebSphere MQ _ Scripts that simplify the administration of WebSphere MQ _ Interfaces into WebSphere MQ from additional programming languages

Applications accessing a Queue manager

By connecting to a single queue manager within a WebSphere MQ infrastructure, an application is able to communicate with applications that connect to other queue managers within that infrastructure.

Generalizing destinations using WebSphere MQ

Names of queues are unique within each queue manager, but queues of an identical name can exist on other queue managers within the infrastructure.

Cross-platform support
The combination of a particular hardware type and a particular operating system is called a

platform.
A queue manager does not need to be hosted on the same hardware server as the applications that connect to that queue manager. When a queue manager is hosted on a different hardware server, a WebSphere MQ client product is required for the application to connect to the WebSphere MQ queue manager.

APIs
For applications to connect to a queue manager API is required

The message queue interface (MQI)

The core API provided by WebSphere MQ is the message queue interface (MQI). Applications developed using the programming languages C, COBOL are likely to use the MQI directly

APIs based on the WebSphere MQ object model

WebSphere MQ provides object-oriented APIs for a number of object-oriented programming languages. Although programming using these APIs differs among individual programming languages, all of these interfaces conform to a single design, called the WebSphere MQ object model. WebSphere MQ object-oriented APIs: 1. WebSphere MQ C++ 2. WebSphere MQ base Java API 3. WebSphere MQ classes for .NET 4. WebSphere MQ component object model (COM) interface

Standardized APIs available for WebSphere MQ

1. Java Message Service (JMS): JMS encapsulates both the point-to-point messaging model and the publish/subscribe messaging model 2. IBM Message Service Client (XMS): XMS is a messaging API for the C and C++ programming languages and the .NET environment

WebSphere MQ messages
To process an individual message, information is required about the message, which is not part of the message data itself, for example, whether the message requires a reply to be generated by an application processing that message Message descriptor Contains the meta information about the message Some of this information is specified by the application that sends the message, and some is generated and updated automatically by WebSphere MQ as the message passes through the message queuing infrastructure

Examples of this meta information, _ A uniquely generated, or custom, identity for the message _ The type of message, which determines whether a reply is required _ Details of where to send any replies to the message _ Whether this message has a limited life, called an expiry interval _ Information about how the message was produced, when, and by whom _ Information about the representation of data in the message body

Data conversion The individual machines that host the queue managers of a WebSphere MQ infrastructure can represent characters and numbers in different ways. Each individual queue manager, running on a particular machine, has an understanding of the way character and numeric data is stored on that machine. This means that it can perform data conversion to convert data in other representations to a representation WebSphere MQ can be configured to perform this in two ways: 1. Data conversion can be performed each time the message reaches a new queue manager over a channel. 2. When an application receives a message, it can specify that it wants data conversion to be performed. Message Formats To perform Data Conversion Message format should be known. The application that sends the message sets a message format in the message descriptor. If this is not specified, WebSphere MQ treats the message body as binary, and no data conversion can be performed.

Interacting with a WebSphere MQ infrastructure

Applications can connect to a queue manager using the APIs in order to access a WebSphere MQ infrastructure. Applications can connect to a queue manager hosted on the same machine on which they are running. This is an efficient connection method to a queue manager and is called a bindings connection to the queue manager. Applications can also connect to a queue manager hosted on a different machine using a client connection over a network

Facilities provided to a WebSphere MQ application

Facilities provided to an application that connects to a WebSphere MQ infrastructure through an individual queue manager: 1. An application can retrieve messages from queues hosted on that queue manager in order to process those messages and perform processing 2. Application can gain an identity within the infrastructure based on a queue on the queue manager to which it is connected 3. An application can send messages to queues anywhere within the infrastructure, as long as the queue manager to which it is connected has been configured to have knowledge of that destination. 4. An application can access the publish/subscribe functionality provided by the infrastructure to publish messages and subscribe to topics.

Units of work
Units of work allow multiple actions performed by an application to be grouped together so that any individual action within that unit of work can only complete successfully if all actions within that unit of work complete successfully.

The basic construct that allows actions within a unit of work to complete or fail as a group is a transaction