WebSphereMQ Integration mit Mule ESB Community Edition

2 Kommentare

Mule ESB ist eine Opensource-Implementierung eines Enterprise Service Bus. Die kostenpflichtige Enterprise Edition von Mule ESB setzt sich von der freien Community Edition unter anderem durch die out-of-the-box Integration des IBM WebSphereMQ Messaging-Produkts ab. Der folgende Beitrag erläutert, wie man auch in der Community Edition schnell und einfach ein WebSphereMQ-System als JMS-Provider anbindet.

Zunächst sind einige Bibilotheken mit der WebSphereMQ Client-API dem Klassenpfad hinzuzufügen. Im Einzelnen sind dies

  • com.ibm.mq.jar
  • com.ibm.mqjms.jar
  • dbhcore.jar

Diese JARs sind Teil der Installation eines WebSphereMQ-Servers. Alternativ können diese aus dem kostenfreien WebSphereMQ Client verwendet werden. Die kostenfreie Client-Variante ist allerdings nicht XA-fähig. Die JARs sind nach

$MULE_HOME/lib/opt

zu kopieren.

Zur Konfiguration des WebSphereMQ-System müssen nun folgende Parameter bekannt sein:

  • IP/Hostname
  • Portnummer
  • Name der QueueManagers
  • Name des Kanals
  • User / Password

Der entsprechende Mule-Konnektor kann dann wie folgt konfiguriert werden:

<jms:connector
   name="WebsphereMQConnector"
   connectionFactory-ref="MQConnectionFactory"
   specification="1.0.2b"
   username="mquser"
   password="password"
   numberOfConsumers="1"/>
<spring:bean
   id="MQConnectionFactory"
   class="com.ibm.mq.jms.MQQueueConnectionFactory">
   <spring:property name="transportType" value="1"/>
   <spring:property name="hostName" value="localhost"/>
   <spring:property name="port" value="1414"/>
   <spring:property name="channel" value="MY.CHANNEL"/>
   <spring:property name="queueManager" value="MY.QM"/>
</spring:bean>

Um die Namespaces „jms“ and „spring“ benutzen zu können, müssen diese im Root-Element der mule-config.xml deklariert werden. Vorausgesetzt, Sie nutzen Mule in Version 3.0, kann die wie folgt aussehen:

<mule xmlns="http://www.mulesoft.org/schema/mule/core"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:spring="http://www.springframework.org/schema/beans"
       xmlns:jms="http://www.mulesoft.org/schema/mule/jms"
    xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
       http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.0/mule.xsd
       http://www.mulesoft.org/schema/mule/jms http://www.mulesoft.org/schema/mule/jms/3.0/mule-jms.xsd">

Danach kann der WebSphereMQConnector z.B. zur Definition von Inbound JMS-Endpoints verwendet werden:

<endpoint 
   name="MyInQueue"   
   address="jms://queue:MY.QUEUE.IN"
   connector-ref="WebsphereMQConnector"/>
...
<flow id="MyFlow">
   <inbound-endpoint ref="MyInQueue" />
   ...
</flow>

Für JMS Consumer ist zu beachten, dass für zu lesende Warteschlangen mindestens die Privilegien GET, INQ und BROWSE vergeben worden sind. Dies ist hier detailiert beschrieben. JMS Producer benötigen PUT-Privilegien.

Fazit: wenn Ihre Queues nicht an verteilten Transaktionen teilnehmen müssen, kommen Sie auch mit der kostenfreien Community Edtion des Mule ESB aus, wenn Sie ein WebSphereMQ-System als JMS-Provider integrieren möchten.

Tobias Trelle

Diplom-Mathematiker Tobias Trelle ist Senior IT Consultant bei der codecentric AG, Solingen. Er ist seit knapp 20 Jahren im IT-Business unterwegs und interessiert sich für Software-Architekturen und skalierbare Lösungen. Tobias hält Vorträge auf Konferenzen und Usergruppen und ist Autor des Buchs „MongoDB: Ein praktischer Einstieg“.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Dirk Olmes

    Great summary.

    BTW the jars need to go to $MULE_HOME/lib/opt (not optional, there is no such directory)

    Why do you show the global endpoint here? The flow would be more consise if the endpoint declaration was just inlined.

    • Tobias Trelle

      BTW the jars need to go to $MULE_HOME/lib/opt (not optional, there is no such directory)

      Thanks for the hint. I just fixed it.

      Why do you show the global endpoint here? The flow would be more consise if the endpoint declaration was just inlined.

      The example was taken from a project where the global endpoints and flows were defined in separate configuration files. Most of the endpoints were used in several flows and therefore they were referenced.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.