Introduction

One of the major improvements to the administration capabilities of IBM® WebSphere® Message Broker V6 is a new Java™ API that gives programmatic control of broker domains. This API, the Configuration Manager Proxy, is a direct interface with the Configuration Manager and lets applications manipulate all run-time object types used in Message Broker, including execution groups, message flows, and the broker itself.

Since WebSphere Message Broker V5 there have been two primary ways to deploy artifacts to the run-time broker: the Message Broker Toolkit or the mqsideploy command-line utility. Both methods use Broker Archive (BAR) files that typically contain a set of related message flows and any files required to run them, such as dictionaries.

The Configuration Manager Proxy adds a third, programmatic way of deploying BAR files to execution groups. Using the API, you can script deployment in any Java J2SE 1.4.2 environment, interpret the results, and easily manipulate any created objects. It can be used to completely administer domains of V2.1, V5, and V6 brokers.

Each of the three deployment techniques is tailored towards providing a means of deploying one broker archive file to a single execution group. Using the Message Broker Toolkit, deployment is achieved by associating or dragging the broker archive file onto a representation of the execution group. A single command-line invocation of the mqsideploy command can only invoke the deployment of a single broker archive file. And using the Configuration Manager Proxy API, the deployment method publishes a single broker archive file to a single execution group.

While deployment of one broker archive file at a time is adequate for many development and test environments, it is not always sufficient for large or production-scale domains, where there may be a requirement to coordinate deployment across multiple execution groups, brokers or Configuration Managers. It is somewhat possible to achieve such co-ordination using shell scripts and the mqsideploy utility, although this is rather difficult and time consuming to achieve, and the feedback (such as the broker’s BIP return codes) can not be interpreted easily. On the other hand, using the Configuration Manager Proxy API it is relatively easy to write a program that will achieve the goal of coordinating deployment, and can be used to produce a solution that will be powerful, maintainable and extensible. The rest of this article aims to describe the design and implementation of such a program.

Describing a deployment operation

In order to create a program that coordinates a set of deployment operations it is first useful to define what such a deployment operation is, and in this sample we will use the Java DeploymentOperation class to describe it. Logically, deployment is a mapping of a BAR file onto an execution group, and so it is the address of these two elements that need to be specified within a DeploymentOperation in order to make it complete.

A broker archive is a simple sequence of bytes that exist in a file, and so may be addressed by a standard file path, although execution groups are trickier to address. The Configuration Manager Proxy API provides the ExecutionGroupProxy class, instances of which represent an execution group as defined in the Configuration Manager, although this class does not provide the means of addressing the object from an unconnected state and so is not suitable here.

However, by viewing how each ExecutionGroupProxy can be obtained, you can determine what information is required. From the V6 documentation, here is an example of how ExecutionGroupProxy handles are obtained:

ConfigManagerConnectionParameters cmcp =
MQConfigManagerConnectionParameters("localhost", 1414, "QMGR");
ConfigManagerProxy cmp = ConfigManagerProxy.getInstance(cmcp);
TopologyProxy t = cmp.getTopology();
BrokerProxy b = t.getBrokerByName("BROKER1");
ExecutionGroupProxy e = b.getExecutionGroupByName("default");

From this sample, you can see that the following pieces of information are required:

1. Configuration Manager connection details: host name, port number, queue manager
2. Name of the broker on which the execution group exists
3. Name of the execution group

Item 1 assumes that security exits and SSL are not used. As an alternative, the location of a .configmgr file can be used, which contains the complete connection details for a given Configuration Manager.)

With the BAR file and the means of addressing an execution group, you can derive a simple Java implementation of this structure:

class DeploymentOperation {
	String host;
	int port;
	String qmgr;
	String brokerName;
	String egName;
	String barFile;
}

Deployment algorithm

This section describes the deployment algorithm . While it provides rudimentary atomic commit and rollback capability, it has a number of limitations including the assumption that the program will not fail during operation. For more information on the limitations of the algorithm and how to overcome them, see Possible enhancements below.

The algorithm to coordinate deployment is relatively straightforward. Each broker in turn is sent the new deployment request, and if it rejects the request for whatever reason, then any brokers running at the new configuration will have their changes backed out. If everything succeeds for all deployment requests, the new message flows are started.

