Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "the basic concept of MQ". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Object (objects)

The WebSphereMQ object is a resilient resource managed by WebSphereMQ.

Queue Manager (Queue managers)

Queue (Queues)

List of names (Namelists)

Distribution list (Distribution lists)

Process definition (Process definitions)

Channel (Channels)

Storage class (Storage classes)

These objects are unified on heterogeneous platforms. Commands for manipulating objects are available to system administrators. These command formats are different for different platforms. When you create a queue manager, the default object is automatically created. These default objects can help you define the objects you need.

Each object has a name so that it can be referenced through commands and MQI calls. Usually the name of each object in these object types must be unique. For example, a queue and a process can have the same name, but there cannot be two queues with the same name. This means that a local queue name cannot be the same as a template queue, a remote queue, or an alias queue. But there will be some special circumstances. Also, in an interconnected queue manager network, the queue manager name must be unique.

WebSphereMQ's object names are case-sensitive, so you need to carefully choose uppercase and lowercase letters when defining objects. In WebSphere MQ, names can be up to 48 characters, except for channels with a maximum of 20 characters.

Message

Type of message

WebSphereMQ defines four basic types of messages. Applications can define other types of messages. The four basic types are:

1. Request message Request message

The request message requires an answer. The query and update information sent from the client to the server is often a request message. The request message should contain the routing information of the reply message, that is, where the reply message is sent.

two。 Reply message Reply message

A reply message is a response to a request message. The information in the request message determines the destination of the response message. The application that handles the request and response controls the correlation between messages, which has nothing to do with the queue manager. The message itself contains enough information for the application to achieve this association.

3. Message message Datagram message

Datagram message is a message that does not need to be replied, and the message message is only an one-way message transmission.

4. Report message Report message.

Report messages are used in response to some system failures. Some report messages are created by the application and some report messages are created by the queue manager. In the latter case, the message cannot be sent correctly because the remote queue is full or does not exist. The application that originally sent the message could not detect this error, and the application could not handle it until the remote queue manager created such a report message and sent it to the local queue manager.

Queue managers use report messages for other purposes, such as reporting events. Messages may have an expiration time limit. If a message has not been processed by an application after the expiration time, the message will be cleared from the system by the queue manager. When the queue manager clears a failure message, it creates a report message whose destination address is provided by the failure message.

Another use for reporting messages is to ensure the arrival of messages. Applications can require that after the message they send arrives at the destination, they receive a report message, which is called a Confirmation of arrival. Similarly, applications can require that they receive a report message when another program takes the message, which is called a delivery confirmation (Confirmation of delivery). In both cases, the queue manager creates the report message and sends it to the appropriate destination.

There is also a special type of message called trigger message. Trigger messages are a special class of messages created by the queue manager. The queue manager of WebSphere MQ provides a mechanism to automatically trigger the application when a certain condition is met, and the trigger message is an important part of the trigger mechanism.

Applications can also define new message types. The queue manager cannot interpret these types, and the message type set by the application is defined by a range. These type values can be used to distinguish messages that different types of applications put in the same input queue.

Message length

The maximum message length is 100 MB (where 1 MB equals 1,048,576 bytes), and the default maximum message length is 4 MB. In fact, message length is affected by the following:

Maximum message length defined by the receiving queue

Maximum message length defined by the queue manager

Maximum message length defined by the transmission queue

Send or receive the maximum message length defined by the application

Free space to store messages

So sometimes information consisting of multiple messages may be needed to meet the requirements of the application.

How does the application send and receive messages?

The application uses MQI calls to send and receive messages.

For example, to put a message in a queue, the application:

Open the required queue by issuing a MQI MQOPEN call

Issue a MQI MQPUT call to put the message on the queue

Another application can fetch messages from the same queue by issuing a MQI MQGET call

Queue

Type of queue

Classified by creation method

Predefined queues are created by the administrator using the appropriate MQSC or PCF commands. Predefined queues are permanent; their existence has nothing to do with whether the application uses them, and the WebSphere MQ continues to exist after a restart.

A dynamic queue is created when the application issues a MQOPEN call that sets the name of the model queue. The queue that is created is based on a template queue. You can use the MQSC command DEFINE QMODEL to create a template queue. Dynamic queues inherit the properties of template queues. The template queue has an attribute that indicates whether the dynamic queue is permanent or temporary. Permanent queues continue to exist after the application and queue manager are restarted; temporary queues disappear after restarting.

Classify by function

1. Local queue (local queue):

A local queue is a queue that is physically in the local queue manager. Local queues actually exist in memory or disk storage terminals with the local system. The local queue manager controls access to the queue.

