Deployment methods

Choose the appropriate method of deployment according to the way in which you are working. You can use the workbench, the mqsideploy command, or functions described by the Configuration Manager Proxy (CMP) API.

Using the Message Brokers Toolkit
In the Broker Administration perspective of the workbench, the Domain view displays all the objects associated with a specific domain. For example, if you expand a topology, all the brokers in the domain are displayed; if you expand a broker, all the execution groups within that broker are displayed. From the Domain 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 Broker Development view onto an execution group within the Domain Navigator view to deploy the contents of the broker archive.

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

Using the mqsideploy command
You can deploy from the command line using the mqsideploy command. On the command line, you typically specify the connection details as well as parameters specific to the type of deployment. See Types of deployment for more about what you can deploy.

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 that invoke the mqsideploy command:

  • Initialization file mqsicfgutil.ini. This file 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
    Information that you do not explicitly specify as parameters on the mqsideploy command (as shown in the examples in subsequent topics), 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.

  • Windows platform Batch file mqsideploy.bat. On Windows® platforms, you can use mqsideploy.bat.
    Note: You must modify the parameters provided in this file if you are using Version 6.0 or later.
Using the Configuration Manager Proxy API
You can control deployment from anyJava™ program by using functions described by the Configuration Manager Proxy (CMP) (CMP) API. You can also interrogate the responses from the broker and take appropriate action.

Java applications can also use the CMP 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. This means that you can use the CMP to create and manipulate an entire domain programmatically.

Synchronous and asynchronous operations
The goals of a deployment are the same, regardless of how you initiate it. But the method that you choose might have an effect on how the operation is performed:
  • If you use the workbench or the Configuration Manager Proxy (CMP), the request is asynchronous. Control returns immediately either to the workbench or to your Java program. You must request the result of the operation at a later time:
    • If you are using the workbench, switch to the Broker Administration perspective and check the Event Log.

      A deployment request always completes, either because the broker has sent a response or the timeout has expired. If you have reason to believe that the deployment might not be successful, for example if you become aware that a problem with the network or the broker might prevent its completion, you can cancel the deployment request. Use this only in exceptional circumstances; cancelation might cause the state of the execution groups to become unpredictable.

    • If you are using the Configuration Manager Proxy (CMP), you can request responses to the deployment later in your program.

      When the request is received by the broker, it communicates with the execution groups that are affected by the contents of the deployment request. The broker waits for a certain amount of time, during which it expects the execution groups to complete the work. If the execution groups do not indicate that they have finished before the time has expired, the broker sends back a negative response with message BIP2066.

  • If you use the mqsideploy command, the deployment is synchronous and the command waits for a response. Control is returned to you (or to the script that issued the command) when a response is received by the broker, or when the wait time defined by the -w parameter has expired, whichever occurs first. If the time expires before a response is received, the command completes with a warning message that informs you what has happened. The warning does not mean that the command has failed, only that a response was not received during the time for which it waited.
Related tasks
Deploying
Developing applications that use the Configuration Manager Proxy Java API
Using the Configuration Manager Proxy API to deploy
Related reference
Workbench
Broker Administration perspective
mqsideploy command
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Last updated : 2009-01-07 15:21:50

af01282_