In order to more closely specify this algorithm, you must first decide on how the deployment of each operation will be carried out. There are two techniques: synchronous and asynchronous.

Synchronous vs. asynchronous deployment

Deployment using the Message Broker Toolkit is typically an asynchronous operation. The deployment request is sent to the Configuration Manager, which forwards the request to the broker and reports to the Toolkit that it has initiated the deployment. The broker responds to the deployment request asynchronously, and the user is requested to open the Event Log editor to view the results. This procedure lets the user continue working in the Toolkit while the broker is finishing any existing work items and applying the new configuration, and even lets you send multiple deployment requests simultaneously, although each broker can only have one deployment in progress at any one time.

Sometimes however, a synchronous deployment mechanism is more convenient. Particularly when scripting deployment, it is more useful to know that the deployment was completely successful and that the broker has applied and is running the new configuration before continuing.

The Configuration Manager Proxy provides both synchronous and asynchronous deployment models. Deploying asynchronously, the Configuration Manager Proxy provides the ability to initiate a deployment, return control immediately to the calling application, and have the calling application either implement code to interrogate the event log messages at a future point in time, or have it notified if the event log subsequently changes (using an object observer). Deploying synchronously, you can initiate a deployment and have the method return only when the broker has reported that it is running the new configuration, explicitly failed, or reached a timeout condition.

Because we are designing a system to coordinate multiple deployments, it is tempting to adopt an asynchronous deployment model, which lets each broker process the deployment requests in parallel and thus improve the performance of the overall process. However, the asynchronous approach has three major disadvantages:

• Each broker can only have one deployment in progress at any one time, and so when firing off multiple deployments to the same broker, second and subsequent deployments to the same broker will fail unless they are synchronised.
• If one deployment fails and completed deployment operations need to be backed out, what happens to the brokers who have not yet responded to the original deployment request? It is not known whether they are running at the new configuration or are still at the old configuration, and therefore it is difficult to determine whether they need to have their configuration backed out. This would require a lot more work and disruption to potentially unaffected brokers.
• The algorithm for achieving asynchronous deployment is more complex and error-prone. The algorithm involves registering object observers on the broker’s event log and listening for updates from the broker. Compare this to the synchronous model, which is simply a case of reading the return code from the Configuration Manager Proxy’s deployment method.

For these reasons, the synchronous model will be adopted here. And with this in mind, you can specify the deployment algorithm at a greater level of detail:

1. For each deployment operation in the set
2. Attempt the deployment; wait for it to complete.
3. If deployment was successful, then
4. Continue with the next deployment operation.
5. Else
6. For each deployment operation already attempted:
7. Attempt to back out the deployment changes, and exit.
8. End for
9. End if
10. End for
11. Commit the changes

Issuing deployment requests

The method used to achieve deployment in the Configuration Manager Proxy in Line 2 above is ExecutionGroupProxy.deploy(). There are several variants of this method, although the type of information that can be supplied is similar for all:

1. Some sort of pointer to the BAR file being deployed -- either a file name or a reference to the InputStream of data that contains the file’s contents.
2. An indication as to whether the contents of the execution group should be cleared before deployment takes place.
3. The amount of time to wait for responses to come back from the broker. This parameter is typically used to distinguish between synchronous and asynchronous deployment.

Addressing the execution group is achieved through the object on which the deploy method is invoked, and so is not part of the parameters supplied to the method. However, a connection to the Configuration Manager and a valid handle to the correct ExecutionGroupProxy object still needs to be obtained before deployment, which means that the implementation of Step 2 becomes:

private DeployResult attemptDeployment(DeploymentOperation dep)
		throws ConfigManagerProxyException, IOException {
	ConfigManagerConnectionParameters cmcp = new
		MQConfigManagerConnectionParameters(dep.host, dep.port, dep.qmgr);
	ConfigManagerProxy cmp = ConfigManagerProxy.getInstance(cmcp);
	TopologyProxy t = cmp.getTopology();
	BrokerProxy b = t.getBrokerByName(dep.brokerName);
	ExecutionGroupProxy e = b.getExecutionGroupByName(dep.egName);
	return e.deploy(dep.barFile, true, 60000);
}

