Administration Tools and Tasks

This section describes the tools you use to configure Message Queue services and the tasks that you need to complete to support a development or a production environment.

Administration Tools

Figure 3–5 shows a view of the message service that excludes the client connections and focuses on the broker components and on the tools used to manage these.

Figure 3–5 Administration Tools

You can use the following command-line tools to configure and manage the Message Queue service.

• Use the imqbrokerd utility to start the broker. You can use options to the imqbrokerd command to specify whether brokers should be connected in a cluster and to specify additional startup configuration information.

• After starting the broker, use the imqcmd utility to create, update, and delete physical destinations; to control the broker and its connection services, and to manage the broker’s resources.

• Use the imqobjmgr utility to add, list, update, and delete administered objects in a JNDI object store.

• Use the imqusermgr utility to populate a file-based user repository for user authentication and authorization.

• Use the imqdbmgr utility to create and manage a JDBC-compliant database used for persistent storage. (The built-in file store requires no external management.)

• Use the imqkeytool utility to generate self-signed certificates used for SSL authentication.

• Use the imqsvcadmin utility to install, query, and remove the broker as a Windows service.

A GUI-based administration console combines some of the capabilities of the imqcmd and imqobjmgr utilities. You can use it to do the following:

• Connect to a broker and manage it.

• Create and manage physical destinations.

• Connect to an object store, add objects to the store, and manage them.

JMX-Based Administration

To serve clients who need a standard programmatic means to monitor and access the broker, Message Queue also supports the Java Management Extensions (JMX) architecture, which allows a client application to manage resources programmatically.

• Resources can include applications, services, or devices. In the case of Message Queue, resources include everything that you can manipulate using imqcmd: the broker, services, connections, destinations, consumers, producers, and so on.

• Management includes the ability to dynamically configure and monitor resources, and the ability to obtain notifications about state changes and error conditions.

JMX-based administration provides dynamic, fine grained, programmatic access to the broker. You can use this kind of administration in a number of ways.

• You can include JMX code in your JMS client application to monitor application performance and, based on the results, to reconfigure the JMS objects you use to improve performance.

• You can write JMX clients that monitor the broker to identify use patterns and performance problems, and you can use the JMX API to reconfigure the broker to optimize performance.

• You can write a JMX client to automate regular maintenance tasks, rolling upgrades, and so on.

• You can write a JMX application that constitutes your own version of imqcmd, and you can use it instead of imqcmd.

In addition to offering expanded functionality (compared to the JMS API), JMX is also the Java standard for building management applications and is widely used for managing J2EE infrastructure. If your Message Queue client is a part of a larger J2EE deployment, JMX support allows you to use a standard programmatic management framework throughout your J2EE application.

The JMX specification defines an architecture that enables the programmatic management of any distributed resource. This architecture is defined by design patterns, APIs, and various services. Message Queue relies on the implementation of the JMX 1.2 specification, which is part of JDK 1.5.

To manage a Message Queue broker using this architecture, you create an MBean (a managed Java object) that represents the resource to be managed. You manage the underlying resource by configuring the MBean, invoking its operations, or listening for notifications. For complete information about using JMX to manage the Message Queue broker, see Sun Java System Message Queue 4.1 Developer’s Guide for JMX Clients.

Supporting a Development Environment

In developing a client component, it’s best to keep administrative work to a minimum. The Message Queue product is designed to help you do this and can be used out of the box. It should be enough just to start the broker. The following practices allow you to focus on development:

• Use default implementations of the data store (built-in file persistence), the user repository (file-based), and access control properties file. These are adequate for developmental testing. The default user repository is created with default entries that allow you to use the broker immediately after installation. You can use the default user name (guest) and password (guest) to authenticate a client.

• Use a simple file-system object store by creating a directory for that purpose, and store administered objects there. You can also instantiate administered objects directly in code if you prefer not to create a store at all.

• Use auto-created physical destinations rather than explicitly creating them on the broker. See the appropriate developer’s guide for information.

Supporting a Production Environment

In a production environment, message service management plays a key role in application performance and in meeting the enterprise requirements for scaling, availability, and security. In this environment, the administrator has many more tasks to perform. These can be roughly divided into setup and maintenance operations.

Setup Operations

Typically, you have to perform the following setup operations:

• Secure administrative access

  Whether you use a file-based or LDAP user repository, make sure that the administrator is in the admin group and has a secure password. If necessary, create a secure connection to the broker for the administrator.

• Secure client access

  Whether you use a file-based or LDAP user repository, populate the user repository with the names of users who can access the message service and edit the access control properties file to give them appropriate authorization. If necessary set up SSL-based connection services. To prevent unauthenticated connections, be sure to change the “guest” user’s password.

• Create and configure physical destinations

  Set destination attributes so that the number of messages and the amount of memory allocated for messages can be supported by broker resources.

• Create and configure administered objects.

  If you want to use an LDAP object store, configure and set up the store. Create and configure connection factory and destination administered objects.

• If stateful horizontal scaling is required, create a broker cluster.

  Create a central configuration file and designate a master broker.

Maintenance Operations

To monitor and control broker resources and to tune application performance, you must do the following after an application has been deployed:

• Support and manage application clients

  • Monitor and manage destinations, durable subscriptions, and transactions

  • Disable auto-create capability

  • Monitor and manage the dead message queue

• Monitor and tune the broker

  • Recover failed brokers

  • Monitor, tune, and reconfigure the broker

  • Manage broker memory resources

  • Expand clusters if necessary

• Manage administered objects

  Create additional administered objects as needed and adjust connection factory attributes to improve performance and throughput.