WebSphere MQ Objects
Overview
MQ object types include queue managers, queues, process definitions, channels, namelists, and authentication information objects.
The manipulation or administration of objects includes:
- Starting and stopping queue managers.
- Creating objects, particularly queues, for applications.
- Working with channels to create communication paths to queue managers on remote systems.
- Creating clusters of queue managers to simplify the overall administration process, and to balance workload.
Object names
The naming convention adopted for WebSphere MQ objects depends on the object.
Each instance of a queue manager is known by its name. This name must be unique within the network of interconnected queue managers, so that one queue manager can unambiguously identify the target queue manager to which any given message is sent.
For the other types of object, each object has a name associated with it and can be referred to by that name. These names must be unique within one queue manager and object type. For example, you can have a queue and a process with the same name, but you cannot have two queues with the same name.
In WebSphere MQ, names can have a maximum of 48 characters, with the exception of channels which have a maximum of 20 characters.
Managing objects
You can create, alter, display, and delete objects using:
- Control commands, which are typed in from a keyboard
- MQSC commands, which can be typed in from a keyboard or read from a file
- PCF messages, which can be used in an automation program
- MQAI calls in a program
Object attributes
The properties of an object are defined by its attributes. Some you can specify, others you can only view. For example, the maximum message length that a queue can accommodate is defined by its MaxMsgLength attribute; you can specify this attribute when you create a queue. The DefinitionType attribute specifies how the queue was created; you can only display this attribute.
In WebSphere MQ, there are two ways of referring to an attribute:
- Using its PCF name, for example, MaxMsgLength.
- Using its MQSC command name, for example, MAXMSGL.
This book mainly describes how to specify attributes using WebSphere MQ and so it refers to most attributes using their MQSC command names, rather than their PCF names.
WebSphere MQ queues
There are four types of queue objects available in WebSphere MQ.
- Local queue object
A local queue object identifies a local queue belonging to the queue manager to which the application is connected. All queues are local queues in the sense that each queue belongs to a queue manager and, for that queue manager, the queue is a local queue.
- Remote queue object
A remote queue object identifies a queue belonging to another queue manager. This queue must be defined as a local queue to that queue manager. The information you specify when you define a remote queue object allows the local queue manager to find the remote queue manager, so that any messages destined for the remote queue go to the correct queue manager.
Before applications can send messages to a queue on another queue manager, have defined a transmission queue and channels between the queue managers, unless you have grouped one or more queue managers together into a cluster.
- Alias queue object
An alias queue allows applications to access a queue by referring to it indirectly in MQI calls. When an alias queue name is used in an MQI call, the name is resolved to the name of either a local or a remote queue at run time. This allows you to change the queues that applications use without changing the application in any way; you merely change the alias queue definition to reflect the name of the new queue to which the alias resolves.
An alias queue is not a queue, but an object that you can use to access another queue.
- Model queue object
A model queue defines a set of queue attributes that are used as a template for creating a dynamic queue. Dynamic queues are created by the queue manager when an application issues an MQOPEN request specifying a queue name that is the name of a model queue. The dynamic queue that is created in this way is a local queue whose attributes are taken from the model queue definition. The dynamic queue name can be specified by the application, or the queue manager can generate the name and return it to the application.
Dynamic queues defined in this way can be temporary queues, which do not survive product restarts, or permanent queues, which do.
Defining queues
Queues are defined to WebSphere MQ using:
- The MQSC command DEFINE
- The PCF Create Queue command
The commands specify the type of queue and its attributes. For example, a local queue object has attributes that specify what happens when applications reference that queue in MQI calls. Examples of attributes are:
- Whether applications can retrieve messages from the queue (GET enabled)
- Whether applications can put messages on the queue (PUT enabled)
- Whether access to the queue is exclusive to one application or shared between applications
- The maximum number of messages that can be stored on the queue at the same time (maximum queue depth)
- The maximum length of messages that can be put on the queue
Queues used by WebSphere MQ
WebSphere MQ uses some local queues for specific purposes related to its operation. You must define these queues before WebSphere MQ can use them.
Initiation queues
- Used in triggering. A queue manager puts a trigger message on an initiation queue when a trigger event occurs. A trigger event is a logical combination of conditions that is detected by a queue manager. For example, a trigger event might be generated when the number of messages on a queue reaches a predefined depth. This event causes the queue manager to put a trigger message on a specified initiation queue. This trigger message is retrieved by a trigger monitor, a special application that monitors an initiation queue. The trigger monitor then starts the application program that was specified in the trigger message.
If a queue manager is to use triggering, at least one initiation queue must be defined for that queue manager.
Transmission queues
- Temporarily store messages that are destined for a remote queue manager. You must define at least one transmission queue for each remote queue manager to which the local queue manager is to send messages directly. See also, WebSphere MQ Intercommunication.
Each queue manager can have a default transmission queue. When a queue manager that is not part of a cluster puts a message onto a remote queue, the default action, if there is no transmission queue with the same name as the destination queue manager, is to use the default transmission queue.
Cluster transmission queues
- Each queue manager within a cluster has a cluster transmission queue called SYSTEM.CLUSTER.TRANSMIT.QUEUE. A definition of this queue is created by default when you define a queue manager.
A queue manager that is part of the cluster can send messages on the cluster transmission queue to any other queue manager that is in the same cluster.
During name resolution, the cluster transmission queue takes precedence over the default transmission queue.
When a queue manager is part of a cluster, the default action is to use the SYSTEM.CLUSTER.TRANSMIT.QUEUE, except when the destination queue manager is not part of the cluster.
Dead-letter queues
- Stores messages that cannot be routed to their correct destinations. This occurs when, for example, the destination queue is full. The supplied dead-letter queue is called SYSTEM.DEAD.LETTER.QUEUE.
For distributed queuing, define a dead-letter queue on each queue manager involved.
Command queues
- The command queue, SYSTEM.ADMIN.COMMAND.QUEUE, is a local queue to which suitably authorized applications can send WebSphere MQ for processing. These commands are then retrieved by a WebSphere MQ component called the command server. The command server validates the commands, passes the valid ones on for processing by the queue manager, and returns any responses to the appropriate reply-to queue.
A command queue is created automatically for each queue manager when that queue manager is created.
Reply-to queues
- When an application sends a request message, the application that receives the message can send back a reply message to the sending application. This message is put on a queue, called a reply-to queue, which is normally a local queue to the sending application. The name of the reply-to queue is specified by the sending application as part of the message descriptor.
Event queues
- Instrumentation events can be used to monitor queue managers independently of MQI applications.
When an instrumentation event occurs, the queue manager puts an event message on an event queue. This message can then be read by a monitoring application, which might inform an administrator or initiate some remedial action if the event indicates a problem.
Trigger events are quite different from instrumentation events in that trigger events are not caused by the same conditions, and do not generate event messages.
WebSphere MQ queue managers
A queue manager provides queuing services to applications, and manages the queues that belong to it. It ensures that:
- Object attributes are changed according to the commands received.
- Special events such as trigger events or instrumentation events are generated when the appropriate conditions are met.
- Messages are put on the correct queue, as requested by the application making the MQPUT call. The application is informed if this cannot be done, and an appropriate reason code is given.
Each queue belongs to a single queue manager and is said to be a local queue to that queue manager. The queue manager to which an application is connected is said to be the local queue manager for that application. For the application, the queues that belong to its local queue manager are local queues.
A remote queue is a queue that belongs to another queue manager. A remote queue manager is any queue manager other than the local queue manager. A remote queue manager can exist on a remote machine across the network, or might exist on the same machine as the local queue manager. WebSphere MQ supports multiple queue managers on the same machine.
A queue manager object can be used in some MQI calls. For example, you can inquire about the attributes of the queue manager object using the MQI call MQINQ.
Process definitions
A process definition object defines an application that starts in response to a trigger event on a WebSphere MQ queue manager. See the "Initiation queues" entry under Queues used by WebSphere MQ for more information.
The process definition attributes include the application ID, the application type, and data specific to the application.
Channels
Channels are objects that provide a communication path from one queue manager to another. Channels are used in distributed queuing to move messages from one queue manager to another. They shield applications from the underlying communications protocols. The queue managers might exist on the same, or different, platforms. For queue managers to communicate with one another, define one channel object at the queue manager that is to send messages, and another, complementary one, at the queue manager that is to receive them.
For information on channels and how to use them, see WebSphere MQ Intercommunication.
Clusters
In a traditional WebSphere MQ network using distributed queuing, every queue manager is independent. If one 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 every queue to which it wants to send messages.
A cluster is a group of queue managers set up in such a way that the queue managers can communicate directly with one another over a single network, without the need for transmission queue, channel, and remote queue definitions.
Namelists
A namelist is a WebSphere MQ object that contains a list of other WebSphere MQ objects. Typically, namelists are used by applications such as trigger monitors, where they are used to identify a group of queues. The advantage of using a namelist is that it is maintained independently of applications; it can be updated without stopping any of the applications that use it. Also, if one application fails, the namelist is not affected and other applications can continue using it.
Namelists are also used with queue manager clusters to maintain a list of clusters referred to by more than one WebSphere MQ object.
Authentication information objects
The queue manager authentication information object forms part of WebSphere MQ support for SSL security. It provides the definitions needed to check certificate revocation lists using LDAP servers. CRLs allow Certification Authorities to revoke certificates that can no longer be trusted.
This book describes using the setmqaut, dspmqaut, dmpmqaut, rcrmqobj, rcdmqimg, and dspmqfls commands with the authentication information object.
System default objects
The system default objects are a set of object definitions that are created automatically whenever a queue manager is created. You can copy and modify any of these object definitions for use in applications at your installation.
Default object names have the stem 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; default objects of these names are required.
When you define an object, any attributes that you do not specify explicitly are copied from the appropriate default object. For example, if you define a local queue, those attributes that you do not specify are taken from the default queue SYSTEM.DEFAULT.LOCAL.QUEUE.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.