The key statement is the last one, which issues the deployment request to the Configuration Manager and waits for up to 60000 milliseconds (60 seconds) for the broker response. The rest of the method is involved with connecting to the Configuration Manager and getting the handle to the ExecutionGroupProxy object.

This method assumes that the parameters supplied to the method are valid and that any specified objects exist and are available. If this is not the case, when the invalid object is queried, the returned value will be null and a java.lang.NullPointerException will be thrown the first time the object is used. An improvement to this method would be to add stricter error checking, as shown in Possible enhancements below.

Interpreting deployment results

The next step is to interpret the response from the deployment method – the DeployResult object. This object is always returned from the ExecutionGroupProxy.deploy() methods, so long as the deployment message could at least be sent to the Configuration Manager. If the broker archive file could not be read successfully, the method throws a java.io.IOException. Or if the deployment message could not be put the Configuration Manager’s input queue, the method throws com.ibm.broker.config.proxy.ConfigManagerProxyLoggedException.

In the coordinated deployment algorithm, either of these exceptions will initiate a complete rollback of the deployment operation – equivalent to any failure response from the broker. This leads to the following draft method:

private boolean attemptDeploymentAndCheckResults(
			DeploymentOperation dep) {
	boolean deployWasSuccessful = true;
	try {
		DeployResult dr = attemptDeployment(dep);
		// TODO - Interpret 'dr'
	} catch (IOException ex) {
		// BAR file could not be read
		ex.printStackTrace();
		deployWasSuccessful = false;
	} catch (ConfigManagerProxyException ex2) {
		// BAR file could not be deployed
		ex2.printStackTrace();
		deployWasSuccessful = false;
	}
	return deployWasSuccessful;
}

This method returns true if the deployment was successful and false if it was not. As it stands, this method simply calls the previously described attemptDeployment() method, and only if either of the declared exceptions is caught, returns false.

To interpret the returned DeployResult object, the method to call from the DeployResult class is getCompletionCode(), which describes the outcome of the deployment request. The return value from this method is an object representing one of the following states:

success

Everything worked.

submitted

Request submitted to Configuration Manager, but nothing heard back in timeout period (in this case, 60 seconds).

initiated

Request deployed to broker, but broker did not respond within same timeout period.

failure

Broker rejected the deployment.

pending

Calling application used ConfigManagerProxy.beginUpdates() call to batch the deployment request.

successSoFar

Deployment affected multiple brokers, and some of them did not respond within timeout period.

The completion codes pending and successSoFar can be returned only for certain deployment types, and can be ignored for the purposes of this algorithm.

If the completion code is success or failure, then the algorithm is straightforward. In the successful case, the program can simply go on and attempt the next deployment in the set. For failure, the program can obtain more information on what went wrong by using the DeployResult.getLogEntriesForBroker() method, but the outcome will be to commence back-out of the deployment set.

On the other hand, the completion codes submitted and initiated cause a problem for coordinated deployment, because they represent an unknown state in the system. If the completion code is initiated, it usually means that the broker is not running. This situation is particularly difficult to resolve, because it suggests that if a backout operation were to be performed, it would not succeed either. The algorithm here does not backout the deployment, but instead warns the user that a broker did not respond. A production-quality implementation may differ.

If the completion code is submitted, then there is a problem with the Configuration Manager. This algorithm again does not commence a backout operation, but instead warns the user. This scenario is very unlikely, since the Configuration Manager must be running in order for the domain information to have been supplied to the Configuration Manager Proxy application in the first place.

These completion code choices are reflected in the following implementation of the TODO section in the attemptDeploymentAndCheckResults() method:

CompletionCodeType cc = dr.getCompletionCode();
if (cc == CompletionCodeType.failure) {
	deployWasSuccessful = false;
} else if (cc == CompletionCodeType.initiated) {
	System.err.println("Warning: Broker "+dep.brokerName+
		" did not respond");
} else if (cc == CompletionCodeType.submitted) {
	System.err.println("Warning: Config Manager at"+dep.host+
		":"+dep.port+"+ ("+dep.qmgr+") did not respond");
}

Scripting deployment of multiple BAR files

It is a relatively simple task to iterate through a set of DeploymentOperation objects using the coordinateDeployment() method.

