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.

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.