Applications can "PUT" messages to local queues or GET messages from local queues, and the program can query or modify some of the properties of these queues. Modifications to queue properties require appropriate permissions.

two。 Remote queue (remote queue):

A remote queue belongs to a queue manager that is not directly connected to the application. Access to such queues includes communication between the local queue manager and the remote queue manager. This kind of communication involves channels.

Applications can perform certain operations on remote queues, such as putting a message to a remote queue, but the program cannot remove messages from the remote queue. The application can only read messages from the local queue.

Applications have two different ways to access remote queues. The first is to provide both the queue manager name and the queue name when the program opens a remote queue. This requires the program to know which queue manager the destination queue belongs to. The second method is to have a definition of a remote queue on the local queue manager that contains enough information for the local queue manager to determine which queue manager the remote queue is located on.

The destination queue in the remote queue definition is not necessarily the local queue of the remote queue manager, it can also be a remote queue definition

The application puts a message to Q1 QM1 Q1 is a remote queue definition on the local queue manager: Q2at QM2. QM2 is the remote queue manager. Q2 is a remote queue definition Q3 at QM3 on QM2. Q3 is a local queue of QM3, and after two deliveries, the message finally arrives at Q3, the local queue of QM3.

This Multihop transmission makes sense for a number of reasons. Within a TCP/IP network, all machines have IP addresses, and the IP protocol itself handles routing between nodes. However, suppose that messages need to travel through different types of networks, which requires middleware to participate in routing. In the figure, QM2 is located on a machine connecting the TCP/IP network and the SNA network, and messages can be transmitted across the network by providing a remote queue definition Q2:Q3 at QM3 on the QM2.

Because access to remote queues always involves communication between queue managers, we need to define other resources, such as channels, transmission queues (Transmission queue).

3. Transmission queue (Transmission queue):

A transmission queue is a queue that temporarily stores messages destined for a remote queue manager. The queue manager uses the transmission queue to send messages to the remote queue in stages. Together with the message mobile program, the queue manager is responsible for transferring data to the remote queue. When the queue manager receives a request to send a message to a remote queue, it sends the message to a transmission queue associated with the destination queue manager, which is located on the local queue manager. The name of the destination queue manager may be provided by the application or can be obtained from the remote queue definition.

A transmission queue is one end of a connection between two queue managers. All messages directly destined for the same queue manager can be placed on the same transport queue, and the ultimate destination of these messages may not be the same. It takes only one transmission queue to transfer messages from one queue manager to another, but it is also possible that there are multiple connections between the two queue managers to provide different transport services, each with a different transmission queue.

Transmission queues are handled by MCA, and MCA is responsible for reliable delivery of messages between queue managers. MCA is actually a MQI application that processes messages on the transmission queue.

4. Dynamic queues and template queues:

In addition to having fixed-defined queues, WebSphere MQ provides programs with the ability to create queues dynamically as they execute. For example, an application, as a customer of a service, might create a dynamic queue and notify the server to send a response to the service request to the dynamic queue. Of course, queues with permanent definitions can also be used in this case. To simplify many of the parameters that must be set when creating a dynamic queue, a dynamic queue is always created based on a template queue that defines all the properties of the dynamic queue. When an application tries to open a template queue, WebSphere MQ creates a dynamic queue. WebSphere MQ provides system template queues for applications.

Dynamic queues can also be divided into two types, which have different life cycle and fault recovery characteristics. When the application that creates temporary dynamic queues (Temorary dynamic queue) closes, the queues are deleted and messages on the queues are lost. Such dynamic queues do not support message persistence. If the queue manager fails to restart, the temporary dynamic queue will not be restored. Another type of dynamic queue is persistent dynamic queue (Permanent dynamic queue). Persistent dynamic queues are deleted only if the delete option is defined when an application closes the persistent dynamic queue. Programs that delete persistent dynamic queues are not necessarily programs that create persistent dynamic queues. Persistent dynamic queues are restored after the queue manager is restarted and support persistent messages.

5. Start queue

The startup queue is the queue used in the trigger. If the queue manager will use triggers, at least one startup queue must be defined for this queue manager. The queue manager places the trigger message in the startup queue when the trigger event occurs. A trigger event is a logical combination of conditions detected by the queue manager. For example, a trigger event may be generated when the number of messages on the queue reaches a predefined depth. This event causes the queue manager to place trigger messages in the specified startup queue. This trigger message is retrieved by the trigger monitor, that is, the special application that monitors the startup queue. The trigger monitor then starts the application specified in the trigger message.

6. Cluster transmission queue