private boolean coordinateDeployment(DeploymentOperation[] dep) {
	int i=0;
	boolean deployWasSuccessful = true;
	while ((deployWasSuccessful) && (i<dep.length)) {
		deployWasSuccessful =
			attemptDeploymentAndCheckResults(dep[i++]);
		if (!deployWasSuccessful) {
			backoutDeployment(dep, i-1);
		}
	}
	return deployWasSuccessful;
}

The method takes as input an array of DeploymentOperation objects and returns true if the deployment of all of these objects was successful. The if clause in this method causes the backoutDeployment() method to be called as soon as any deployment fails.

Backing out after a failure

Undoubtedly the most complicated procedure is backing out the deployment requests after a failure, because Message Broker does not provide native support for "undeployment" of resources or reverting to a previously deployed state.

There are several ways to use the Configuration Manager Proxy to enable Message Broker to provide this behaviour. Two possibilities:

1. After a successful deployment to a set of brokers, store a backup copy of the BAR files so that they can be redeployed in the future as a "last known good" working configuration.
2. Leave existing message flows and deployable artifacts alone during the deployment phase, and remove them only when all deployment requests have completed successfully.

The problem with (1) is that it requires all deployment to take place through this utility in order for the backups to be created. Technique (2) does not have this restriction, but because the old execution groups are deleted after the commit step, any artifacts that were deployed to the execution groups in the old configuration are removed in the new configuration. Nevertheless, the algorithm presented here will use Technique (2). For ideas on how to get round this limitation, see Possible enhancements below.

In order to use achieve Technique (2), you need to change the deployment process slightly. To prevent message flows from being overwritten, they must be deployed to a new execution group created by the Configuration Manager Proxy program. Then if all deployments are successful, the old execution groups will be deleted and the temporary execution groups will be renamed to the old one. If deployment has to be backed out after a failure, the newly created execution group can simply be deleted. To create the temporary execution group, a constant is created to derive a naming convention for the temporary execution groups. Do not use the suffix in any existing execution group names:

private static final String TEMP_EXECUTIONGROUP_SUFFIX = "_temp";

To deploy to the temporary execution group, you must first create it, which is simply a case of replacing the call to getExecutionGroupByName() in attemptDeployment() to:

ExecutionGroupProxy e =
	b.createExecutionGroup(dep.egName+TEMP_EXECUTIONGROUP_SUFFIX);

Thus, If the deployment operation is targeted at an execution group called default, the temporary execution group -- the one to which the new message flows will first be deployed -- will be default_temp.

With the code to deploy to the temporary execution groups in place, the backout algorithm is simply a case of deleting all execution groups with the temporary suffix.

private void backoutDeployment(DeploymentOperation[] dep,
 int upToLimit)
throws ConfigManagerProxyException {
for (int i=0; i<=upToLimit; i++) {
			ConfigManagerConnectionParameters cmcp = new
MQConfigManagerConnectionParameters(dep[i].host,
dep[i].port,
dep[i].qmgr);
ConfigManagerProxy cmp =
ConfigManagerProxy.getInstance(cmcp);
            TopologyProxy t = cmp.getTopology();
            BrokerProxy b = t.getBrokerByName(dep[i].brokerName);
            
            // Get hold of the temporary execution group
// and delete it.
>b.deleteExecutionGroup(dep[i].egName
+TEMP_EXECUTIONGROUP_SUFFIX);
        }
}

An interesting problem is what to do if the delete or any other part of the backout operation fails. For more information, see Possible enhancements below.

Committing deployment

If the deployment completes successfully, you need to delete the old execution groups and make the temporary execution groups live, which you do via the commitDeployment() method:

private void commitDeployment(DeploymentOperation[] dep) 
		throws ConfigManagerProxyException {
	for (int i=0; i<dep.length; i++) {
            ConfigManagerConnectionParameters cmcp = new
            MQConfigManagerConnectionParameters(dep[i].host,
dep[i].port,
dep[i].qmgr);
ConfigManagerProxy cmp = 
ConfigManagerProxy.getInstance(cmcp);
            TopologyProxy t = cmp.getTopology();
            BrokerProxy b = t.getBrokerByName(dep[i].brokerName);
ExecutionGroupProxy newEg = 
b.getExecutionGroupByName(dep[i].egName+
TEMP_EXECUTIONGROUP_SUFFIX);            
// In a single batch, delete the old execution group and rename the new one.
            cmp.beginUpdates();
            b.deleteExecutionGroup(dep[i].egName);
            newEg.setName(dep[i].egName);
            cmp.sendUpdates();
}
}

