WebSphere MQ eliminates application network concerns

Applications Applications Network Networking interface Applications MQI Queue manager Applications MQI Queue manager Networking interface Networking interface MCA MCA

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1-26 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Instructor notes:

Purpose — To compare the networking requirements of WebSphere MQ and the conversational style of program-to-program communication.

Details — The conversational style of program-to-program communication requires that a communications connection exist between each pair of communicating applications. In WebSphere MQ, it is the MCAs that are responsible for moving messages from one queue manager to another, so it is only each pair of MCAs that requires a communications connection. In this way, one communications connection can support multiple applications connected to one queue manager, sending messages to multiple applications connected to another queue manager.

Additional information — Keep the discussion at this level for now. Intercommunication has a full unit later on.

Transition statement — So far, it may seem as if everything is happening on one system. Often this requirement is true, but WebSphere MQ is able to connect applications over a network.

Uempty

Figure 1-12. Local and remote queues concept WM101 / VM1011.0

Notes:

When an application opens a queue, the queue manager determines the ultimate destination queue owner. If the queue is owned by the queue manager to which the application is connected, it is a local queue. If the queue is owned by another queue manager, it is a remote queue.

When the application puts a message on a queue that is local, the queue manager places the message directly on that queue. However, if the queue is remote, the queue manager places the message on a special local queue called a transmission queue.

A message channel agent is a component of WebSphere MQ. It is the task of the MCA to get the message from the transmission queue and send it over the network to the MCA at the receiving end. The receiving MCA then puts the message on the destination queue. Once the message has been safely committed on the destination queue, it is removed from the transmission queue.

Local and remote queues concept

Program B Program A Program C QM2: Local queue, transmit queue Q1: Local queue Queue manager QM1 Queue manager QM2 Q2: Local queue System 1 System 2 MQPUT Q2, QM2

MQPUT Q1 _{MQGET Q1} _{MQGET Q2}

MQI

Dead letter queue

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1-28 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

If the receiving MCA cannot put the message on the destination queue, the message is placed in the dead letter queue associated with that queue manager, or it can also be discarded, depending on the options specified by the sending application in the message descriptor.

Uempty

Instructor notes:

Purpose — Explain how a message is delivered safely to a remote destination queue. Details — Walk the students through what happens when Program A puts a message on local queue Q1. This process is easy because the queue manager to which Program A is connected owns Q1, and therefore knows where it is.

However, when Program A puts a message on remote queue Q2, the queue manager to which Program A is connected needs to know which queue manager owns Q2. It also needs to know where that queue manager is located in the network. This process is done in various ways, which you discuss later. Do not be tempted to discuss these ways now. Assuming the queue manager knows this information, the message can be forwarded to that queue manager and put on the destination queue.

However, the delivery of a message to a remote queue needs to be done reliably, and once only. The queue manager to which Program A is connected identifies a local queue called a transmission queue, and puts the message on that queue. It is the task of an MCA to get the message from the transmission queue and send it to a partner MCA at the other end of a communications connection. The receiving MCA then puts the message on the

destination queue Q2.

Once the receiving MCA has put the message on the destination queue, the protocol used by the two MCAs ensures that the message is removed from the transmission queue. If there is a communications failure during transmission, the same protocol also ensures that the two ends resynchronize when the communications connection is restored. Any

messages that have been safely received are removed from the transmission queue at the sending end, and any messages that were not safely received are sent again. This protocol is called the Message Channel Protocol (MCP) and is responsible for ensuring that a message is delivered to a remote queue once only.

If a message cannot be delivered, it would normally be put on the dead letter queue at the receiving end. However, the sending application may specify other options.

Additional information —

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1-30 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Figure 1-13. MQI calls WM101 / VM1011.0

Notes:

The component of WebSphere MQ that owns and manages queues is called a queue manager.

A queue manager also provides the message queue interface (MQI) to enable an application to access its queues and the messages they contain. The MQI is a simple application programming interface that is consistent across all platforms supported by WebSphere MQ. The MQI effectively protects applications from having to know how a queue manager physically manages messages and queues.

An application must first connect to a queue manager before it can access any of its resources. To connect to a queue manager, it issues an MQCONN or MQCONNX call. When the application no longer needs to be connected to the queue manager, it issues an MQDISC call.

To access a queue, an application must first issue an MQOPEN call. When it no longer requires access to the queue, the application issues an MQCLOSE call.

MQI calls

• Major calls – MQCONN – MQCONNX – MQDISC – MQOPEN – MQCLOSE – MQPUT – MQPUT1 – MQGET – MQSUB – MQSUBRQ • Minor calls – MQBEGIN – MQCMIT – MQBACK – MQINQ – MQSET Applications MQI Queue manager Queue manager object Namelist object Process definition object