Each queue manager in the cluster has a clustered transport queue called SYSTEM.CLUSTER.TRANSMIT.QUEUE. When you define a queue manager, create a definition of this queue by default. A queue manager that is part of a cluster can send messages on the cluster transmission queue to any other queue manager in the same cluster. During route resolution, the cluster transmission queue takes precedence over the default transmission queue. The default action is to use SYSTEM.CLUSTER.TRANSMIT.QUEUE when the queue manager is part of the cluster, unless the target queue manager is not part of the cluster.

7. Dead letter queue (Dead letter queue)

A dead letter (undelivered message) queue is a queue that stores messages that cannot be sent to their correct destination. Sometimes there are situations where the queue manager cannot send the message to the destination, and the message is sent to a dead-letter queue. Messages in dead-letter queues often indicate problems that may occur in the system. For example, when a message arrives at the destination queue manager, it is found that the destination queue does not exist. Or the destination queue cannot receive mail messages, such as the destination queue is full, or it is set to not allow new messages to be added. Not all failures of message release operations result in messages being placed in a dead-letter queue. For example, if the application cannot "put" the message because of an error in the local queue, the MQI call returns the error code directly to the application.

Some errors can only be reported by a dead letter queue, for example, a message traverses the network and arrives at the destination queue manager, only to find that the destination queue is full. The machine on which the error is found is different from the machine on which the message application was originally placed, and the application that placed the message may not even be running. At this point, the destination queue manager sends the message to the dead-letter queue it owns, rather than simply throwing it away. This makes the error visible and provides an opportunity for the application to correct the error.

Dead letter queue is a solution for WebSphere MQ to deal with remote system errors. Applications can take advantage of other tools provided by WebSphere MQ to monitor and ensure reliable delivery and reception of messages.

When the queue manager is created, a dead-letter queue is created by default, and the queue name is SYSTEM.DEAD.LETTER.QUEUE. It is recommended that on the production system, it is necessary to create a dead-letter queue independently instead of using the system default dead-letter queue.

8. Command queue

The command queue SYSTEM.ADMIN.COMMAND.QUEUE is a queue used to store messages with PCF (programcommand format) placed by the application manager. This queue is mainly used when writing hypervisors. The specific use will be described in the following chapters. Command queues are automatically created for each queue manager when the queue manager is created.

9. Reply queue

When the application sends a request message, the application that receives the message can send the reply message to the sending application. This reply message is placed in a queue called a reply queue, which is usually the local queue for the sending application. The name of the reply queue is specified by the sending application that is part of the message descriptor.

10. Alias queue

An alias queue is actually another name for a local queue, a remote queue definition, or a queue name table. It is a simple name-to-name mapping that allows applications to access queues with another name. WebSphere MQ has shielded applications from many of the underlying system details, especially the details of network traffic, while alias queues allow access to queues with other names without modifying the application.

Queue manager

In WebSphere MQ, the queue manager is the basic software system, and the queue manager can be regarded as the container of queues and other objects. Each queue in WebSphere MQ belongs to a queue manager, which provides access to objects in queue management for applications and WebSphere MQ parts (some administrative tools).

A queue manager is a basic independent execution unit in WebSphere MQ. One or more queue managers can run on a machine.

Any application that needs to access the services provided by WebSphere MQ must first be connected to the queue manager, which is called the "local queue manager" (Local Queue Manager) to the application, and the local queue manager provides support for MQI calls to the program. Applications can manipulate and manage the various resources owned by local queue managers, and can also send messages to other queue managers.

The application requests services from the queue manager through a programming interface called MQI. These services include some basic operations such as "putting" a message to the queue or "fetching" a message from the queue. The queue manager also makes the queue a reliable place to store messages. It also controls security management and provides special queue functions, such as triggering queues.

To reduce the application's dependence on the environment in which it is running, WebSphere MQ's application can be connected to a queue manager that it does not know its name, which is the default queue manager on a machine. If the program sets the queue manager name parameter to empty when calling MQCONN, MQCONN will return a handle to connect to the default queue manager.

The queue manager owns each queue. The queue manager is responsible for maintaining the queues it owns and storing all messages it receives to the appropriate queues. Messages can be queued by an application or queue manager as part of its normal operation.

Channel message Channel (Messagechannels)

A message channel is a communication path that provides communication from one queue manager to another. Message channels are used in distributed queues to send messages from one queue manager to another. They shield the application from the underlying communication protocols. Queue managers may exist between heterogeneous or heterogeneous platforms. In order to communicate between queue managers, you must define a channel object to send messages in one queue manager and a channel object to receive messages in another queue manager. The message channel is an one-way link. It connects the two queue managers through a message channel broker (message channel agents).