This method removes the execution group that was originally running and changes the name of the new execution group to be the same as the original one. It is a requirement of this program that this execution group was not running anything that wasn't redeployed in the new BAR file, because by removing the old execution group, any resources deployed to it are implicitly deleted. For information on how this might be resolved, see Possible enhancements below.

The beginUpdates() and sendUpdates() calls provide a way to batch multiple requests in the same message, which guarantees that the Configuration Manager will process them together (although it is no guarantee of transactionality -- that they will all succeed or all fail). In this case, it means that the Configuration Manager will delete the old execution group directly before renaming the new one; there is no window in which another Configuration Manager Proxy application could perform a potentially conflicting operation between these two.

As with the backout step, an interesting problem is what to do if the commit operation fails; again, see Possible enhancements below.

Caching Configuration Manager connections

It takes several seconds to establish a connection to the Configuration Manager, and when coordinating deployment to multiple brokers owned by the same Configuration Manager, it is not necessary to re-establish this connection every time during a single run of the utility. Therefore, to improve performance, it is a good idea to cache the ConfigManagerProxy object and reuse it if the Configuration Manager connection characteristics are the same as the ones already connected. To enable this capability, four new member variables are required:

private String hostCache = null;
private int portCache = -1;
private String qmgrCache = null;
private ConfigManagerProxy cmpCache = null;

The first three are used to check that the connection details are the same, and if they are, the ConfigManagerProxy handle is reused. The implementation is in a new getConfigManagerProxy() method:

private ConfigManagerProxy getConfigManagerProxy(String host,
int port,
String qmgr)
throws ConfigManagerProxyLoggedException {
    ConfigManagerProxy retVal = null;
    if ((host.equals(hostCache)) &&        (port == portCache) &&
        (qmgr.equals(qmgrCache))) {
             retVal = cmpCache;
    } else {
        ConfigManagerConnectionParameters cmcp = new
        MQConfigManagerConnectionParameters(host, port, qmgr);
               retVal = ConfigManagerProxy.getInstance(cmcp);
        hostCache = host;
        portCache = port;
        qmgrCache = qmgr;
        cmpCache = retVal;
    }
    return retVal;
}

If the connection details are different, the old ConfigManagerProxy cache will be replaced by the new one and the old connection will get closed by the Configuration Manager Proxy application. In this case it is not necessary to explicitly close the ConfigManagerProxy handle.

Possible enhancements

The sample presented here is just the first step towards a complete, coordinated deployment system. This section describes some key areas for enhancement if you want to use the algorithm.

Improve error checking

This sample does not do much error checking and handles errors in a non-resilient way. There are three causes for concern:

1. When domain objects are looked up using the Config Manager Proxy, null is returned from the get methods if the object could not be found. For example, in the following code: ExecutionGroupProxy e =b.getExecutionGroupByName("does_not_exist");e.startMessageFlows(); , if the execution group does_not_exist cannot be found, then the first statement will return null and the second statement will throw a java.lang.NullPointerException. The algorithm could be improved to check for the presence of domain objects.
   
   
2. The algorithm does not handle communication errors with the Configuration Manager well. The two error types that need catching are:

   ConfigManagerProxyLoggedException

   Thrown if the Configuration Manager was unable to complete an action (for example, stopping message flows).

   ConfigManagerProxyPropertyNotinitializedException

   Thrown if the Configuration Manager did not supply some required information (for example, the list of execution groups for a given broker) within a reasonable amount of time. Both of these types inherit from ConfigMangerProxyException.

   
   
3. The algorithm does not handle errors in the commit and backout code. In both of these cases, you need to add code to determine exactly what went wrong in these cases – perhaps by interrogating the execution groups using the Configuration Manager Proxy, and thereby deriving the correct cause of action. Currently, the sample exits with an error. To mitigate this, the (perhaps naïve) assumption made by the algorithm is that if the first deployment to a broker succeeds, the second one will also succeed. In other words, if the deployment to the temporary execution groups succeeds, then the commit operation will succeed also.