Uempty Once a queue is opened, an application uses an MQPUT call to put a message on the

queue and an MQGET call to get a message from the queue. An MQPUT with a Topic String is also used to publish information which can be established for subscribers of the published information. The MQCLOSE call releases access to the queue. The MQPUT1 call enables an application to open a queue, put one message on the queue, and close the queue, all in a single call.

The MQPUT1, MQCMIT, and MQBACK calls enable an application to put and get messages as part of a unit of work.

A queue is an example of a WebSphere MQ object. However, there are other types of WebSphere MQ objects, such as a process definition, a namelist, and queue manager objects.

The following functionality was introduced in WebSphere MQ V7: using MQPUT with

topics, or topic strings, enables the publication of information. WebSphere MQ enables the subscription to publication information via the MQSUB and MQSUBR, which is outlined in Unit 8, “Linking.”

Every WebSphere MQ object has a set of attributes that describe the object. Each attribute has a name and a value. The definition of a WebSphere MQ object specifies the values of its attributes. Every WebSphere MQ object also has a name, which is considered to be one of its attributes. An application can use an MQINQ call to inquire on the values of the attributes of an object. It can use an MQSET call to set the values of certain attributes of a queue.

WebSphere MQ has two additional application programming interfaces: the Java interface for use in Java applications, and the Java Message Service (JMS), which allow

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1-32 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Instructor notes:

Purpose — To introduce the concepts of a queue manager and a WebSphere MQ object, and to describe the MQI calls.

Details — As shown in the figure, there are 10 major calls and five more specialized ones. It is not necessary to go into the details of the calls here, as they are covered in the

following units. Simply emphasize that this simple set of calls provides all the functionality that an application program needs to interact with WebSphere MQ.

It is sufficient to consider the following types of IBM WebSphere MQ objects: • Queue managers

• Queues

• Process definitions — the attributes of an application that must be known to a queue manager in order for the application to be started without operator intervention (used in triggering)

• Namelist — a WebSphere MQ object that contains a list of other WebSphere MQ objects

There are other types of WebSphere MQ objects as well.

WebSphere MQ V7 introduced the ability to publish using MQPUT with topic information. Subscriptions can be retrieved using the MQSUB and MQSUBR commands. More information is provided in Unit 8, “Linking, bridging, and the WebSphere MQ family.” Additional information —

Uempty

Figure 1-14. Message composition WM101 / VM1011.0

Notes:

A message is composed of two parts: the various headers used by WebSphere MQ, and the application data.

All WebSphere MQ messages always have a header called the WebSphere MQ message descriptor (MQMD). The message descriptor contains control information about the

message that is used by both the queue manager and the receiving application. It contains a number of fields that you review later in the course.

The application data is meaningful only to the applications that send or receive the message. It is possible to have a message with only a header and no application data. There is no restriction on the content of the application data, but there is a maximum allowable length of 100 MB for a physical message. However, later in the course you see that messages larger than that size can still be processed.

Message composition

• Set by application and queue manager • Header

– MQMD (message descriptor) • Application data

– Any sequence of bytes

– Meaningful only to the sending and receiving applications – Not meaningful to the queue manager

Application data Header

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1-34 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Instructor notes:

Purpose — To describe the two parts of a message.

Details — The application data (sometimes referred to as the “payload”) in a message has no meaning to the queue manager, and is not checked or processed in any way. Under certain circumstances, however, it may be converted from one character representation to another, and from one numeric representation to another, if wanted. You look more closely at application data conversion later in the course.

The message descriptor is used by the queue manager and the receiving application for the purposes of security, reporting, determining the sequence in which messages are delivered to the receiving application, and so on.

Some of the fields in the message descriptor are set by the application that puts the message on a queue; others are set by the queue manager on behalf of the application. Both the message descriptor and the application data are returned to the application that gets the message from the queue.

Do not get too deep on the contents of the message descriptor or the use of the other headers here. You look at the message descriptor in detail in Unit 3.

Additional information — In general, the default maximum message length is 4 MB, although you can increase it to a maximum length of 100 MB. An application is not limited to sending a maximum of 100 MB at a time; larger messages can be sent by using

segmentation, which is discussed in Unit 3.

Transition statement — Next, you look at some types of application models for which WebSphere MQ is well-suited.

Uempty

Figure 1-15. Parallel processing application design WM101 / VM1011.0

Notes:

Booking a vacation with a travel agent may require a number of tasks. In the scenario depicted in the figure, an agent needs to reserve a flight and a hotel room, and rent a car. All of these tasks must be performed before the overall business transaction can be considered complete.