Don't be confused with MQI channel (MQI channel) channel. There are two types of MQI channels, server connections (server-connection) and client connections (client-connection).

Message channel classification

The definition of message channels can be divided into the following six types:

L send Channel (Sender)

L receive Channel (Receiver)

L server channel (Server)

L requestor channel (Requester)

L Cluster send Channel (Cluster sender)

L Cluster receive Channel (Cluster receiver)

The combined form of message channel

If you want to implement message transmission between queue managers, you must define the corresponding channels on both queue managers. The combination of sender and receiver channels is as follows:

L send Channel-receive Channel (Sender-receiver)

Requestor Channel-Server Channel (Requester-server)

L requestor channel-send channel (Requester-sender (callback))

Server Channel-receive Channel (Server-receiver)

Cluster send channel-cluster receive channel (Cluster sender-cluster receiver)

Note: there are five combinations of channels, each of which is fixed and cannot be combined at will. The name of each pair of channels must be the same, for example, in the send channel-receive channel combination, the send channel name and the receive channel name must be the same, otherwise the channel will not start.

Message Channel usage send Channel-receive Channel (Sender-receiver)

Usage: the channel is activated by one system's send channel so that it can send messages to another system. The transmitting channel sends a start request to the receiving channel. The sending channel sends messages from the transmission queue to the receiving channel. The receiving channel puts the message on the destination queue.

Requestor Channel-Server Channel (Requester-server)

Usage:

(1) the channel is started by a requester channel in one system so that it can receive messages from another system. The requestor channel sends a request to the server channel at the other end of the channel to start. The server channel sends messages from the transmission queue to the requestor channel.

(2) the server channel can also start the channel and send messages to the requester, but this only applies to the full meaning of the server channel, that is, the server channel definition should contain the other party's connection name. A fully meaningful server channel can be initiated by the requester channel, or it can initiate communication with the server channel.

(3) it is best not to stop the Server and Request channels manually, but to rely on the Discint property of the Server channel to stop the channel.

Requestor channel-send channel (Requester-sender (callback))

Usage: the requester channel starts the channel and the sending channel terminates the session. The send channel then restarts the session based on the information in its channel definition (called callback). It sends messages from the transmission queue to the requestor channel. It is best not to stop the Sender and Request channels manually, but to rely on the Discint property of the Sender channel to stop the channel.

Server Channel-receive Channel (Server-receiver)

Usage: similar to send channel-receive channel, but only applied to full sense server channel. That is, the definition of the server channel should contain the connection name of the other party, and the initiator of the channel is the server channel.

Cluster send Channel (Cluster sender)

Usage: in a cluster, each queue manager has a cluster send channel through which cluster information can be sent to one of the queue manager resource managers. Queue managers can also send messages to other queue managers through this channel.

Cluster receive Channel (cluster receiver)

Function: in a cluster, each queue manager has a cluster receive channel. Through this channel, you can receive data messages and messages about the cluster.

MQI channel

The MQI channel is the channel for communication between the WebSphere MQ client and the queue manager on the server. The connection is established only when the client application makes a MQCONN or MQCONNX call. It is a two-way channel that can be used for sending and receiving, and is used as the transmission and response of MQI calls.

A MQI channel can connect a client to a single queue manager. There are two types of MQI channels that define two-way MQI channels.

Client connection Channel (Client-connectionchannel)

This type is used by clients of WebSphereMQ.

Server connection Channel (Server-connectionchannel)

This type is used by the server side running the queue manager, and applications running on the WebSphere MQ client will use this channel to communicate.

Compare message channel and MQI channel

The differences between message channels and MQI channels can be compared in two ways:

The MQI channel is bi-directional: an MQI channel can be used to send requests or to receive responses. The message channel can only communicate with one-way data. If you want to achieve two-way communication between two queue managers, you need to define two message channels, one for data transmission and the other for data reception.

The communication of the MQI channel is synchronous: when a MQI request is sent from the client to the server, the WebSphere MQ client must wait for a response from the server before sending the next request. On the other hand, the message transmitted in the message channel is independent of time. A large number of messages can be sent from one queue manager to another, and the sending queue manager does not have to wait for any response from the receiving queue manager.

Process

The process definition object defines the application that starts in response to trigger events on the WebSphere MQ queue manager. Process definition properties contain application identity, application type, and application-specific data.

Cluster

In traditional WebSphere MQ networks that use distributed queuing, each queue manager is independent. If the queue manager needs to send messages to another queue manager, it must define a transmission queue, a channel to the remote queue manager, and a remote queue definition for each queue to which it sends messages.