Improve atomicity of transactions

The algorithm is not intended to provide a completely transactional deployment solution, where you can guarantee that either all deployments succeed or all of them fail. Implementing the improved error checking described above will help achieve this goal, but a complete transactional solution requires a great deal of effort. Additionally, the backout algorithm does not completely restore the state of the system as it was before the program started. You could do more detailed interrogation of the objects deployed to the system (for example, discover whether they were originally running) and attempt to restore that state accordingly.

Selectively delete old execution group artifacts

Currently, the entire old execution group is deleted during the commit phase, which means that any artifacts deployed to that execution group that have not been redeployed will be removed. The Configuration Manager Proxy does not provide a way to obtain from the run-time broker the actual resources deployed to it, so that they may be redeployed elsewhere. However, it would be relatively easy to modify the algorithm to compare the contents of the old and the new execution groups and selectively delete only those artifacts that have been redeployed in the new system.

Adopt run-time versioning

Message Broker V6 enables user-definable version information to be associated with each deployed artifact, and the Configuration Manager Proxy exposes methods to retrieve this information. The algorithm could be improved to ensure that the resources being deployed are at the same or at a later version than the resources already running.

Resolve resource contention

There is a window in which both the old and the new message flows could be running, and thus in contention for the same resources. An improvement would be to stop any existing message flows before deployment occurs, stop the new message flows as soon as they are deployed, and modify the commit algorithm to start the newly deployed flows. This technique reduces but does not completely eliminate the window in which the new message flow could be processing messages, because new message flows are automatically started as soon as they are deployed.

With some knowledge of the message flows being deployed, you could remove this window altogether by temporarily restricting any resources required by the message flows. For example, if a message flow uses an MQInput queue to trigger processing, you could inhibit get operations on the queue on which the message flow is listening until deployment has been successfully committed.

Conclusion

This article has described some of the principal capabilities of the Configuration Manager Proxy API and how you might use them to create a system to coordinate the deployment of BAR files to multiple execution groups. The resulting sample is just the first step in achieving this goal, as the requirements of such a system are dependent on the processes and capabilities in place in the environment in which such a utility will be used.

Resources

• WebSphere Message Broker developer resources page
  Technical resources to help you use WebSphere Message Broker for connectivity, universal data transformation, and enterprise-level integration of disparate services, applications, and platforms to power your SOA.
  
  
• WebSphere Message Broker product page
  Product descriptions, product news, training information, support information, and more.
  
  
• WebSphere Message Broker information center
  A single Eclipse-based Web portal to all WebSphere Message Broker V6 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Message Broker environment.
  
  
• WebSphere Message Broker documentation library
  WebSphere Message Broker specifications and manuals.
  
  
• WebSphere Message Broker forum
  Get answers to your technical questions and share your expertise with other WebSphere Message Broker users.
  
  
• WebSphere Message Broker support page
  Access to all support resources for WebSphere Message Broker.
  
  
• developerWorks Java zone
  Access to a wealth of free technical information, downloads, and resources for Java developers.
  
  
• developerWorks WebSphere Business Integration zone
  For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
  
  
• WebSphere Business Integration products page
  For both business and technical users, a handy overview of all WebSphere Business Integration products
  
  
• WebSphere forums
  Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  
  
• Most popular WebSphere trial downloads
  No-charge trial downloads for key WebSphere products.
  
  
• Trial downloads for IBM software products
  No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
  
  
• Safari Bookshelf: e-library designed for developers
  Complete search and download access to thousands of technical books for a one-time subscription fee. Free trial for new subscribers.
  
  
• developerWorks technical events and Webcasts
  Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.
  
  
• developerWorks blogs
  Ongoing, free-form columns by software experts, to which you can add your comments. Check out Grady Booch's blog on software architecture.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Describing a deployment operation
• Deployment algorithm
• Possible enhancements
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Message Broker
• Webcast: WebSphere Message Broker: Converting Maps to ESQL using Support Pac IA9Y
• Briefing: WebSphere flexible business processes for a smarter planet
• Buy: WebSphere Message Broker

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers