Enterprise Application

Integration

Teilleistung

Der Enterprise Service Bus in

Theorie und Praxis

Ulrich Biberger

Wintersemester 2007/2008

---

Inhaltsverzeichnis

I

Inhaltsverzeichnis

Abbildungsverzeichnis III

1

Der Enterprise Service Bus 1

1.1 Das Konzept des Enterprise Service Bus 1

1.2 Aufgaben eines Enterprise Service Bus 1

1.3 Probleme und Nachteile der Kopplung über ESB 2

2

ESB am Beispiel ServiceMix 4

2.1 Die Software ServiceMix 4

2.2 Das Beispielszenario 5

2.3 Die Realisierung 7

2.3.1 Generelles Vorgehen 7

2.3.2 Die Fileschnittstelle 7

2.3.3 Die JMS Schnittstelle 8

2.3.4 Der Distributor 8

2.3.5 Der Abrechnungsservice 8

2.3.6 Der Versandtransformator 9

2.3.7 Erstellen einer Service Assembly und Installation 9

2.3.8 Aufrufen der neu installierten Dienste 9

3

Fazit 10

4

Anhang 11

4.1 Installation von ServiceMix 11

4.2 Konfiguration: Service Unit File 12

4.2.1 Verzeichnisaufbau und ­inhalt 12

4.2.2 Konfigurationsdatei ,,xbean.xml": 12

4.2.3 Konfigurationsdatei "jbi.xml" 12

4.2.4 Beispieldatei 13

4.3 Konfiguration: Service Unit JMS 13

4.3.1 Verzeichnisaufbau und ­inhalt 13

4.3.2 Konfigurationsdatei ,,xbean.xml" 13

4.3.3 Konfigurationsdatei "jbi.xml" 13

4.4 Konfiguration: Distributor 14

4.4.1 Verzeichnisaufbau und ­inhalt 14

4.4.2 Konfigurationsdatei ,,xbean.xml" 14

4.4.3 Konfigurationsdatei "jbi.xml" 14

4.5 Konfiguration: Abrechnungsservice 15

---

Inhaltsverzeichnis

II

4.5.1 Verzeichnisaufbau und ­inhalt 15

4.5.2 Konfigurationsdatei ,,xbean.xml" 15

4.5.3 Konfigurationsdatei "jbi.xml" 15

4.5.4 Java Klasse "AbrechnungPojo.java" 16

4.6 Konfiguration: Versandtransformation 16

4.6.1 Verzeichnisaufbau und ­inhalt 16

4.6.2 Konfigurationsdatei ,,xbean.xml" 16

4.6.3 Konfigurationsdatei "jbi.xml" 17

4.6.4 Stylesheet ,,transform.xsl" 17

4.7 Konfiguration: Service Assembly 18

4.7.1 Verzeichnisaufbau und ­inhalt 18

4.7.2 Konfigurationsdatei "jbi.xml" 18

4.8 Der JMS Client 19

Literaturverzeichnis 21

---

Abbildungsverzeichnis

III

Abbildungsverzeichnis

Abb. 1: Kommunikationsbus statt Punkt-zu-Punkt 1

Abb. 2: Aufbau einer JBI-Architektur 4

Abb. 3: Struktur des Beispielszenarios 6

Abb. 4: Aufbau des Distributors 8

Abb. 5: Verzeichnisstruktur ServiceMix 1

Abb. 6: Aufbau der Service Unit spitzi-file-su 12

Abb. 7: Aufbau der Service Unit spitzi-abrechnung-su 15

Abb. 8: Aufbau der Service Unit spitzi-transformer-su 16

Abb. 9: Aufbau der Service Assembly 18

---

1

1 Der Enterprise Service Bus

1.1 Das Konzept des Enterprise Service Bus

Moderne IT Infrastrukturen zeichnen sich heutzutage nicht zuletzt durch ihre

hohe Heterogenität aus. Häufig handelt es sich um gewachsene Strukturen, die

verstärkt über öffentliche oder herstellerspezifische Protokolle miteinander ver-

knüpft werden. Diese Integrationsaktivitäten machen nicht an Unternehmens-

grenzen halt sondern greifen auch nach den Systemen der Kunden und Lieferan-

ten, immer mit dem Ziel Prozesse weiter zu automatisieren und zu verbessern.

Tragische Folge: Es entsteht ein Kommunikationswirrwarr, in dem keiner mehr

genau abschätzen kann, welches System mit welchem kommuniziert und welche

Folgen eine Änderung in diesem fragilen Kommunikationsgefüge nach sich zieht.

Letztlich manövriert sich das Unternehmen selbst in eine Position, in der es die

heutzutage notwendige Flexibilität bezüglich der unternehmerischen Prozeß-

gestaltung oftmals nur mit großen zeitlichen und finanziellen Mühen erbringen

kann.

Hier setzt die Idee des ESB (Enterprise Service Bus) an (Abb. 1). Anstelle eines

Kommunikationsnetzes mit individuellen Austauschprotokollen tritt ein genereller

Kommunikationsbus. Dieser Bus transportiert als Mittler Nachrichten vom Sender

zum Empfänger und sorgt gleichzeitig für eine lose Kopplung der beiden.

Abb. 1: Kommunikationsbus statt Punkt-zu-Punkt

Quelle: In Anlehnung an [JBI2005]

1.2 Aufgaben eines Enterprise Service Bus

Bezüglich der konkreten Aufgaben eines ESB unterscheiden sich die Vorstellun-

gen der Softwareanbieter - nicht zuletzt aufgrund der Funktionalitäten der eige-

---

2

nen Produktpalette. Allerdings sind folgende wesentliche Elemente des Busses in

allen Beschreibungen anzutreffen (siehe [IBMSOA2004] S.84ff, [PTRSOA2004]

S.187ff):

Transformation:

Über Nachrichtentransformation kann der ESB verschiedene

Formate unterstützen indem Nachrichten bei Bedarf in ihrer Struktur oder ihrem

Inhalt verändert werden.

Routing:

Die Kernaufgabe des ESB ist das Routing, das Weiterleiten von Nach-

richten von einer Quelle (Service Consumer) zu dem gewünschten Serviceanbie-

ter (Service Provider). Dabei sollte der Bus auch abhängig vom Nachrichteninhalt

einen Serviceanbieter ermitteln können (content-based routing).

Nachrichtenbasierte Kommunikation:

Der Bus kann synchrone und asyn-

chrone Dienste ansprechen und besitzt die Möglichkeit, Nachrichten nach dem

Publish/Subscribe Prinzip von einem Sender an viele Empfängern zu senden.

Sicherheit:

Hierzu gehören die Identifizierung des Aufrufers (Authentifizierung),

die Prüfung der Rechte des Aufrufers (Autorisierung) sowie die Möglichkeit zur

Verschlüsselung der Kommunikationskanäle.

Zusätzlich zu den oben genannten Elementen erwartet man eine Vielzahl von

verfügbaren Komponenten, mit denen bestehenden Dienste an den ESB gebun-

den werden können (Ftp, Http, Webservice usw.) sowie die Möglichkeit, gegebe-

nenfalls eigene Komponenten zu entwickeln.

1.3 Probleme und Nachteile der Kopplung über ESB

Den unbestreitbaren Vorteilen eines ESB bei der Verknüpfung von Applikations-

systemen stehen auch Nachteile gegenüber.

So verursacht der Einsatz eines ESB bei jedem Nachrichtenaustausch zwischen

zwei Systemen eine zweimalige Konvertierung von und zu einem einheitlichen

Nachrichtenformat. Dies verursacht einen signifikanten Zusatzaufwand, der bei

einer hohen Anzahl auszutauschender Nachrichten zwischen zwei Systemen zu

einer deutlichen Verlangsamung der Bearbeitung führen kann.

Auch verliert man durch den Einsatz von Nachrichten in der Regel eine übergrei-

fende Transaktion. Kommt es zu einem Zurücksetzen in der zugehörigen Ge-

schäftsoperation werden nicht automatisch die Änderungen in dem oder den an-

deren Systemen zurückgesetzt. Häufig sieht man als Lösung den Ansatz von

Kompensationsbuchungen. Dieser Ansatz hat jedoch den Nachteil, daß einerseits

die Behandlung eines Rollback nicht implizit aus Sicht der beteiligten Applikatio-

---

3

nen stattfindet und andererseits ein möglicher Ausfall von Systemen Kompensa-

tionsbuchungen verhindern kann ­ wodurch die Applikation in der Verantwortung

ist, entsprechende Schritte einzuleiten (beispielsweise den Anwender zu infor-

mieren).

Auch ist ein ESB ist eigenständiges Stück Software, in der Regel installiert auf

einer eigenen Hardware. Für die Konfiguration und den Betrieb des ESB ist zu-

sätzliches Wissen erforderlich. Dies ist zunächst eine nicht unerhebliche Investi-

tion die sich nicht nach dem ersten erfolgreichen ESB Projekt bezahlt machen

wird. Somit ist die Einführung eines ESB nicht im Kontext eines Projektes zu se-

hen ist sondern gesamthaft im Unternehmen zu planen und umzusetzen.

Letztlich gilt also auch hier analog zu allen anderen Technologien und Konzep-

ten: je nach Fall ist abzuwägen, ob und wie stark ein ESB im Rahmen eines Pro-

jektes Sinn macht.

---

4

2 ESB am Beispiel ServiceMix

Die im ersten Kapitel dargestellten theoretischen Konzepte eines Enterprise Ser-

vice Bus werden in diesem Kapitel anhand der frei verfügbaren Software ,,Servi-

ceMix" aufgezeigt.

2.1 Die Software ServiceMix

ServiceMix ist ein mit Java entwickelter opensource ESB unter der Apache Lizenz

(siehe [SMIX]). Bis zum jetzigen Zeitpunkt findet man in der Literatur noch keine

allgemein gültige Spezifikation eines Enterprise Service Bus. Allerdings wurde

innerhalb der Java Community unter dem JSR (Java Specification Request) 208

mit der JBI (Java Business Integration, siehe [JBI2005]) ein Standard für die

Integration von Komponenten spezifiziert, welcher von ServiceMix auch als Basis

für deren ESB Implementierung verwendet wird.

Folgende Grafik (Abb. 2) veranschaulicht die Architektur der JBI. Komponenten

werden in einem JBI konformen Container wie beispielsweise ServiceMix instal-

liert und sind ab dann in der Lage nachrichtenorientiert miteinander zu kommu-

nizieren.

Abb. 2: Aufbau einer JBI-Architektur

Quelle: In Anlehnung an [JBI2005]

Das Herzstück der Architektur ist der NMR (Normalized Message Router). Dabei

handelt es sich um einen Softwarebus, der einen Nachrichtenaustausch zwischen

---

5

einem Service Provider und einem Service Consumer ermöglicht. Die grünen und

lila markierten Rechtecke repräsentieren die Komponenten, die über einen Deli-

very Channel mit dem NMR verbunden sind. Die Komponenten können als Provi-

der und/oder Consumer agieren. Komponenten, die ihre Dienste nur innerhalb

der JBI Umgebung ausführen, werden ,,Service Engine" genannt. Komponenten,

die Dienste über ein irgendwie geartetes Kommunikationsprotokoll aufrufen oder

anbieten werden als ,,Binding Component" bezeichnet. Die Interaktion der Kom-

ponenten wird technisch auf Basis der WSDL 2.0 (Web Service Description Lan-

guage) realisiert: der Serviceprovider publiziert den angebotenen Dienst in Form

eines WSDL Dokuments, welches alle Informationen enthält, die ein Service

Consumer für den Aufruf des Dienstes nach dem Find-Bind-Execute Prinzip benö-

tigt.

Die JBI bietet aktuell den besten standardisierten Ansatz um Prozesse durch

Komposition von Diensten zu erstellen. Sie hilft einmal entwickelte JBI-konforme

Services in ESB Implementierungen unterschiedlicher Hersteller zu nutzen.

2.2 Das Beispielszenario

Zur Demonstration betrachten wir folgendes Beispielszenario: Der Bleistifther-

steller ,,Spitzi AG" führt zur Weihnachtszeit regelmäßig werbewirksame Spenden-

sammelaktionen durch. Hierzu wird dieses Jahr eine neue Art von Spendenservi-

ce eingerichtet: Großhändler können ihre Spenden über eine B2B Verbindung

direkt in das System der ,,Spitzi AG" einspeisen. Jede dieser Spenden führt zum

Versand einer Quittung. Eine Anforderungsanalyse ergab, daß kleinere Händler

selten die technische Möglichkeit haben, eine B2B Integration wie oben zu reali-

sieren. Daher entschloß sich die ,,Spitzi AG" dazu, den Service auch auf Basis von

Dateiaustausch verfügbar zu machen.

Zur Realisierung dieses Prozesses entschieden sich die IT Architekten der ,,Spitzi

AG" für eine serviceorientierte Herangehensweise, dessen Herzstück die ESB

Implementierung ServiceMix darstellt. Dabei müssen die bestehenden Dienste

zur Abrechnung und zum Versand der Quittung genutzt werden, schließlich hat

die Firma viel Geld in die Entwicklung dieser Systeme gesteckt.

---

6

Abb. 3: Struktur des Beispielszenarios

Quelle: In Anlehnung an [JBI2005]

In der ESB/JBI Terminologie werden folgende Aktivitäten durchgeführt (Abb. 3):

Eine Business Component vom Typ JMS Consumer wird eine Eingangsqueue ü-

berwachen und dort eintreffende XML-Nachrichten über den NMR an den Service

,,Distributor" weiterleiten. Der Distributor schickt die Nachricht an die Applikation

,,Abrechnung", wofür eine gleichnamige Business Component eingerichtet wird.

Wir simulieren die Abrechnungsapplikation als einfache Java-Klasse, auf die die

Business Component über Webservice zugreift. Der Distributor schickt die Nach-

richt auch an den Versandservice, der in unserem Beispiel die Quittung nach ei-

ner Transformation in eine Datei schreibt. Neben dem Eingang über JMS bietet

das Szenario auch einen alternativen Einstieg über eine Dateischnittstelle. Einzi-

ger Unterschied ist das Einlesen der Eingangsdaten über einen Filepoller, die

weitere Verarbeitung bleibt dieselbe.

---

7

2.3 Die Realisierung

Essentiell für die Realisierung ist die korrekte Verwendung des ESB im Hinblick

auf seine Aufgaben. Als Infrastrukturkomponente ist es

nicht

zweckmäßig, Ap-

plikationslogik direkt im ESB Container zu installieren (beispielsweise indem eine

Business Component mit fachlichem Inhalt programmiert wird). Stattdessen soll

externe Applikationslogik über Komponenten an den Bus gebunden werden. Da-

her wird man nur selten selbst JBI Komponenten implementieren zu müssen. Ein

mögliches Szenario für eine eigenentwickelte Komponente wäre die Implemen-

tierung eines proprietären Transportprotokolls für ein bereits vorhandenes An-

wendungssystem. Üblicherweise besteht die Hauptaufgabe des Applikationsent-

wicklers darin, die JBI Komponenten geeignet zu konfigurieren.

2.3.1

Generelles Vorgehen

Die sehr einfache Installation von Service Mix ist im Anhang beschrieben (siehe

4.1).

Service Mix nimmt die Konfiguration für Komponenten als sogenannte Service

Units in Form von zip-Dateien entgegen. Diese werden im Folgenden zunächst

beschrieben, wobei auszugsweise auf deren Konfiguration eingegangen wird. Die

vollständige Konfiguration ist jeweils im Anhang zu finden. Im nächsten Schritt

werden die Service Units in einem Service Assembly Paket verpackt (wiederum

als zip Datei) und im ServiceMix Container installiert. Daraufhin können die in-

stallierten Dienste des Szenarios aufgerufen werden­ sowohl über JMS als auch

über File.

2.3.2

Die Fileschnittstelle

Die Service Unit ,,spitzi-file-su" beinhaltet die Konfigurationen aller Dienste des

Beispielszenarios, welche auf der Komponente ServiceMix-File aufsetzen. Dies

sind der Filepoller für das Einlesen der Eingangsdateien sowie der Versandservice

für das Schreiben der Quittungen. Jede Service Unit besteht zumindest aus den

beiden Dateien jbi.xml und xbean.xml, wobei erstere den Dienst benennt und ihn

mit der Rolle Consumer oder Provider versieht und die letztere komponenten-

spezifische Konfigurationseinstellungen erlaubt.

Die xbean.xml enthält die Konfiguration der beiden Endpunkte Filepoller und

Versandservice. Während der Filepoller eingehende Dateien an ein konfiguriertes

Ziel weiterleitet (hinterlegt als targetService und targetEndpoint), stellt der Ver-

sandservice aus Sicht des NMR eine Senke dar, dessen Verarbeitung mit dem

