UX-Bridge - Installationshandbuch

Bei dem UX-Bus handelt es sich um eine Message Oriented Middleware (MOM) zum Austausch von Nachrichten unter den beteiligten Komponenten. Als Message Broker wird Apache ActiveMQ verwendet. Die Konfiguration des Routings erfolgt über das integrierte Apache Camel-Framework.

Der UX-Bus leitet die gesendeten Nachrichten an die konfigurierten Endpunkte weiter. So werden die von FirstSpirit erzeugten Nachrichten an den entsprechenden Adapter geleitet. Dieser erzeugt nach der Speicherung der Daten eine Rückantwort, die vom UX-Bus an eine Komponente im FirstSpirit-Server verschickt wird.

Weitere Informationen finden Sie im Kapitel Installation des UX-Busses.

Diese Komponente muss auf dem FirstSpirit-Server installiert werden. Die Hauptkomponente des Moduls ist ein Service, der Nachrichten erzeugt und an den UX-Bus schickt sowie Antworten von diesem entgegennimmt.

Weitere Informationen finden Sie im Kapitel Installation FirstSpirit-Modul.

Das UX-Bridge API ermöglicht das Verwenden des UXB-Services in eigenen Modulen. Dazu müssen das uxbridge-module-api-<version>.jar und JDOM in der Version 1.0 im Classpath liegen. Auf den Service kann dann folgendermaßen zugegriffen werden:

UxbService uxbService = context.getConnection().getService(UxbService.class);

Adapter bilden die Schnittstelle zu den unterschiedlichen Content-Repositories und sorgen dafür, dass die Daten in ein Repository geschrieben werden. Da Adapter sowohl vom verwendeten Repository als auch vom Datenmodel abhängen, sind es projektspezifische Komponenten.

Das Content-Repository oder auch Live-Repository ist eine Datenhaltungskomponente, die von FirstSpirit gefüllt und von Webapplikationen ausgelesen wird.

Wichtiges Architekturparadigma der UX-Bridge ist hier: Die Art und Anzahl der Repositories wird nicht vorgegeben, weil je nach Aufgabenart unterschiedliche Repositories unterschiedlich gut geeignet sind (siehe auch UX-Bridge Whitepaper).

Je nach Anforderung des Projekts ist also das geeignete Content-Repository auszuwählen und zu installieren.

Der Standalone-Betrieb ist der empfohlene Betriebsmodus des UX-Busses. In diesem Szenario sind alle wesentlichen Komponenten von einander entkoppelt. Außerdem eignet er sich am besten für die Konfiguration von Hochverfügbarkeits-Szenarien.

Installation

Der UX-Bus benötigt mindestens ein installiertes Java 7. Die genauen Systemanforderungen entnehmen Sie bitte dem mitgelieferten Technischen Datenblatt.

Stellen Sie sicher, dass die Umgebungsvariable JAVA_HOME gesetzt ist. Außerdem sollte JAVA_HOME/bin der Pathvariablen hinzugefügt werden.

Um den UX-Bus zu installieren genügt es, die in Verbindung mit dem Modul ausgelieferte Distribution (UX-Bus_<VERSIONSNUMMER>.zip) in einen selbst gewählten, geeigneten Ordner zu entpacken. Diese Distribution ist bereits so konfiguriert, dass sie in Verbindung mit der UX-Bridge gute Ergebnisse erzielt. Es handelt sich um ein vorkonfiguriertes Apache ActiveMQ mit integriertem Apache Camel, in dem die Routen für den UX-Bus und die Adapter bereits konfiguriert wurden.

Im Ordner bin finden sich die Startskripte. Das Skript activemq kann zum Starten des UX-Busses verwendet werden. Ausgehend vom Programmordner, in welchem ActiveMQ liegt:

Hierbei wird erst einmal die Standardkonfiguration genutzt. Die Konfiguration liegt im Ordner conf und muss später den eigenen Bedürfnissen angepasst werden.

Testen der Installation

Sobald der ActiveMQ Bus gestartet wurde, sollte eine Meldung darüber auf der Konsole geloggt werden:

INFO ActiveMQ JMS Message Broker (ID:apple-s-Computer.local-51222-1140729837569-0:0) has started

Mithilfe des Tools netstat kann geprüft werden, ob der Bus auch wirklich erreichbar ist und der Port richtig konfiguriert wurde.

Der Port ist in der Standardkonfiguration 61616 und sollte entsprechend der eigenen Konfiguration angepasst werden.

Zum Testen einfach folgende Zeile in der Konsole ausführen:

Installation als Dienst

Für den produktiven Einsatz ist die Konfigurationen als Windows-Dienst bzw. Unix-Service empfehlenswert. Dadurch wird sichergestellt, dass der Standalone-Server nach einem Neustart des Betriebssystems ebenfalls automatisiert gestartet wird.

Informationen zur Installation als Dienst bzw. Service finden sie unter:
http://activemq.apache.org/run-broker.html

Der Betrieb des UX-Busses als Modul in einem FirstSpirit-Server wird nur empfohlen, wenn es aus betrieblichen Gründen nicht möglich ist, den UX-Bus als eigenständige Komponente zu installieren, Sie aber Zugriff und Administrationsrechte für den FirstSpirit-Server besitzen.

In dieser Betriebsart kommt es in der Regel zu Warnungen im FirstSpirit-Serverlog, die darauf zurückzuführen sind, dass der UXB-Service vor dem UX-Bus gestartet wird. Näheres zu diesen Warnungen finden Sie am Ende dieses Unterkapitels.

Sollten aber Punkte wie Rückkanal (WebApp → FirstSpirit), Clustering und Failover eine Rolle spielen, dann sollte der UX-Bus als Standalone-Server betrieben werden.

Wenn sie den UX-Bus in diesem Modus betreiben möchten, gehen sie bitte wie folgt vor:

Weitere Informationen zu dem Thema Web-Applikationen finden sie im FirstSpirit Handbuch für Administratoren.

In diesem Betriebsmodus wird der UXB-Service vor dem UX-Bus gestartet. Da der UXB-Service direkt versucht, sich nach dem Start mit dem UX-Bus zu verbinden, werden im FirstSpirit-Serverlog mehrmals folgende Fehlermeldungen ausgegeben. Nach dem Start aller Komponenten sollte diese Meldung dann nicht mehr auftauchen. Hinweise für den Fall, dass die Meldung weiter auftaucht, finden sie im Kapitel Fehleranalyse.

WARN 20.07.2012 14:00:03.919 (org.apache.camel.component.jms.DefaultJmsMessageListenerContainer): Could not refresh JMS Connection for destination 'FS_OUT' - retrying in 5000 ms. Cause: Connection refused: connect

Der UXB-Service ist die Schnittstelle von FirstSpirit zum UX-Bus, über den die Nachrichten versendet werden.

Die Konfiguration des UXB-Service ist recht einfach:

XML-Reiter

Die Konfiguration wird über eine Spring XML DSL vorgenommen. Weitere Informationen zur Syntax finden Sie unter:
http://camel.apache.org/spring.html

Die Konfiguration der Beispielanwendung sieht z.B. folgendermaßen aus:

<?xml version="1.0" encoding="UTF-8" ?>
  <beans
    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jms="http://www.springframework.org/schema/jms"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
       http://camel.apache.org/schema/spring
       http://camel.apache.org/schema/spring/camel-spring.xsd
       http://www.springframework.org/schema/jms
       http://www.springframework.org/schema/jms/spring-jms-3.0.xsd">

    <bean id="jms" class="org.apache.camel.component.jms.JmsComponent">
      <property name="connectionFactory">
        <bean class="org.apache.activemq.ActiveMQConnectionFactory">
          <property name="brokerURL" value="failover:(tcp://localhost:61616)?maxReconnectAttempts=2&amp;startupMaxReconnectAttempts=10" />
        </bean>
      </property>
    </bean>
    <bean id="pooledConnectionFactory" class="org.apache.activemq.pool.PooledConnectionFactory" destroy-method="stop">
      <property name="maxConnections" value="10" />
      <property name="maximumActive" value="500" />
      <property name="connectionFactory" ref="jmsConnectionFactory" />
    </bean>
    <bean id="jmsConfig" class="org.apache.camel.component.jms.JmsConfiguration">
      <property name="connectionFactory" ref="pooledConnectionFactory" />
      <property name="transacted" value="false" />
      <property name="concurrentConsumers" value="10" />
      <property name="deliveryPersistent" value="true" />
    </bean>
    <bean id="jmsConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
      <property name="brokerURL" value="failover:(tcp://localhost:61616)?maxReconnectAttempts=2&amp;startupMaxReconnectAttempts=10" />
    </bean>
    <bean id="activemq" class="org.apache.activemq.camel.component.ActiveMQComponent">
      <property name="configuration" ref="jmsConfig" />
    </bean>
    <camelContext xmlns="http://camel.apache.org/schema/spring" id="camelContext" trace="false">
      <package>com.espirit.moddev.uxbridge.service</package>
      <template id="producerTemplate" />
      <endpoint id="FS-Out" uri="activemq:topic:FS_OUT"></endpoint>
      <onException>
        <exception>java.lang.Exception</exception>
        <handled>
          <constant>true</constant>
        </handled>
        <process ref="uxbExceptionProcessor" />
      </onException>
      <route id="Adapter-Statistics-Response-Route">
        <from uri="jms:topic:FS_IN" />
        <convertBodyTo type="com.espirit.moddev.uxbridge.api.v1.service.UXBEntity" />
        <bean ref="UxbServiceStatisticsResponseHandler" method="print" />
      </route>
    </camelContext>
    <bean id="UxbServiceStatisticsResponseHandler" class="com.espirit.moddev.uxbridge.service.UxbServiceStatisticsResponseHandler">
      <constructor-arg ref="camelContext" />
    </bean>
    <bean id="uxbExceptionProcessor" class="com.espirit.moddev.uxbridge.inline.UxbExceptionProcessor" />
  </beans>

Zu Entwicklungs- und Testzwecken ist es möglich den UXB-Service so zu konfigurieren, dass er ohne einen laufenden UX-Bus auskommt (siehe auch Kapitel Routing). Wenn es dem UXB-Service nicht gelingt, sich mit einem UX-Bus zu verbinden, loggt er regelmäßig eine Meldung darüber. Geschieht dies über längere Zeiträume, kann es schwierig werden, die Logs zu lesen. Deshalb kann eine Dummykonfiguration angelegt werden, die dafür sorgt, dass alle Nachrichten als Dateien in einem bestimmten Ordner abgelegt werden.

<?xml version="1.0" encoding="UTF-8" ?>
  <beans
    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
       http://camel.apache.org/schema/spring
       http://camel.apache.org/schema/spring/camel-spring.xsd">
    <camelContext xmlns="http://camel.apache.org/schema/spring" id="camelContext" trace="false">
      <package>com.espirit.moddev.uxbridge.service</package>
      <template id="producerTemplate" />
      <endpoint id="FS-Out" uri="file://log/uxb-messages"></endpoint>
      <onException>
        <exception>java.lang.Exception</exception>
        <handled>
          <constant>true</constant>
        </handled>
        <process ref="uxbExceptionProcessor" />
      </onException>
      <route id="Adapter-Statistics-Response-Route">
        <from uri="direct:in" />
        <convertBodyTo type="com.espirit.moddev.uxbridge.api.v1.service.UXBEntity" />
      </route>
    </camelContext>
    <bean id="uxbExceptionProcessor" class="com.espirit.moddev.uxbridge.inline.UxbExceptionProcessor" />
  </beans>

Nachdem der Service neu konfiguriert wurde, muss er neu gestartet werden, um die Änderungen anzuwenden.

In diesem Beispiel werden die Nachrichten im Ordner <FS-Home>/log/uxb-messages/ abgelegt. Diese Dateien werden allerdings nicht automatisch entfernt, was je nach Menge der gesendeten Nachrichten dazu führen kann, dass der Ordner sehr groß wird. Wenn viele Nachrichten zu erwarten sind, sollte man einen Mechanismus einrichten, welcher alte Nachrichten regelmäßig löscht.

Optionen-Reiter

Im zweiten Reiter des UXB-Services kann definiert werden ob die Nachrichten asynchron oder synchron versendet werden sollen. Durch das Setzen des Hakens werden die Nachrichten asynchron versendet. Dadurch kann eine höhere Performance erreicht werden, da anders als bei der synchronen Kommunikation nicht auf eine Rückantwort gewartet wird. Diese Verbesserung der Performance kann bei großen Datenmengen sehr vorteilhaft sein.

Informationen zu versandten Nachrichten werden zu Zeitmessungszwecken intern in einem Cache gespeichert, bis eine Rückantwort von einem Adapter eingetroffen ist. Über das Eingabefeld Tage die Timings erhalten bleiben kann die Dauer definiert werden, wie lange gewartet werden soll, bevor Nachrichten ohne Rückantwort aus dem Cache entfernt werden.

Über die Checkbox Status Nachrichten senden kann konfiguriert werden ob die UX-Bridge zu Beginn und nach der Generierung eine weitere Nachricht an den Bus schickt, so das auf diese Events im Adapter gezielt reagiert werden kann (weitere Details siehe UX-Bridge Entwicklerhandbuch).

Die Checkbox Projekt Informations-Nachricht senden steuert ob zu Beginn der Generierung einmalig eine Nachricht mit Projektinformationen gesendet wird (weitere Details siehe UX-Bridge Entwicklerhandbuch).

