Deployment overview

Deployment is the process of transferring data to an execution group on a broker so that it can take effect in the broker domain. For deploying message flows and associated resources, the data is packaged in a broker archive (bar) file before being sent to the Configuration Manager, from where it is unpackaged and distributed appropriately.

This topic describes the environments from which you can perform a deployment, and then introduces a number of different types of deployment that you might need to use:
Most types of deployment can typically be configured to perform in one of two ways:

After reading this conceptual overview, find detailed instructions for particular tasks in the subsequent topics.

Read the WebSphere Message Broker Basics Redbook for further information about deployment.

Deployment environments

Depending on the environment in which you are working, you can choose one of the following options to initiate a deployment:

Message Brokers Toolkit

In the Broker Administration perspective of the workbench, the Domain Navigator view displays all the objects associated with a specific domain. For example, if you expand the Topology view, all the brokers in the domain are displayed; if you expand a Broker view, all the execution groups within that broker are displayed. From the Domain Navigator view you can deploy a topology to all the brokers in the domain, or you can deploy all the execution groups to a particular broker. You can also drag a broker archive (bar) file from the Resource Navigator view onto an execution group within the Domain Navigator view to deploy the contents of the bar.

You might typically use the workbench if you are working in a development environment or if you are new to WebSphere Message Broker.

mqsideploy command
You can deploy from the command line using the mqsideploy command. On the command line, you must typically specify the connection details as well as parameters specific to the type of deployment you want to perform. Details are given in each topic describing the types of deployment.

You might typically use the mqsideploy command in a script when you are more familiar with WebSphere Message Broker.

WebSphere Message Broker provides two files to help you when writing your own scripts for managing broker deployment outside the workbench. These are:

  • Initialization file mqsicfgutil.ini. This is a plain text file in the mqsideploy command's working directory that contains configurable variables that are required to connect to the Configuration Manager. For example:
    hostname = localhost
    queueManager = QMNAME
    port = 1414
    securityExit = test.myExit
    If you do not explicitly specify any of this information as parameters on the mqsideploy command (as has been done in the examples in subsequent topics), the information is taken from the mqsicfgutil.ini file.

    Alternatively, use the -n parameter on the command to specify an XML-format .configmgr file that describes the connection parameters to the Configuration Manager.

  • Batch file mqsideploy.bat. The parameters used with the mqsideploy command in WebSphere Message Broker Version 6.0 are not the same as those used in earlier versions of the command. On Windows platforms, use mqsideploy.bat if you want to use the same parameters as in previous versions.

Configuration Manager Proxy API

You can control deployment from any Java program using the Configuration Manager Proxy API. You can also interrogate the responses from the broker and take appropriate action.

The Configuration Manager Proxy API also allows Java applications to control other objects in the domain, such as brokers, execution groups, publish/subscribe topologies, topics, subscriptions and the Configuration Manager and its event log. Because of this, you can use the Configuration Manager Proxy API to create and manipulate an entire domain programmatically.

Types of deployment

The other topics within this section describe what each type of deployment does, the situation in which each type should and should not be used. To deploy message flows, message sets and other deployable objects to an execution group, use: In publish/subscribe scenarios, you can deploy topics and topologies: You can also cancel a deployment.

This table lists appropriate ways of deploying for a number of common scenarios.

Scenario Suggested deployment
Adding a broker to the domain (when not using publish/subscribe) None required.
Connecting publish/subscribe brokers using connections or a collective Delta topology deployment
Modifying the publish/subscribe topic hierarchy Delta deployment of the topics hierarchy (The changed elements in the topic hierarchy are deployed to all brokers in the domain.
Modifying the publish/subscribe topic hierarchy, after adding a new broker to the domain Complete topics deployment (The entire topic hierarchy is deployed to all brokers in the domain. The new broker also receives the complete topic hierarchy.)
Tidying up a broker's resources after removing it from the topology If the broker is part of a publish/subscribe network, or if you are using the Message Brokers Toolkit, initiate a delta publish/subscribe topology deployment. Otherwise, no deployment is required.
Creating an execution group Message flow application deployment using an incremental bar file deployment.
Deleting an execution group None required.
If a broker is not responding to a deploy request Ensure that the broker is running. If the broker is not running, cancel the broker deployment. You should only cancel a broker deployment if you are sure that the broker will never respond to the deploy request.