Schreiben der Datei in das Verzeichnis ,d:\projekte\tmp\versand` endet. In der

---

8

jbi.xml ist hinterlegt, dass es sich bei dem Dienst Versandservice um einen

Dienstanbieter (Provider) und bei Filepoller um einen Dienstnutzer (Consumer)

handelt (siehe Anhang 4.2).

2.3.3

Die JMS Schnittstelle

In ,,spitzi-jmsconsumer-su" wird die Konfiguration für die Überwachung der JMS

Eingangsqueue hinterlegt. Im Wesentlichen sind das der Queuename und die

Connection Factory als Parameter für die Verbindung mit der Queue sowie Ziel-

service und Endpoint, an die die eintreffenden Nachrichten per NMR geschickt

werden (siehe Anhang 4.3).

2.3.4

Der Distributor

Die Konfiguration für den Distributor enthält ,,spitzi-distributor-su". Service Mix

bietet unter dem Namen ,,servicemix-eip" eine Komponente an, in der verschie-

dene Routing-Mechanismen implementiert sind. Per Konfiguration definieren wir

eine ,,recipient list", eine Menge von Empfängern für die eingehende Nachricht

(nämlich Abrechnung und Versand). Da vor dem Versand eine Transformation

stattfindet wird für den Versandpfad eine Pipeline konfiguriert (Abb. 4).

Abb. 4: Aufbau des Distributors

Quelle: Eigene Darstellung

Die dafür notwendige Konfiguration ist im Anhang enthalten (siehe 4.4).

2.3.5

Der Abrechnungsservice

Die Konfiguration des Abrechnungsservice liegt in ,,spitzi-abrechnung-su". Die

Abrechnung wurde im Besipielszenario als einfache Javaklasse (POJO, Plaing old

java object) implementiert. Die Klasse als .class Datei ist Teil der Service Unit.

---

9

Die Anbindung der Klasse erledigt die Service Mix Komponente ,,servicemix-

jsr181". Sie erstellt dynamisch einen Webservice und macht so die public-

Methoden der Abrechnungsklasse als Dienst dem NMR verfügbar. Die Konfigura-

tion der jsr181 Komponente kann im Anhang eingesehen werden (siehe 4.5).

2.3.6

Der Versandtransformator

In ,,spitzi-transformer-su" liegt die Konfiguration für die Transformation vor dem

Aufruf des Versandservice. Die zuständige Service Mix Komponente ist ,,service-

mix-saxxon". Ihr kann ein Stylesheet mitgegeben werden, welches die Regeln

der Transformation enthält. Wie erwartet enthält die Konfiguration der Kompo-

nente in der Datei xbean.xml insbesondere den Namen des zu verwendenden

Stylesheets (siehe 4.6).

2.3.7

Erstellen einer Service Assembly und Installation

Die Service Assembly beinhaltet neben allen zuvor als zip-Archive erstellten Ser-

vice Units auch eine Konfigurationsdatei ,,jbi.xml". Dort ist hinterlegt für welche

Komponenten jede einzelne zip-Datei eine Konfiguration beinhalten (siehe 4.7).

Das Service Assembly Paket wird dem ServiceMix JBI Container bekannt ge-

macht indem es in das Verzeichnis /hotdeply kopiert wird. Service Mix erkennt

zur Laufzeit, daß neue Konfigurationen eingestellt wurden und aktualisiert sich

daraufhin entsprechend.

2.3.8

Aufrufen der neu installierten Dienste

Die Überprüfung des JMS Eingangs in unser Beispielszenario erfolgt durch die

Implementierung eines einfachen JMS Clients (siehe Anhang 4.8). Dieser legt

eine Nachricht in die Queue, die von der JMS Business Component aufgrund der

Konfiguration in ,,spitzi-jms-su" überwacht wird. Die Verarbeitung der Nachricht

erkennt man an den Ausgaben der Konsole des ESB sowie am Schreiben der

Quittungsdatei in das erwartete Ausgabeverzeichnis ,,d:/spitzi/versand".

Die Dateischnittstelle kann geprüft werden indem eine xml-Datei in das von

,,spitzi-file-su" überwachte Verzeichnis gelegt wird. Eine gültige Beispieldatei fin-

det sich im Anhang (siehe 4.2.4). Auch hier kann man die weitere Verarbeitung

über Konsole bzw. Ausgangsverzeichnis für Quittungen beobachten.

---

10

3 Fazit

Der ESB Ansatz ist eine vielversprechende Herangehensweise zur Strukturierung

von Kommunikationskanälen zwischen Anwendungssystemen. Service Mix als

Software zeigt, wie das Ganze in der Praxis aussehen kann.

Noch erkennt man an Service Mix deutlich sein junges Alter: Dokumentation und

Fehlermeldungen sind teilweise schwer zu verstehen, Beispiele nicht immer

nachzuvollziehen. Aufgrund dieser Hürden benötigte auch das oben aufgeführte

Beispielszenario einen unerwartet hohen Zeitaufwand zur Umsetzung. Sind diese

Klippen aber gemeistert ist das Gesamtbild einer möglichen unternehmensweiten

Lösung sehr gut erkennbar und zukunftsweisend. Das Zusammenspiel mit JBI als

Standardisierungsversuch läßt zudem hoffen, daß austauschbare und wiederver-

wendbare Komponenten künftige Integrationsaufwände geringer halten und ei-

nen echten Mehrwert für Unternehmen liefern

---

11

4 Anhang

4.1 Installation von ServiceMix

ServiceMix steht als zip-Datei auf der Website http://servicemix.apache.org zum

Download bereit. Hierbei kann zwischen einer Standalone und einem Web Archi-

ve für den Betrieb innerhalb eines Applicationservers gewählt werden. Zur Reali-

sierung des Beispielszenarios reicht die Standalone Variante aus. Die zip-Datei

wird in ein Verzeichnis entpackt und zeigt sich dann die in Abb. 5 dargestellte

Struktur.

Das /bin Verzeichnis enthält die Skripte für das Starten und

Stoppen des ESB. Im Verzeichnis /hotdeploy können Dienste

während des Betriebs an den ESB gehängt oder auch wieder

entfernt werden. Dies geschieht durch einfaches Kopieren bzw.

Löschen der entsprechenden zip Datei.

Im /conf Verzeichnis liegen alle Konfigurationsdateien des

ESB, darunter auch die für die Messaging Plattform und für die

Security-Einstellungen.

Abb. 5: Verzeichnis-

struktur ServiceMix

Die Skripte von ServiceMix beziehen sich auf die Umgebungsvariable

%SERVICEMIX_HOME%, die für die weiteren Schritte in der Umgebung zu set-

zen ist. %SERVICEMIX_HOME% muß auf das Installationsverzeichnis von Servi-

ceMix zeigen. Nach Setzen dieser Variable kann der ESB bereits gestartet wer-

den. Hierzu wechselt man in das Installationsverzeichnis und führt das Skript

,,servicemix.bat" im \bin Verzeichnis aus.

D:\ apache-servicemix-3.2> bin\servicemix

ServiceMix initialisiert eine Reihe von Komponenten und steht dann zur Bearbei-

tung von Nachrichten zur Verfügung (das Command-Fenster in Windows darf

nicht geschlossen werden).

---

12

4.2 Konfiguration: Service Unit File

4.2.1

Verzeichnisaufbau und ­inhalt

Die Service Unit besteht aus den beiden Dateien jbi.xml und xbean.xml, die wie

in unten dargestellter Abbildung (Abb. 6) in einer zip-Datei zusammenzufassen

sind.

Abb. 6: Aufbau der Service Unit spitzi-file-su

4.2.2

Konfigurationsdatei ,,xbean.xml":

Die Datei xbean.xml enthält die komponentenspezifischen Konfigurationseinstel-

lungen der beiden Dienste Filepoller und Versandservice.

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

<!-- BUG detected: Source/Target must be same

drive as servicemix installation-->

<beans xmlns:file="http://servicemix.apache.org/file/1.0"

xmlns:spitzi="http://spitzi.org/services">

<file:sender service="spitzi:VersandService"

endpoint="sender"

directory="file://d:/spitzi/versand" />

<file:poller service="spitzi:FilePollerService"

endpoint="poller"

file="file://d:/spitzi/incoming/"

targetService="spitzi:DistributorService"

targetEndpoint="endpoint" />

</beans>

4.2.3

Konfigurationsdatei "jbi.xml"

Die jbi.xml legt fest, welche konkreten Dienste diese Service Unit konfiguriert

und ob diese Dienste in der Rolle eines Providers oder eines Consumers agieren.

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

<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">

<services binding-component="true"

xmlns:spitzi="http://spitzi.org/services">

<provides service-name="spitzi:VersandService"/>

<consumes service-name="spitzi:FilePollerService"/>

</services>

</jbi>

---

13

4.2.4

Beispieldatei

Wird folgende Beispieldatei in das Verzeichnis ,,d:/spitzi/incoming" abgelegt, so

beginnt die autoamtische Verarbeitung.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<abrechnen>

<kunde>Versandhaus Ulrich</kunde>

<zweck>Spende</zweck>

<betrag>34</betrag>

</abrechnen>

4.3 Konfiguration: Service Unit JMS

4.3.1

Verzeichnisaufbau und ­inhalt

Die Service Unit besteht analog der unter 4.2 beschriebenen Service Unit aus

den beiden Dateien jbi.xml und xbean.xml.

4.3.2

Konfigurationsdatei ,,xbean.xml"

Die Datei xbean.xml enthält die komponentenspezifischen Konfigurationseinstel-

lungen des Dienstes zur Überwachung der Eingangsqueue ,,incomingQueue".

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

<beans xmlns:jms="http://servicemix.apache.org/jms/1.0"

xmlns:spitzi="http://spitzi.org/services">

<bean id="connectionFactory"

class="org.apache.activemq.ActiveMQConnectionFactory">

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

</bean>

<jms:endpoint service="spitzi:JMSConsumerService"

endpoint="jmsConsumer"

role="consumer"

soap="false"

targetService="spitzi:DistributorService"

defaultMep="http://www.w3.org/2004/08/wsdl/in-only"

destinationStyle="queue"

jmsProviderDestinationName="queue/incomingQueue"

connectionFactory="#connectionFactory" />

</beans>

4.3.3

Konfigurationsdatei "jbi.xml"

Die jbi.xml nennt ,,JMSConsumerService" als einzigen Service dieser Service Unit

und definiert diesen als Consumer.

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

<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">

<services binding-component="true"

xmlns:spitzi="http://spitzi.org/services">

---

14

<consumes service-name="spitzi:JMSConsumerService"/>

</services>

</jbi>

4.4 Konfiguration: Distributor

4.4.1

Verzeichnisaufbau und ­inhalt

Die Service Unit besteht analog der unter 4.2 beschriebenen Service Unit aus

den beiden Dateien jbi.xml und xbean.xml.

4.4.2

Konfigurationsdatei ,,xbean.xml"

In der Datei ,,xbean.xml" wird die servicemix-eip Komponente konfiguriert. Diese

Komponente ist ein Container mit einer Vielzahl an Routing Mechanismen. Für

das Beispielszenario werden die beiden Typen ,,Recipient List" und ,,Pipeline"

verwendet.

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

<beans xmlns:eip="http://servicemix.apache.org/eip/1.0"

xmlns:spitzi="http://spitzi.org/services">

<eip:static-recipient-list service="spitzi:DistributorService"

endpoint="endpoint">

<eip:recipients>

<eip:exchange-target service="spitzi:PipelineService" />

<eip:exchange-target service="spitzi:AbrechnungService" />

</eip:recipients>

</eip:static-recipient-list>

<eip:pipeline service="spitzi:PipelineService" endpoint="endpoint">

<eip:transformer>

<eip:exchange-target service="spitzi:TransformationService" />

</eip:transformer>

<eip:target>

<eip:exchange-target service="spitzi:VersandService" />

</eip:target>

</eip:pipeline>

</beans>

4.4.3

Konfigurationsdatei "jbi.xml"

Die jbi.xml nennt ,,JMSDistirbutorService" und legt fest, daß dieser Service in der

Rolle ,,Provider" agiert.

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

<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">

<services binding-component="true"

xmlns:spitzi="http://spitzi.org/services">

<provides service-name="spitzi:DistributorService"/>

</services>

</jbi>

---

15

4.5 Konfiguration: Abrechnungsservice

4.5.1

Verzeichnisaufbau und ­inhalt

Neben den beiden Dateien xbean.xml und jbi.xml enthält diese Service Unit auch

die POJO Implementierung des Abrechnungsservice (Abb. 7).

Abb. 7: Aufbau der Service Unit spitzi-abrechnung-su

4.5.2

Konfigurationsdatei ,,xbean.xml"

Die Datei xbean.xml erweitert die Java Klasse ,,AbrechnungPojo" dynamisch nach

dem Proxy-Prinzip um Webservice Funktionalitäten. Mit dem in ServiceMix ent-

haltenen Framework XFire werden XML Nachrichten auf die entsprechenden Me-

thoden der Javaklasse abgebildet. Auch Annotationen innerhalb der Javaklasse

gemäß dem JSR 181 sind möglich.

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

<beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0"

xmlns:spitzi="http://spitzi.org/services">

<jsr181:endpoint annotations="none"

service="spitzi:AbrechnungService"

<jsr181:pojo>

<bean class="com.spitzi.AbrechnungPojo"></bean>

</jsr181:pojo>

</jsr181:endpoint>

</beans>

4.5.3

Konfigurationsdatei "jbi.xml"

Die jbi.xml definiert ,,AbrechnungService" als in dieser Service Unit konfigurier-

ten Service Provider.

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

<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">

<services binding-component="false"

xmlns:spitzi="http://spitzi.org/services">

<provides service-name="spitzi:AbrechnungService"/>

</services>

</jbi>

---

16

4.5.4

Java Klasse "AbrechnungPojo.java"

Die bewußt sehr einfach gehaltene Klasse AbrechnungPojo gibt eingehende

Nachrichten auf Konsole aus.

package

com.spitzi;

public

class

AbrechnungPojo {

public

void

abrechnen(String kunde, String zweck, String betrag){

//

TODO

: add value-adding code here...

System.out.println(betrag+" Euro Abrechnung ["+zweck+

"] von "+kunde);

}

}

4.6 Konfiguration: Versandtransformation

4.6.1

Verzeichnisaufbau und ­inhalt

Neben den beiden obligatorischen Dateien xbean.xml und jbi.xml enthält diese

Service Unit ein Stylesheet zur Transformation eingehender Nachrichten (Abb.

8).

Abb. 8: Aufbau der Service Unit spitzi-transformer-su

4.6.2

Konfigurationsdatei ,,xbean.xml"

Die xbean.xml legt das Stylesheet fest, mit dem die Transformation durchgeführt

wird.

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

<beans xmlns:sm="http://servicemix.apache.org/config/1.0"

xmlns:saxon="http://servicemix.apache.org/saxon/1.0"

xmlns:spitzi="http://spitzi.org/services">

<saxon:xslt service="spitzi:TransformationService"

endpoint="endpoint"

result="string"

resource="classpath:transform.xsl" />

</beans>

---

17

4.6.3

Konfigurationsdatei "jbi.xml"

TransformationService wird hier als Service Provider definiert, da er seine Trans-

formation als Dienst den Clients zur Verfügung stellt.

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

<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">

<services binding-component="false"

xmlns:spitzi="http://spitzi.org/services">

<provides service-name="spitzi:TransformationService"

endpoint-name="endpoint"/>

</services>

</jbi>

4.6.4

Stylesheet ,,transform.xsl"

Folgendes einfach gehaltenes Stylesheet transformiert das eintreffende xml in

ein leicht abweichendes Format und ergänzt das Quittungsdatum.

<xsl:stylesheet version="2.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:date="http://exslt.org/dates-and-times"

>

<xsl:output method="xml" omit-xml-declaration="yes" indent="yes" />

<xsl:variable name="now" select="date:date-time()"/>

<xsl:template match="abrechnen">

<quittung>

<xsl:apply-templates select="//betrag"/>

<xsl:apply-templates select="//kunde"/>

</quittung>

</xsl:template>

<xsl:template match="betrag">

<betrag><xsl:value-of select="."/></betrag>

<quittungsdatum>

<xsl:value-of select="concat(date:day-in-month($now), ′ ′,

date:month-in-year($now), ′ ′,

date:year($now))"/>

<xsl:text> um </xsl:text>

<xsl:value-of select="concat(date:hour-in-day($now), ′:′,

date:minute-in-hour($now), ′:′,

date:second-in-minute($now))"/>

</quittungsdatum>

</xsl:template>

<xsl:template match="kunde">

<spender><xsl:value-of select="."/></spender>

</xsl:template>

</xsl:stylesheet>

---

18

4.7 Konfiguration: Service Assembly

4.7.1

Verzeichnisaufbau und ­inhalt

Die Service Assembly enthält als zip Datei alle Service Units des Beispielszenari-

os sowie eine jbi.xml in der diese Service Units den Service Mix Komponenten

zugeordnet werden (Abb. 99).

Abb. 9: Aufbau der Service Assembly

4.7.2

Konfigurationsdatei "jbi.xml"

Die jbi.xml listet alle enthaltenen Service Units auf und ordnet sie den zugehöri-

gen zip-Dateien und Service Mix Komponenten zu.

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

<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">

<service-assembly>

<identification>

<name>spitzi-sa</name>

<description>Spitzi Services-Paket</description>

</identification>

<service-unit>

<identification>

<name>spitzi-abrechnung-su</name>

<description>Abrechnung als POJO</description>

</identification>

<target>

<!-- Name der zip Datei -->

<artifacts-zip>spitzi-abrechnung-su.zip</artifacts-zip>

<!-- Name der Standard Servicemix Komponente-->

<component-name>servicemix-jsr181</component-name>

</target>

</service-unit>

<service-unit>

<identification>

<name>spitzi-file-su</name>

<description>biuFile Service Unit</description>

</identification>

<target>

<artifacts-zip>spitzi-file-su.zip</artifacts-zip>

<component-name>servicemix-file</component-name>

</target>

</service-unit>

<service-unit>

---

19

<identification>

<name>spitzi-distributor-su</name>

<description>Verteilt an Abrechnung u. Versand</description>

</identification>

<target>

<artifacts-zip>spitzi-distributor-su.zip</artifacts-zip>

<component-name>servicemix-eip</component-name>

</target>

</service-unit>

<service-unit>

<identification>

<name>spitzi-jmsconsumer-su</name>

<description>liest Queue</description>

</identification>

<target>

<artifacts-zip>spitzi-jmsconsumer-su.zip</artifacts-zip>

<component-name>servicemix-jms</component-name>

</target>

</service-unit>

<service-unit>

<identification>

<name>spitzi-transformation-su</name>

<description>Transformationen</description>

</identification>

<target>

<artifacts-zip>spitzi-transformer-su.zip</artifacts-zip>

<component-name>servicemix-saxon</component-name>

</target>

</service-unit>

</service-assembly>

</jbi>

4.8 Der JMS Client

Folgender Java Sourcecode realisiert eine einfache JMS Client Applikation, mit

dem eine Nachricht in die JMS-Queue des ServiceMix Beispiels gestellt werden

kann (in Anlehnung an [DOBBS2007]). Da ServiceMix intern ActiveMQ für den

Austausch von Nachrichten verwendet bietet es sich an, diesen Messagebroker

auch im Beispielszenario einzusetzen. Zur Übersetzung sind die Bibliotheken aus

ServiceMix/lib einzubinden.

package

com.biu.client;

import

javax.jms.Connection;

import

javax.jms.MessageProducer;

import

javax.jms.Session;

import

org.apache.activemq.ActiveMQConnectionFactory;

import

org.apache.activemq.command.ActiveMQQueue;

/**

* Beispielcode für einen JMS Client. Die Applikation

* erzeugt eine Textnachricht und stellt sie in eine

* Queue.

---

20

*/

public

final

class

JMSClient {

final

static

String

SERVERURL

="tcp://localhost:61616";

final

static

String

QUEUE_NAME

="queue/incomingQueue";

final

static

String

MESSAGE

= "<?xml version=\"1.0\" "+

"encoding=\"ISO-8859-1\" ?> "+

"<abrechnen> "+

"<kunde>Versandhaus Ulrich</kunde> "+

"<zweck>Spende</zweck> "+

"<betrag>34</betrag> "+

"</abrechnen>";

/**

*

@param

args Kommandozeilenparameter, nicht verwendet

*/

public

static

void

main(String[] args){

try

{

ActiveMQConnectionFactory factory

=

new

ActiveMQConnectionFactory(

SERVERURL

);

ActiveMQQueue myQueue =

new

ActiveMQQueue(

QUEUE_NAME

);

Connection c = factory.createConnection();

Session session=c.createSession(

false

,Session.

AUTO_ACKNOWLEDGE

);

MessageProducer mySender = session.createProducer(myQueue);

c.start();

mySender.send(session.createTextMessage(

MESSAGE

));

c.close(); //better in finally but unimportant in this example

}

catch

(Exception ex){

ex.printStackTrace();

}

} //end main

} //end class

---

Literaturverzeichnis

21

Literaturverzeichnis

IBMSOA2004 Keen, Martin: Patterns:

Implementing an SOA Using an Enter-

prise Service Bus

, IBM Redbooks, 2004.

PTRSOA2004 Krafzig, Dirk: Enterprise SOA ­ Service Oriented Architecture

Best Practice, Prentice Hall, 2004.

JBI2005

Ten-Hove, Ron; Walker, Peter: Java Business Integration (JBI)

1.0, Sun Microsystems Inc., Santa Clara, 2005.

SMIX

Apache ServiceMix Projekt: http://servicemix.apache.org

DOBBS2007

Dr Dobbs Journal: Defining the ESB, 2007

http://www.ddj.com/java/201200303

---