A cluster is a set of queue managers set up in a way that queue managers can communicate directly with each other on a single network without the definition of transmission queues, channels, and remote queues.

Name list

A name list is a WebSphere MQ object that contains a list of other WebSphere MQ objects. Typically, applications, such as trigger monitors, use name lists, which are used to identify a set of queues. The advantage of using a name list is that it is independent of application maintenance; it can be updated without stopping any applications that use it. Also, if one application fails, the list of names is not affected and other applications can continue to use it.

The name list is also used with queue manager clusters to maintain a list of clusters referenced by multiple WebSphere MQ objects.

Authentication information object

Queue manager authentication information objects (AUTHINFO) make up the WebSphere MQ-supported parts of secure Sockets layer (SSL) security. It provides the definition required to check the certificate revocation list (CRL) using the LDAP server. CRL allows certification authorities to cancel certificates that are no longer trusted.

This book describes the use of setmqaut, dspmqaut, dmpmqaut, rcrmqobj, rcdmqimg and dspmqfls commands on authentication information objects. For an overview of SSL and the use of AUTHINFO, see WebSphere MQ Security.

System default object

The system default object is a set of object definitions that are automatically created each time a queue manager is created. You can copy and modify any of these object definitions for use in the application at installation time.

The default object name has an entry SYSTEM.DEFAULT; for example, the default local queue is SYSTEM.DEFAULT.LOCAL.QUEUE, and the default receiver channel is SYSTEM.DEFAULT.RECEIVER. You cannot rename these objects; the default objects with these names are required.

When you define an object, copy any properties that you do not explicitly specify from the corresponding default object. For example, if you define a local queue, get those properties that you did not specify from the default queue SYSTEM.DEFAULT.LOCAL.QUEUE.

See Appendix 1, "system and default objects" for more information about system defaults.

MQI (message queue interface)

MQI (message queuing Interface) has the following components:

L function interface: the application can access the queue manager and its components through the function.

L data structure: the application uses the provided data interface to pass data to or obtain data from the queue manager.

Basic data type: is also used to transfer data from the queue manager or to obtain data from the queue manager.

Control command

The following is reference information for each WebSphere MQ control command:

Command name

Purpose

Amqmcert

Manage SSL certificates

Amqmdain

Configure or control WebSphere MQ services (Windows systems only)

Crtmqcvx

Convert data

Crtmqm

Create a local queue manager

Dltmqm

Delete queue Manager

Dmpmqaut

Dump the permissions of the open object

Dmpmqlog

Dump log

Dspmq

Show queue manager

Dspmqaut

Show permissions to open an object

Dmpmqcap

Display processor capacity and number of handlers

Dspmqcsv

Show command server status

Dspmqfls

Show file name

Dspmqtrc

Show formatted trace output (HP-UX, Linux, and Solaris)

Dspmqrtn

Display the details of the transaction

Endmqcsv

Stop the command server on the queue manager

Endmqlsr

Stop the listener process on the queue manager

Endmqm

Stop the local queue manager

Endmqtrc

Stop tracking entities (not for AIX)

Rcdmqimg

Write the image of the object to the log

Rcrmqobj

Recreate an object based on their image in the log

Rsvmqtrn

Commit or resume transactions in reverse order

Runmqchi

Start the channel initiator process

Runmqchl

Start the sender or requestor channel

Runmqdlq

Start the dead letter queue handler

Runmqlsr

Start the listener process

Runmqsc

Issue a MQSC command to the queue manager

Runmqtmc

Invoke the trigger monitor of the client (AIX client only)

Runmqtrm

Call the trigger monitor of the server

Setmqaut

Change the permissions of open objects

Setmqcap

Set handler capacity

Setmqcrl

Set up Certificate revocation list (CRL) server definition

Setmqscp

Set up service connection points (Windows systems only)

Strmqcsv

Start the command server for the queue manager

Strmqm

Start the local queue manager

Strmqtrc

Enable tracing (not for AIX)

Give an example

1. This command creates a default queue manager called Paint.queue.manager, creates the system and default objects, and requests two primary log files and three secondary log files:

Crtmqm-c "Paint shop"-ll-lp 2-ls 3-Q Paint.queue.manager

two。 The following command removes the queue manager travel and also suppresses any messages issued by the command.

Dltmqm-z travel

3. This command immediately ends the queue manager named saturn.queue.manager. All current MQI calls are completed, but new calls are not allowed.

Endmqm-isaturn.queue.manager

This is the end of the introduction to the basic Concepts of MQ. Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.