The Websphere Message Broker plugin for MidVision RapidDeploy follows a simple guiding principle. Your broker in Development is an accurate representation of your Production broker with the only differences being those that depend on the environment connectivity and capacity in which you are working. This principle is reflected in all intermediate brokers on your "route to live" between Development and production.

Your current working practices may not agree with this guiding principle, however it has been arrived at from experience within the industry.

  • Why does my code pass testing in development and QA and then fail when we move to production?
  • Why are my messages being processed in test environments but not when we move to production?
  • How can I get an environment representitive of production?

These are the questions we strive to answer with the Message Broker plugin.


The Message Broker Plugin is designed to work from a single template Message Broker xml file that is the the "model" of the production broker but with anything that might differe (e.g. broker queue manager, execution groups to deploy to, ports etc...) parameterised (or sometimes referred to as tokenized). By convention we adopt the following form of a parameter within a RapidDeploy WMessage Broker template @@PARAMETER_NAME@@.

This is very powerful, this single Message Broker template can then be used along with an appropriate dictionary (a key-value file that maps parameters/tokens to their real values) to create and deploy to any broker between DEV and PROD. This ensures that the basic structure of your broker is identical in each level through to production


You are not restricted to using this template approach as suggested here. The plugin can be used to treat every single broker as an individually configured entity. You could in theory represent all of your brokers as objects within RapidDeploy. You would have to manage your source through very strict control processes to achieve the same result. What falls naturally from using a single tokenized template is very error prone in the alternate approach. However you would still benefit from a single set of tasks being run in the same sequence for every deployment, so you still benefit from automation of deployment which reduces human error in those steps.

We think that the template approach though is very scaleable, and still works well if you have differing topologies (e.g. multiple execution groups in production versus a single execution group in DEV can be controlled by a single dictionary variable). It is very powerful.