Abbildung 9. Optionen des UXB-Service

Das Routing wird in der Datei conf/camel.xml im Installationsverzeichnis des UX-Busses definiert. In der mitgelieferten Distribution sind bereits einige Standardrouten vorgegeben, so dass initial keine Anpassungen notwendig sind.

Details zur Konfiguration des Routings finden Sie im Kapitel Änderung des Routings.

Wurde der UX-Bus auf dem FirstSpirit-Server installiert, dann gehen Sie zur Konfiguration der Routen bitte folgendermaßen vor:

Eine Beschreibung der in FirstSpirit zu konfigurierenden Routen finden Sie im UX-Bridge Entwicklerhandbuch.

Die Standardausgabedatei für das Logging ist data/activemq.log. Bei Problemen sollte sie die erste Anlaufstelle sein. Das Logging kann in der Datei conf/log4j.properties konfiguriert werden, um zum Beispiel das Loglevel den eigenen Bedürfnissen anzupassen. In der Standardkonfiguration wird das Loglevel INFO verwendet. Es wird sowohl auf der Konsole als auch in dem Logfile ausgegeben:

log4j.rootLogger=INFO, console, logfile

Weiterhin können einzelne Pakete definiert werden, welche ein anderes Loglevel nutzen sollen. In der Standardkonfiguration sind es:

log4j.logger.org.apache.activemq.spring=WARN
log4j.logger.org.apache.activemq.web.handler=WARN
log4j.logger.org.springframework=WARN
log4j.logger.org.apache.xbean=WARN
log4j.logger.org.apache.camel=INFO

Für Debuggingzwecke kann das Loglevel dann beispielsweise durch das Ersetzen der jeweiligen Zeile angepasst werden. Für das Debuglevel also:

log4j.rootLogger=DEBUG, console, logfile

Hierbei sollte man sich dessen bewusst sein, dass im Debug-Modus viel mehr Meldungen erscheinen werden, was es erschwert, die relevanten Meldungen herauszufiltern. Um dies zu verhindern, könnte man die rootLogger-Konfiguration auf INFO belassen und nur die Konfiguration für das zu untersuchende Paket auf DEBUG oder sogar TRACE setzen.

Also:

log4j.logger.mein.eigenes.package=TRACE

In der mitgelieferten Distribution reicht es, folgende beiden Zeilen in der Datei <activemq>/conf/log4j.properties zu aktivieren, um passende Debugmeldungen für das Routing und die Verarbeitung der Nachrichten zu bekommen:

#Or for more fine grained debug logging uncomment one of these
#log4j.logger.org.apache.activemq=DEBUG
#log4j.logger.org.apache.camel=DEBUG

Das LoggingBrokerPlugin ermöglicht es noch detaillierter zu loggen, als log4j es tut und vor allem mehr Informationen darüber zu bekommen, was im UX-Bus passiert. Man kann das Plugin einfach in der conf/activemq.xml Konfigurationsdatei zu den <plugins> hinzufügen:

...
<plugins>
 <loggingBrokerPlugin logAll="true"/>
</plugins>
...

Nähere Erklärungen und weitere Attribute sind in der Apache ActiveMQ-Dokumentation enthalten: http://activemq.apache.org/logging-interceptor.html

Bei Fehlern und Problemen auf dem Broker hilft das Logging des UX-Busses. Wenn allerdings Fehler außerhalb des UX-Busses auftreten, sollte man auch hier die Möglichkeit des Loggings haben, um Probleme schnell zu beheben. Probleme können an allen zum UX-Bus verbundenen Clients auftreten. Dazu gehört der UXB-Service und die implementierten Adapter.

Der UXB-Service nutzt das über die FirstSpirit-API zur Verfügung gestellte log4j als Logging-Mechanismus. Es wird die Logging-Konfiguration genutzt, welche vom FirstSpirit-Server ebenfalls genutzt wird. Um DEBUG-Messages für den UXB-Service zu erhalten, genügt es das DEBUG-Logging für den FirstSpirit-Server zu aktivieren. Wählen Sie dazu im Server-Monitoring des FirstSpirit-Servers den Punkt Konfiguration → Protokollierung. Editieren Sie die aktive Konfiguration und ändern Sie die erste Zeile wie folgt:

log4j.rootCategory=DEBUG, fs

Nach der Speicherung der Konfiguration wird das Loglevel automatisch angepasst.

Adapter werden im Projekt umgesetzt, so dass es im Verantwortungsbereich des Entwicklers liegt, ein entsprechendes Logging vorzusehen und die Verwendung entsprechend zu dokumentieren.

Als Message Store des UX-Busses wird in der mitgelieferten Distribution KahaDB mit aktivierter Persistenz eingesetzt. Falls Sie auch für den Message Storage eine Desaster-Recovery-Strategie umsetzen wollen, finden Sie entsprechende Hinweise unter: http://activemq.apache.org/replicated-message-store.html

Detaillierte Hinweise zur Konfiguration des Message Storage finden Sie unter: http://activemq.apache.org/persistence.html

Backup des Message Storage

Bei der Auslieferung ist in der Konfiguration (\conf\activemq.xml) KahaDB zur Nachrichten-Persistenz konfiguriert:

<broker>
 <persistenceAdapter>
  <kahaDB directory="${activemq.data}/kahadb"/>
 </persistenceAdapter>
</broker>

Um ein Backup der KahaDB zu erstellen sind folgende Schritte notwendig:

Weitergehende Informationen finden sich unter:

http://activemq.apache.org/how-do-i-back-up-kahadb.html

