Enterprise Application
Integration
Teilleistung
Der Enterprise Service Bus in
Theorie und Praxis
Ulrich Biberger
Wintersemester 2007/2008
Inhaltsverzeichnis
I
Inhaltsverzeichnis
Abbildungsverzeichnis ...I I I
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 Versandt ransformat or
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.
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).
Abb. 5: Verzeichnis-
struktur ServiceMix
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"
?>
<
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 "j bi.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.
version
=
"1.0"
encoding
=
"UTF-8"
?>
Versandhaus Ulrich
Spende
34
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 "j bi.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 "j bi.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 "j bi.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 "j bi.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 "j bi.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
>
<
artifacts-zip
>
spitzi-abrechnung-su.zip
artifacts-zip
>
<
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
=
"
"encoding=\"UTF-8\" ?> "
+
+
"Versandhaus Ulrich "
+
"Spende "
+
"34 "
+
""
;
/**
*
@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
![Title: Enterprise Service Bus: Theory in Practice [With Quick-Ref Card]](http://content.grin.com/picture/1228357-ZtfaDZ0C9lSe4kud.jpeg)
0 comments