High Availability for WebSphere Message Broker & Websphere ESB

It’s important to consider how to ensure the performance and availability targets for a WebSphere Message Broker implementation are met. As the most common implementation of Message Broker is as a central hub that all messages in a messaging architecture are processed though, it is a potential bottleneck and single point of failure for the whole WebSphere MQ Queue Manager network.

Below the topology that I proposed and implemented in a lot of clients:

The diagram shows the topology. It consists of:

1. Two brokers BK.1 and BK.2. Each broker executes a specific set of execution groups that run each process in a specific set of flows parallelized or not.

2. Two Queue Manager WMB.BK1 and WMB.BK.2 corresponding respectively to BK.1 and BK.2 brokers.

3. A DB2 database dedicated hosting the configuration repository shared brokers.

4. The configuration manager CM to administer the two brokers.

5. The queue manager WMB.CM dedicated to configuration manager

We have also to consider the following points that contribute to high availability of any ESB environment. For example:

• Reliable hardware
• Shared queues
• Heath monitoring
• Failover clustering
• Online backup
• Dual networks
• Reliable operating system
• Online reconfiguration
• Fast reboot
• RAID disks
• Crash recovery
• Fast start up
• IP takeover
• Documented procedures
• Practicing procedures

Lightweight ESB or ESB?

Lately, we see a lot of lightweight ESBs that begins to emerge, we can already list some solutions:, Apache Camel, MuleESB, Spring integration, WebSphere Message Broker.. Etc

The Deployment of lightweight ESB can be done in a container like JBoss AS, Jetty, Tomcat, WebSphere Application Server..etc, and it can be also in a message broker, which's directly embedded like Camel that is embedded by default in ActiveMQ.

The question that arises, which brick the lightweight ESB covers ?

The main features that one would expect from a lightweight ESB are:

• Connectivity
• Routing
• Mediation (Transformation, EIP patterns, Orchestration)
• Monitoring

Concerning the orchestration, only the technical orchestration is covered. Sometimes we use the lightweight ESBs for aggregation services, or enrichment of data, but it must be remembered that we should not regard the lightweight ESB as an orchestrator of process.

Idem for monitoring, only the technical monitoring is covered.

A lightweight ESB alone, does not setup the BPM or BAM.

IBM SOA Vs Oracle SOA

In this link you find an Oracle Webinar (*), that explain why Oracle SOA Suite beats IBM patchwork of products J

Oracle says that IBM has not spent time for integrating or rationalizing their products, a difficult architecture to implement, they also explain that IBM is often based on their professional service to make the patchwork of products work, and that IBM proposes a grab bag of SOA products.

(*)You would need to register first...

Fuse ESB : How to configure Fuse ESB for authentication against an Active Directory server

Fuse ESB supplies a JAAS login module that enables it to use LDAP to authenticate users.

This tutorial will be focused on how we configure Fuse ESB for authentication against an Active Directory server.

The example defines a JAAS realm that uses the Active Directory server located at ldap://localhost:389 :

View of ldap-module.xml file to be copied into the Fuse ESB deploy/ directory:

<?xml version="1.0" encoding="UTF-8"?>

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"

  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"

  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

  <jaas:config name="karaf" rank="1">

    <jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule" flags="required">

      initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory

      connection.username=user_service@company.com

      connection.password=password

      connection.url=ldap://localhost:389

      user.base.dn= OU=Users,DC=company,DC=com

      user.filter=(samAccountName=%u)

      user.search.subtree=true

      role.base.dn=OU=Groups,OU,DC=company,DC=com

      role.name.attribute=cn

      role.filter=(sAMAccountName=Operator)

      role.search.subtree=true

      authentication=simple

    </jaas:module>

  </jaas:config>

</blueprint>

NB: You have to change the value of karaf.admin.role in etc/system properties, the value should correspond to your Group mentioned in role.filter of the ldap-module.xml file.


The example allow the authentication to Fuse ESB, if the user is present in the Organisation Unit “OU=Users” and member of Operator Group.


The LDAP module is automatically activated when you put the file in deploy directory.


Enjoy !