Wird alternativ zur Kaha Persistenz eine JDBC Persistenz der JMS Nachrichten benutzt (http://activemq.apache.org/persistence.html), so sind die bekannten datenbankspezifischen Backup-Mechanismen zu nutzen.

Bei einem Ausfall des UX-Busses sollte sichergestellt sein, dass die Arbeit des UXB-Service und der Adapter nicht beeinträchtigt werden. Das heißt, dass das Versenden der Nachrichten entweder zu einem späteren Zeitpunkt erneut versucht wird oder der Versand direkt über eine zweite Instanz erfolgt.

Alle am jeweiligen UX-Bus angemeldeten Clients sollten die Möglichkeit haben, sich zu einem anderen UX-Bus neu zu verbinden oder einen erneuten Verbindungsaufbau nach einer gewissen Wartezeit zu versuchen. Um dies zu erreichen, gibt es das Failover-Protokoll.

In der Standardkonfiguration des UXB-Service ist das Failover-Protokoll bereits konfiguriert:

<property name="brokerURL" value="failover:(tcp://localhost:61616)"/>

In diesem Fall sorgt das Failover-Protokoll dafür, dass bei einem Verbindungsverlust in bestimmten Abständen versucht wird, eine neue Verbindung aufzubauen. Hier kann man die verschiedenen Parameter selbst bestimmen, z.B. wie lange das erste Mal gewartet werden soll, um welchen Faktor sich die Wartezeit bei jedem Versuch erhöht und wie lange die maximale Wartezeit sein soll ( initialReconnectDelay, backOffMultiplier, maxReconnectDelay).

Eine Failover-Konfiguration mit mehreren UX-Bus-Instanzen würde z.B. folgendermaßen aussehen:

<property name="brokerURL" value="failover:(tcp://broker1:61616, tcp://broker2:61616)?randomize=false"/>

In diesem Fall wird der broker1 zum Versenden der Nachrichten verwendet. Fällt dieser aus, werden die Nachrichten automatisch über broker2 gesendet.

Beim Implementieren eigener Adapter ist darauf zu achten, dass dort ebenfalls das Failover-Protokoll eingesetzt wird, um auch hier vor Verbindungsabbrüchen oder Ausfällen des UX-Busses geschützt zu sein.

Den größten Vorteil des Failover-Protokolls hat man, wenn man mehrere UX-Bus-Instanzen in einem Cluster konfiguriert. (siehe auch Kapitel Master/Slave-Betrieb) Man kann nun mehrere UX-Bus-Instanzen angeben, mit denen sich das Failover-Protokoll verbinden kann. Wenn die Verbindung zu einem UX-Bus unterbrochen wird, wird automatisch eine Verbindung zu einem anderen UX-Bus hergestellt. Bei zeitkritischen Anwendungen kann zusätzlich mit den Parametern backup und backupPoolSize eine bestimmte Anzahl an Backup-Verbindungen hergestellt werden, welche sofort bei einem Abbruch einer aktiven Verbindung genutzt werden können. Der Vorteil ist, dass die Verbindung schon in einem Standby-Zustand besteht und im Notfall nicht erst hergestellt werden muss.

Ein alternative Möglichkeit, um Failover beim Clustering zu nutzen ist, nur einen UX-Bus anzugeben und in der Konfiguration des UX-Busses zu veranlassen, dass die angemeldeten Clients automatisch eine Liste aller verfügbaren UX-Busse erhalten, zu denen sie bei Problemen eine Verbindung aufbauen können. Dafür gibt es die Eigenschaften updateClusterClients und rebalanceClusterClients in der TransportConnector-Konfiguration des UX-Busses.

Nähere Informationen zu den Failover-Parametern können Sie in der Apache ActiveMQ-Dokumentation finden: http://activemq.apache.org/failover-transport-reference.html

Um die Ausfallsicherheit zu erhöhen, bietet sich der Master/Slave-Betrieb an. Dabei fungiert eine Apache ActiveMQ-Instanz als Master und eine oder mehrere Instanzen als Slave. Die Clients senden ihre Anfragen immer an den Master, erst bei einem Ausfall des Masters wird eine der Slave-Instanzen zum neuen Master und übernimmt dessen Aufgaben. Die Nachrichten werden nun von dieser Instanz bearbeitet.

Dem gegenüber steht der Einsatz eines Network of Brokers, bei dem alle Apache ActiveMQ-Instanzen gleichberechtigt sind.

In beiden Fällen ist es wichtig das Failover im Client zu konfigurieren.

Shared storage Master/Slave

Beim Clustering-Modus Shared storage Master/Slave wird dieselbe KahaDB zum persistieren der Nachrichten von mehreren Brokern genutzt. Es kann immer nur ein Master auf die Persistenz zugreifen, während die Slaves geblockt werden. Die Slaves prüfen in regelmäßigen Abständen, ob sie Zugriff auf die Persistenz bekommen. Wenn der Master-Broker nun ausfällt und herunterfährt, bekommt der Slave-Broker den Zugriff auf die Persistenz. Erst in diesem Moment fährt der Slave-Broker komplett hoch und erlaubt es Clients, eine Verbindung aufzubauen.

Es gibt 2 Arten diese geteilte Persistenz zu realisieren:

Eine Möglichkeit ist es, eine relationale Datenbank zu nutzen, in welcher die Broker die Daten speichern. Ein Vorteil dieser Methode ist, dass Sicherungen von Datenbanken schnell und einfach erstellt werden können.

Die zweite Möglichkeit ist, auf ein gemeinsam genutztes Dateisystem zuzugreifen, auf welchem die Apache ActiveMQ-Broker dann die KahaDB ablegen. Die einzige Anforderung an dieses Dateisystem ist, dass es einen Locking-Mechanismus gibt, welcher sicherstellt, dass immer nur ein Broker auf die KahaDB zugreifen kann.

Um ein shared storage Master/Slave-Clustering zu konfigurieren, genügt es, zwei Broker zu konfigurieren, welche auf dieselbe Persistenz zugreifen. Die Broker sollten aufgrund der Ausfallsicherheit auf unterschiedlichen Maschinen laufen. Die Clients bekommen beide Brokeradressen im Failover-Protokoll übergeben und wenn ein Master-Broker ausfällt, wird sofort eine Verbindung zum neuen Master-Broker hergestellt. Dieser greift auf die Daten derselben Persistenz zu und ist somit aktuell. In jedem der Broker muss der Persistence-Adapter so angepasst werden, dass sie alle dasselbe Verzeichnis verwenden.

<persistenceAdapter>
 <kahaDB directory="/sharedFileSystem/sharedBrokerData"/>
</persistenceAdapter>

Näherer Informationen zur Konfiguration finden sie in der offiziellen Dokumentation unter: http://activemq.apache.org/shared-file-system-master-slave.html

Man sollte beachten, dass dieser Modus anfällig für Fehler in Verbindung mit dem Dateisystem ist. Beim Ausfall der Maschine, auf welchem sich das Dateisystem befindet, haben alle Broker, die darauf zugreifen sollen, keinen Zugriff mehr auf die Persistenz und müssen im schlimmsten Fall heruntergefahren werden. Wenn die eigene Anwendung vor Fehlern in Verbindung mit dem Dateisystem geschützt werden soll, sollte ein Dateisystem gewählt werden, welches ebenfalls auf mehrere Maschinen verteilt wird und welches beim Ausfall einer Maschine weiterhin funktionsfähig ist.

Ein Network of Brokers besteht aus mindestens zwei verschiedenen Brokern, welche jeweils einen eigenen Persistenzstore haben. In diesem Fall ist es nicht zwingend notwendig, dass jeder Broker die gleichen Nachrichten (bzw. alle Nachrichten) vorliegen hat. Ein Anwendungsfall für diese Architektur ist die Lastenverteilung.

Der Einsatz eines Netzwerkes von Brokern für die Verteilung der Last wird in den meisten Einsatzszenarien nicht nötig sein. Ein einzelner UX-Bus kann in der Regel das zu erwartete Nachrichtenaufkommen problemlos verarbeiten.

Wird trotzdem ein Loadbalancing gewünscht, so würde eine Client-Konfiguration z.B. folgendermaßen aussehen:

failover:(tcp://master1.IP:61616,tcp://master2.IP:61617)?randomize=true

Bei master1 und master2 handelt es sich um ein Network of Brokers. Die Verteilung der Nachrichten erfolgt nach dem Zufallsprinzip.

Diese Architektur lässt sich am besten an einem Beispiel verdeutlichen:

Broker A bekommt eine Nachricht in der Queue A und speichert sie im eigenen Store. Solange am Broker B kein Client nach Nachrichten aus Queue A lauscht, werden diese Nachrichten auf Broker B nicht benötigt, weshalb er sie auch nicht bekommt. In dem Moment, wo ein Client von Broker B nach Nachrichten aus der Queue A lauscht, wird von Apache ActiveMQ sichergestellt, dass auch Broker B diese Nachrichten erhält, um sie an den Client auszuliefern.

Die Informationen, welche Clients auf welchen Queues an welchen Brokern lauschen, werden durch so genannte Advisory Messages unter den verschiedenen Brokern ausgetauscht. So weiß jeder Broker zu jeder Zeit, welche Nachrichten für andere Broker interessant sind und welche nicht.

In der Konfiguration einzelner Broker kann man auch Filter für verschiedene Nachrichten definieren oder andere Broker von Nachrichten ausschließen.

Aus Sicht des Client handelt es sich hier um eine Hochverfügbarkeit der Broker, nicht aber der Nachrichten, die verschickt werden. Grund dafür ist die Tatsache, dass jeder Broker eine eigene Datenbank für die Nachrichten hat. Fällt ein Broker aus, werden die Nachrichten dieses Brokers erst wieder verteilt, wenn der Broker neu gestartet wurde.

Weiterführend Informationen zu diesem Thema finden sie unter:
http://activemq.apache.org/networks-of-brokers.html und
http://activemq.apache.org/how-do-distributed-queues-work.html

Durch den Einsatz eines oder mehrerer GenerationServer kann die Generierungslast vom FirstSpirit Master-Server entkoppelt werden. Der GenerationServer kann neben der Generierung der statischen Seiten, auch die Generierung der Nachrichten übernehmen. Das Senden der Nachrichten geschieht weiterhin über den UXB-Service, der auf dem FirstSpirit Master-Server läuft.

Um Hochverfügbarkeit zu gewährleisten, ist neben der korrekten Konfiguration der UX-Bridge-Infrastruktur, ebenfalls die Konfiguration des Content-Repositories entscheidend.

Die Wahl des Content-Repositories wird projektspezifisch getroffen. Konsultieren sie bitte die Dokumentation des verwendeten Repositories, um mehr über Hochverfügbarkeit zu erfahren.

Adapter werden projektspezifisch implementiert. Bei der Entwicklung müssen die Anforderungen bzgl. Hochverfügbarkeit entsprechend berücksichtigt werden. In vielen Szenarien können die Anforderungen durch mehrere Instanzen des Adapters und ein entsprechendes Routing abgedeckt werden.

Apache ActiveMQ bringt bereits von Haus aus Möglichkeiten zum Administrieren und Monitoren der Anwendung mit. So gibt es die Webconsole, welche unter http://localhost:8161/admin erreichbar ist, sobald sie aktiviert ist. localhost muss gegebenenfalls durch die Adresse der Maschine, auf welcher der UX-Bus läuft, ersetzt werden.

Details zur Aktivierung und Konfiguration der Webconsole sind in der Online Dokumentation zu finden: http://activemq.apache.org/web-console.html

Es kommt vor allem darauf an, dass nicht jeder uneingeschränkten Zugriff auf die Webconsole hat. Deshalb sollte in der conf/jetty.xml-Datei die Zeile

<property name="authenticate" value="false" />

durch die Zeile

<property name="authenticate" value="true" />

ersetzt werden.

Die berechtigten User und deren Zugangsdaten können dann in der Datei conf/jetty-realm.properties eingetragen werden (der Standarduser ist admin mit Username/Password: admin/admin).

Die Webconsole bietet einfache Funktionen, um Informationen über den Broker zu betrachten und einfache Statistiken angezeigt zu bekommen. Es werden unter anderem Informationen über Queues, Topics, Subscriber, Connections und das Netzwerk angezeigt. Außerdem gibt es eine Funktion zum Senden von Nachrichten. Dies ermöglicht einfaches Testen von Anwendungen ohne vorher extra Code zu schreiben. Die Webconsole lässt sich intuitiv bedienen, ist selbsterklärend und wird deshalb an dieser Stelle nicht näher erläutert.

Mit Apache ActiveMQ werden außerdem einige nützliche Kommandozeilentools ausgeliefert, welche grundlegende Admin-Funktionen bereitstellen, unter anderem auch einige Funktionen zum Monitoring. Mit dem Tool activemq-admin lassen sich zum Beispiel mit dem Parameter query verschiedenste Informationen zu Broker, Destination, Connector und Connection abfragen und auslesen. Mithilfe des Parameters browse können Nachrichten untersucht werden.

Eine genaue Beschreibung des Funktionsumfangs aller Möglichkeiten ist in der offiziellen Apache ActiveMQ-Dokumentation zu finden: http://activemq.apache.org/activemq-command-line-tools-reference.html

Eine andere Möglichkeit des Monitorings ist der Gebrauch des JMX-API (Java Management Extensions). Einige Parameter der oben erwähnten Kommandozeilentools (z.B. query) nutzen ebenfalls das JMX-API, um Informationen über Broker, Queues, usw. zu erhalten.

Details zur Konfiguration von JMX entnehmen Sie bitte der Apache ActiveMQ-Dokumentation: http://activemq.apache.org/jmx.html

Wenn der Apache ActiveMQ-Broker so konfiguriert ist, dass er JMX-Verbindungen zulässt, kann man beispielsweise eigene Hilfsprogramme schreiben, welche eine JMX-Verbindung herstellen und Brokerinformationen auslesen.

Hierzu wird auf das offizielle JMX-API (http://docs.oracle.com/javase/7/docs/technotes/guides/jmx/spec.html) und das Apache ActiveMQ-API, welche zusätzliche Funktionalität bereitstellt (http://activemq.apache.org/maven/5.10.0/apidocs/) verwiesen. Das Interface BrokerViewMBean aus dem Apache ActiveMQ-API ist ein guter Einstiegspunkt, um Daten des Brokers über JMX auszulesen.

Die MBeans von Apache ActiveMQ liegen in dem Package org.apache.activemq und können mit Tools wie der JConsole, JVisualVM oder ähnlichen ausgelesen werden. Informationen zu Apache Camel und den Routen finden sie in dem MBean org.apache.camel.

Über das JMX-Monitoring erhält man Informationen wie:

Im Fehlerfall können dadurch über das Monitoring wertvolle Informationen erlangt werden.

Advisory Messages werden von Apache ActiveMQ genutzt, um die Kommunikation von Brokern untereinander zu ermöglichen und Informationen über Queues, Consumer, usw. auszutauschen. Um diese Nachrichten für eigene Monitoringzwecke zu nutzen, kann zum Beispiel eine eigene Anwendung geschrieben werden, welche die Advisory Messages mithört.

Details hierzu sind in der Apache ActiveMQ-Dokumentation enthalten: http://activemq.apache.org/advisory-message.html

Der UXB-Service stellt selbst auch eine Möglichkeit zum Monitoring zur Verfügung. Jede Nachricht, die an den UX-Bus gesendet wird, erhält bei der Erstellung einen Zeitstempel. Wenn ein Adapter die Nachricht verarbeitet, wird ein weiterer Zeitstempel gesetzt sowie der Status nach der Verarbeitung (ok/fail). Im Auftrag kann eine Methode aufgerufen werden, die den UXB-Service abfragt und eine Liste von Nachrichten, deren Durchlaufzeit und deren Status zurück liefert. Dazu muss dem Auftrag am Ende eine Script-Aktion hinzugefügt werden:

#! executable-class
com.espirit.moddev.uxbridge.inline.UxbResultHandler

Da die Verarbeitung der Nachrichten asynchron erfolgt und sie je nach Adapter und Anzahl der Nachrichten unterschiedlich lange dauern kann, ist es möglich, über einen Scriptparameter (messageTimeout) die Zeit in Sekunden anzugeben, die der Service maximal auf die Antwortnachrichten warten soll, bevor die Durchlaufzeiten ausgewertet werden.

INFO 25.07.2012 10:38:44.811 Time for #uxb/pressreleasedetails/UXB/DE/704 (mongodb): 220ms
INFO 25.07.2012 10:38:44.812 Time for #uxb/pressreleasedetails/UXB/EN/704 (mongodb): 173ms
INFO 25.07.2012 10:38:44.813 48/48 deployed successfully (overall: 210ms, monogodb: 183ms, postgres: 238ms).
INFO 25.07.2012 10:38:44:813 finished task ‘GetTimings’ – schedule entry ‘UX-Bridge (News)’ (id=6191)

Die Ergebnisse der Nachrichten, die erst nach der spezifizierten Wartezeit abgearbeitet wurden, werden im Speicher gehalten. Die Dauer bis diese automatisch gelöscht werden, kann in den Einstellungen des Services konfiguriert werden.

Alternativ zum messageTimeout-Parameter kann ein Heartbeat konfiguriert werden. Hierfür wird der Scriptparameter enableHeartbeat auf den Wert true gesetzt. Per default wird ein maximaler Zeitraum von 15000 ms zwischen zwei Heartbeat-Nachrichten verwendet. Über den Scriptparameter heartbeatTimeout kann eine andere Zeit in Millisekunden konfiguriert werden. Empfängt der ResultHandler länger als die konfigurierte Zeit keine Heartbeat-Nachricht, gilt der Auftrag als fehlerhaft und eine Timeout-Nachricht wird ausgegeben.

INFO  06.07.2016 10:52:40.293 (com.espirit.moddev.uxbridge.service.UxbServiceImpl): Set heartbeat timeout to 10
INFO  06.07.2016 10:52:40.293 (com.espirit.moddev.uxbridge.service.UxbServiceStatisticsResponseHandler): Time since last heartbeat is 15, timed out
ERROR 06.07.2016 10:52:40.293 (com.espirit.moddev.uxbridge.service.UxbServiceImpl): Timeout

Hinweise, wie FirstSpirit-Projekte gesichert und wiederhergestellt werden können, sind im FirstSpirit Handbuch für Administratoren zu finden.

Auf dem Message-Broker befinden sich meistens nicht allzu viele Nachrichten. Sobald eine Nachricht, welche in einer Queue liegt, abgerufen wird, verlässt diese die Queue. Der Message-Broker übergibt die Verantwortlichkeit, was mit der Nachricht weiter geschieht, dem Adapter. Die Nachrichten, welche noch nicht vom Adapter „abgeholt“ wurden, liegen auf dem Broker. Wenn es gewünscht ist, diese zu sichern, kann das durch ein Backup der KahaDB geschehen, falls die Nachrichten und die KahaDB persistiert werden.

Details hierzu finden Sie im Kapitel Message Storage.

Das Vorgehen, um die Daten im Content-Repository zu sichern, ist abhängig von der eingesetzten Lösung. Je nach eingesetztem System sollten die Hinweise aus der entsprechenden Dokumentation befolgt werden, um ein Backup zu erstellen.

Sollte für den FirstSpirit-Server eine Desaster-Recovery notwendig sein, wenden Sie sich bitte an den Helpdesk der e-Spirit AG, um entsprechende Instruktionen zu erhalten.

Wenn der Fehler in der UX-Bus-Infrastruktur auftritt und diese beschädigt wurde, ist es in den meisten Fällen nicht notwendig, gesicherte Daten manuell wiederherzustellen. Im schlimmsten Fall gehen höchstens die Nachrichten verloren, welche noch nicht auf dem UX-Bus verarbeitet und auch nicht persistiert wurden. In der Standardkonfiguration ist die Persistenz allerdings aktiviert.

Auf Seite der Apache ActiveMQ wird die KahaDB genutzt, um Nachrichten zu speichern und zu verarbeiten. Deshalb gilt es im Falle eines Datenverlustes, die KahaDB wiederherzustellen. Das ist wiederum nur möglich, wenn der Broker so konfiguriert ist, dass die KahaDB persistiert wird. Ansonsten sind die Daten, welche sich zum Zeitpunkt des Crashs auf dem UX-Bus befanden, verloren. Im Normalfall sorgt Apache ActiveMQ selbst dafür, dass die persistierten Daten beim Neustart der Anwendung wiederhergestellt werden. Bei eigenen Konfigurationen, zum Beispiel in Verbindung mit einer relationalen Datenbank oder der KahaDB auf einem verteilten Dateisystem, können die Sicherungsmechanismen, die für die jeweilige Technik üblich sind, eingesetzt werden. Außerdem sei auf das Kapitel Hochverfügbarkeit der vorliegenden Dokumentation hingewiesen, welches sich mit dem Thema Hochverfügbarkeit beschäftigt.

Wenn der Adapter abgestürzt ist, sollten keine großen Probleme auftreten, denn ein Datenverlust ist nur in Extremsituationen zu erwarten. Im Normalfall bleiben die Nachrichten einfach so lange auf dem Broker, bis der Adapter wieder hochgefahren ist und diese Nachrichten abholt.

Lediglich die zur Zeit des Crashs verarbeitete Nachricht ist wahrscheinlich, abhängig von der Implementierung des Adapters, verloren. In diesem Fall kann in FirstSpirit ein erneutes Deployment der Daten durchgeführt werden.

Wenn Daten im externen Repository wiederhergestellt werden müssen, müssen dort die jeweils notwendigen Schritte durchgeführt werden. Diese unterscheiden sich je nach eingesetzter Anwendung. Einzelheiten sollten in der jeweiligen Dokumentation nachgeschlagen werden. Ein typischer Anwendungsfall könnte das Wiederherstellen einer Sicherung einer relationalen Datenbank sein.

Fehler in UX-Bridge-Aufgabe im Auftrag

INFO  18.07.2012 12:29:31.180 {seID=6191} (de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl): starting task 'UX-Bridge – Activate Generation' - schedule entry 'UX-Bridge (News)' (id=6191)

ERROR 18.07.2012 12:29:31.185 {seID=6191} (de.espirit.firstspirit.server.scheduler.ScriptTaskExecutor): error during script execution : de.espirit.firstspirit.access.ServiceNotFoundException: Service com.espirit.moddev.uxbridge.api.v1.service.UxbService' not found
de.espirit.firstspirit.access.ServiceNotFoundException: Service com.espirit.moddev.uxbridge.api.v1.service.UxbService' not found

Fehler im UX-Bridge-Generierungsauftrag

INFO  18.07.2012 12:40:45.943 {seID=6191} (com.espirit.moddev.uxbridge.service.UxbServiceImpl): UXB Service: calling Producer

ERROR 18.07.2012 12:40:51.098 {seID=6191} (com.espirit.moddev.uxbridge.service.UxbServiceImpl): Could not connect to broker!

In der UX-Bridge Statistics Report-Aufgabe treten Warnungen auf

INFO  18.07.2012 12:47:14.694 {seID=6191} (de.espirit.firstspirit.server.scheduler.ScheduleManagerImpl): starting task 'UX-Bridge Statistics Report' - schedule entry 'UX-Bridge (News)' (id=6191)

WARN  18.07.2012 12:47:14.736 {seID=6191} (com.espirit.moddev.uxbridge.service.UxbServiceImpl): Deployment for target expired: #uxb/pressreleasesdetails/UXB/EN/256 (postgres)

INFO  18.07.2012 12:47:14.736 {seID=6191} (com.espirit.moddev.uxbridge.service.UxbServiceImpl): Time for #uxb/pressreleasesdetails/UXB/EN/704 (mongodb): 580ms

Der UX-Bus loggt in der Standardkonfiguration keinerlei Informationen bzgl. des Routings von Nachrichten.

Im Kapitel Logging erhalten Sie Informationen, wie Sie ein entsprechendes Logging konfigurieren können.

Es ist möglich, dass der Adapter die Nachrichten nicht richtig verarbeiten kann. Der Entwickler des Adapters sollte in seine Implementierung entsprechende Logausgaben schreiben, damit solche Probleme im laufenden Betrieb erkannt werden können.

Je nach verwendetem Content-Repository können dessen Logfiles und eventuell vorhandene Administrationstools bei der Fehlersuche unterstützen. Da diese Komponenten projektspezifisch gewählt werden, können wir an dieser Stelle keine zusätzlichen Hinweise geben.

FirstSpirit Server meldet, dass keine-JMS Verbindung zum UX-Bus aufgebaut werden konnte

WARN  17.07.2012 16:30:46.483 (org.apache.camel.component.jms.DefaultJmsMessageListenerContainer): Setup of JMS message listener invoker failed for destination 'FS_IN' - trying to recover. Cause: java.io.EOFException

WARN  17.07.2012 16:30:46.486 (org.apache.camel.component.jms.DefaultJmsMessageListenerContainer): Setup of JMS message listener invoker failed for destination Adapter-Statistics-Response-Route' - trying to recover. Cause: java.io.EOFException

WARN  17.07.2012 16:30:46.488 (org.apache.camel.component.jms.DefaultJmsMessageListenerContainer): Could not refresh JMS Connection for destination 'ROUTEIN' - retrying in 5000 ms. Cause: Could not connect to broker URL: tcp://localhost:61616. Reason: java.net.ConnectException: Connection refused

WARN  17.07.2012 16:30:46.489 (org.apache.camel.component.jms.DefaultJmsMessageListenerContainer): Could not refresh JMS Connection for destination Adapter-Statistics-Response-Route' - retrying in 5000 ms. Cause: Could not connect to broker URL: tcp://localhost:61616. Reason: java.net.ConnectException: Connection refused

WARN  17.07.2012 16:30:46.489 (org.apache.activemq.transport.failover.FailoverTransport): Transport (tcp://127.0.0.1:61616) failed, reason:  java.io.EOFException, attempting to automatically reconnect

ERROR 17.07.2012 16:30:51.666 (org.apache.activemq.transport.failover.FailoverTransport): Failed to connect to [tcp://localhost:61616] after: 10 attempt(s)

False positives in UX-Bridge Statistics Report Aufgabe

ERROR Tue Jul 24 14:37:30 CEST 2012 (de.espirit.firstspirit.client.AbstractGuiHost) ExceptionHandler.uncaughtException() - java.lang.SecurityException: Unable to create temporary file
java.lang.SecurityException: Unable to create temporary file
java.lang.SecurityException: Unable to create temporary file
    at java.io.File.checkAndCreate(null:-1)
    at java.io.File.createTempFile0(null:-1)
    at java.io.File.access$100(null:-1)
    at java.io.File$1.createTempFile(null:-1)
    at sun.misc.IOUtils.createTempFile(null:-1)
    at javax.imageio.stream.FileCacheImageInputStream.<init>(null:-1)
    at com.sun.imageio.spi.InputStreamImageInputStreamSpi.createInputStreamInstance(null:-1)
    at javax.imageio.ImageIO.createImageInputStream(null:-1)
    at javax.imageio.ImageIO.read(null:-1)
    at de.javasoft.plaf.synthetica.painter.ImagePainter.<init>(ImagePainter.java:234)
    at de.javasoft.plaf.synthetica.painter.ScrollBarPainter.paintScrollBarThumbBackground(ScrollBarPainter.java:175)
    at de.javasoft.plaf.synthetica.painter.SyntheticaPainter.paintScrollBarThumbBackground(SyntheticaPainter.java:569)
    at javax.swing.plaf.synth.ParsedSynthStyle$DelegatingPainter.paintScrollBarThumbBackground(null:-1)
…
Trace message truncated for length over 10K

Falls noch nicht vorhanden, so muss über den MQ Explorer ein Warteschlangenmanager mit dem Namen QMA eingerichtet werden. Als Portnummer wird die 1414 genutzt. Alle anderen Einstellungen: Default.

Abbildung 10. MQ Explorer Warteschlangenmanager

Falls noch nicht vorhanden, so muss unterhalb des Warteschlangenmanagers QMA ein Empfangsprogramm mit dem Namen QMA.LISTENER und dem Port 1414 eingerichtet werden.

Abbildung 11. MQ Explorer Empfangsprogramme

An dieser Stelle wird das seit IBM Websphere MQ 7 empfohlene Publisher/Subscriber-Prinzip zur Konfiguration genutzt. Hier werden Themen als Publisher genutzt. Beliebige Subscriber können diese Themen dann über Warteschlangen abonnieren. Unterhalb des Warteschlangenmanagers QMA werden zunächst zwei lokale Warteschlagen FS_IN und BUS_OUT eingerichtet.

Abbildung 12. MQ Explorer Warteschlangen

Anschließend werden zwei Themen zum Publizieren von Nachrichten aus FirstSpirit (FS_OUT) und zum Pushen von Nachrichten aus dem Live-System (BUS_IN) auf dem Bus erstellt.

Abbildung 13. MQ Explorer Themen

Dann werden zwei Subskriptionen angelegt:

Abbildung 14. MQ Explorer Subskriptionen

Unterhalb des Warteschlangenmanagers QMA wurde unter Kanäle ein Serververbindungskanal mit dem Namen SRVCONN (Einstellungen: Default) eingerichtet.

Abbildung 15. MQ Explorer Kanäle

Sollte unter Datensätze der Kanalauthentifizierung eine Sperrung aller Benutzer hinterlegt sein, so muss diese entfernt werden.

Das Modul uxbridge-module-x.x.x.fsm wird nach Anleitung installiert und Alle Rechte gesetzt.

Um die UX-Bridge mit IBM Websphere MQ nutzen zu können, ist es noch notwendig, die Dateien jms.jar und com.ibm.mq.allclient.jar in das Verzeichnis FS_ROOT → shared → lib des FirstSpirit-Servers zu kopieren. Die Dateien sind Teil der WebSphere MQ classes for Java, die sie passend für Ihre Websphere-Version von der IBM Fix Central bekommen können (https://www.ibm.com/support/fixcentral/).

Der UXB-Service wird wie folgt konfiguriert:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jms="http://www.springframework.org/schema/jms" xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd        http://camel.apache.org/schema/spring        http://camel.apache.org/schema/spring/camel-spring.xsd http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms-3.0.xsd">
  <bean id="webphere-mq-topic" class="org.apache.camel.component.jms.JmsComponent">
    <property name="connectionFactory" ref="websphere-mq-usercredentials-connection-proxy-topic"/>
  </bean>

 <bean id="webphere-mq" class="org.apache.camel.component.jms.JmsComponent">
    <property name="connectionFactory" ref="websphere-mq-usercredentials-connection-proxy"/>
  </bean>

<bean id="websphere-mq-connection-topic" class="com.ibm.mq.jms.MQTopicConnectionFactory">
                     <property name="transportType" value="1"/>
                    <property name="hostName" value="<hostname>"/>
                    <property name="port" value="1414"/>
                    <property name="queueManager" value="QMA"/>
<property name="channel" value="SRVCONN"/>
  </bean>

<bean id="websphere-mq-connection" class="com.ibm.mq.jms.MQConnectionFactory">
                     <property name="transportType" value="1"/>
                    <property name="hostName" value="<hostname>"/>
                    <property name="port" value="1414"/>
                    <property name="queueManager" value="QMA"/>
<property name="channel" value="SRVCONN"/>
  </bean>

<bean id="websphere-mq-usercredentials-connection-proxy-topic" class="org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter">
   <property name="targetConnectionFactory" ref="websphere-mq-connection-topic"/>
   <property name="username" value="<username>"/>
   <property name="password" value="<password>"/>
 </bean>

<bean id="websphere-mq-usercredentials-connection-proxy" class="org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter">
   <property name="targetConnectionFactory" ref="websphere-mq-connection"/>
   <property name="username" value="<username>"/>
   <property name="password" value="<password>"/>
 </bean>

  <camelContext xmlns="http://camel.apache.org/schema/spring" id="camelContext" trace="false">
    <package>com.espirit.moddev.uxbridge.service</package>
    <template id="producerTemplate" />
    <endpoint id="FS-Out" uri="webphere-mq-topic:topic:FS.BUS_IN" />
    <onException>
      <exception>java.lang.Exception</exception>
      <handled>
        <constant>true</constant>
      </handled>
      <process ref="uxbExceptionProcessor" />
    </onException>
    <route id="Adapter-Statistics-Response-Route">
      <from uri="webphere-mq:queue:FS_IN" />
      <convertBodyTo type="com.espirit.moddev.uxbridge.api.v1.service.UXBEntity" />
      <bean ref="UxbServiceStatisticsResponseHandler" method="print" />
    </route>
  </camelContext>
  <bean id="UxbServiceStatisticsResponseHandler" class="com.espirit.moddev.uxbridge.service.UxbServiceStatisticsResponseHandler">
    <constructor-arg ref="camelContext" />
  </bean>
  <bean id="uxbExceptionProcessor" class="com.espirit.moddev.uxbridge.inline.UxbExceptionProcessor" />
</beans>

Die Empfehlung für ein Update des UX-Busses ist zunächst eine parallele Installation des neuen UX-Busses. Dabei kann wie schon bei der ersten Installation vorgegangen werden. Nachdem die Installation abgeschlossen ist, ist es ratsam eventuelle Anpassungen an der Konfiguration von der bestehenden Installation zur neuen Installation zu kopieren. Ist dies abgeschlossen, kann der bestehende UX-Bus zunächst gestoppt werden und danach der neue UX-Bus gestartet werden. Läuft der UX-Bus als Windows-Dienst bzw. als Unix-Service, muss dieser ebenfalls angepasst werden. Details dazu sind hier zu finden: http://activemq.apache.org/run-broker.html.

Zunächst muss das Modul selber neu installiert werden. Das Vorgehen ist hier zunächst analog zum Update-Prozess des UX-Bridge Moduls aus Kapitel Update des UX-Bridge Moduls. Nach dem Neustart ist es notwendig die Web-Anwendung zu aktualisieren. Dazu muss in den Server-Eigenschaften das Modul ausgewählt und der Button Verwendung aktualisieren geklickt werden.

Abbildung 16. Verwendung aktualisieren

Im darauf folgendem Dialog erneut Aktualisieren klicken.

Abbildung 17. Aktualisieren