Using WebSphere MQ, a request message can be put on each of three queues which serve the car rental application, the flight reservations application, and the hotel

reservations application. Each application can perform its respective task in parallel with the other two, and then put a reply message on the reply-to queue. The agent's application can then get the three replies and produce a consolidated answer.

This model allows several requests to be sent by an application without the application having to wait for a reply to one request before sending the next. All the requests can then be processed in parallel. Designing the system in this way can improve the overall

response time.

Parallel processing application design

Car Flight Hotel MQPUT CAR.RENTAL MQPUT FLIGHT MQPUT HOTEL

MQGET reply-to queue

CAR.RENTAL FLIGHT HOTEL MQPUT MQPUT MQPUT Reply-to queue

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Instructor notes:

Purpose — To explain how WebSphere MQ enables applications to be built in which units of processing can be done in parallel, or possibly even on different systems.

Details — A more complex application may involve sending a number of requests to different servers. For example, a travel agent might use an application to arrange a trip for a customer. The requirements of the customer might mean that the application needs to make a number of requests — to make an airline reservation, to book a hotel room, to run a credit check, and so on.

By using queues, these steps do not have to be performed serially. The requests can be put on different queues, and processed in parallel.

The application might then wait until it has received all the replies before preparing a consolidated response. Alternatively, the business logic may define a time limit to wait for the replies. In that case, the application may present some form of partial response with limited information after that time has elapsed.

As you have seen previously, the application design may involve having a separate process to receive and process the replies.

Additional information —

Transition statement — Next, you look at how an application can be started automatically by the arrival of a message on a queue.

Uempty

Figure 1-16. Triggering WM101 / VM1011.0

Notes:

In WebSphere MQ, it is possible to arrange for an application to be started automatically when a message is put on a queue and certain conditions are satisfied. This facility is known as triggering.

The figure depicts the sequence of actions involved in triggering.

1. Program A puts a message on an application queue that is enabled for triggering. 2. If the conditions for triggering are met, a trigger event occurs, and the queue manager

examines the process definition object referenced by the application queue. The process definition object identifies the application to be started, namely Program B. 3. The queue manager creates a trigger message whose fields contain information copied

from certain attributes of the process definition object and the application queue, including the name of the application queue. The queue manager puts the trigger message on an initiation queue.

4. A long-running program called a trigger monitor gets the trigger message from the initiation queue, and examines its contents.

Triggering

Process definition object MQPUT A.Q Program A Trigger types: • FIRST • DEPTH • EVERY Application queue (A.Q) Initiation queue (I.Q) Trigger monitor 1 2 3 4 6 5 MQGET I.Q MQGET A.Q Program B Queue manager

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5. The trigger monitor starts Program B, passing it information from the trigger message as a parameter, including the name of the application queue.

6. Program B opens the application queue and gets messages from it. Triggering can occur based on selected conditions:

• The first time a message arrives on a queue

• When the number of messages on the queue reaches a predefined number • Every time a message arrives on a queue

Uempty

Instructor notes:

Purpose — To explain how triggering works. Details — Cover triggering only at a high level. A trigger event may occur in one of three ways:

• The first message that arrives on the application queue can be the trigger event. In this case, the application would get the first message from the queue and continue to get any more messages that arrive later. It would terminate only if the queue is empty and no message arrives within a predetermined time.

• When the application queue reaches a specified depth, for example, 10 messages. The design of the started application would normally be similar to that of the previous case. • Every message that is put on the application queue. In this case, the started application would normally be designed to get and process just one message before terminating. This option is a difficult option to use, both from the point of view of administration and from the point of view of application design. Its use is not, therefore, generally

recommended. One problem is that it can cause multiple instances of a program or transaction to be scheduled within a short time, thus putting a strain on system resources.

It is possible to specify that messages below a certain priority are ignored by the queue manager when determining whether a trigger event should occur.

A trigger monitor may start the application synchronously within its own unit of execution or asynchronously as a separate unit of execution. It is worth pointing out that trigger monitors are supplied with WebSphere MQ, but users can write their own trigger monitors for the different operating systems and environments.

Additional information —

Transition statement — Next, you look at how WebSphere MQ can be used to implement client/server applications.

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Figure 1-17. Client/server application model WM101 / VM1011.0

Notes:

The server application (insurance quotations) can handle requests from multiple client applications. Each application client is identical, and requests information from the

application server. The message descriptor in each of the incoming messages identifies the appropriate reply-to queue for each request, so that the application server knows where to route the reply message.

Client/server application model

In document WM1011-VM1011INST (Page 41-66)