JBI: Ein Standard für den ESB

Im vorigen Artikel wurde über «Muster der Systemintegration» gesprochen. Als wesentliche Voraussetzung, um moderne und agile Enterprise-Anwendungen schreiben zu können, wird oft eine entsprechende Integrations­umge­bung angesehen, die es erlaubt, die Vielzahl an Services und Systemen, die zur Verfügung stehen, in kontrollierter Weise zu grösseren Anwendungen zu integrieren.


Dabei geistert das Schlagwort «Enterprise Service Bus» (ESB) als Begriff seit einigen Jahren durch die IT-Landschaft. Dieser Begriff wird allerdings in verschiedenen Kontexten verwendet:

- als Architektur-Paradigma

- als Implementierungs-Pattern

- als Komponente/Software-Produkt.


Häufig werden mit dem ESB-Begriff aber bestimmte Produkte verbunden. Es gibt nun eine grosse Anzahl von kommerziellen Anbietern wie Tibco, Sonic, IBM oder Microsoft, die ESB-Produkte im Programm haben, sowie eine ebenfalls erhebliche Anzahl an Open-Source-Projekten wie Codehaus Mule, Apache Service Mix oder OpenESB. Leider unterscheiden sich die Projekte und Produkte zum Teil erheblich, und es beginnt sich erst langsam ein gemeinsames Verständnis herauszukristallisieren, was ein ESB eigentlich leisten sollte.

Gemeinsam verbunden

Ein wesentlicher Aspekt ist die Verbindung verschiedener IT-Komponenten, wobei dies über eine grosse Anzahl an verschiedenen Protokollen möglich sein sollte (beispielsweise JMS, FTP, Files, RMI, Corba). Die Kommunikation zwischen den angebundenen Systemen sollte dabei über einen standardisierten Bus erfolgen, weshalb meist XML-basierte Nachrichten verwendet werden. Der Bus selbst soll auch komplexes Routing der Nachrichten sowie Transformationen (Konversionen, Anreicherungen usw.) unterstützen.


Neue Anwendungen, Services und Komponenten können dabei im ESB-Kontext geschrieben werden, ohne dass sich der Entwickler mit der Vielzahl an Systemen und Protokollen direkt auseinandersetzen muss. Diese Komponenten werden typischerweise vom ESB verwaltet (Lifecycle Management).

Weiter sollten verschiedenste Services (auch von Drittanbietern) ausführbar und für eigene Anwendungen verwendbar sein. Als Beispiel könnte man BPEL-Prozess-Engines, Regel-Prozessoren
(z.B. JBoss Drools) oder Apache Camel nennen. Dabei ist eine standardisierte Komponenten-
und Service-Schnittstelle natürlich wünschenswert.


Auch Administration und Überwachung der Systeme sind natürlich bei einer solchen Middleware-Komponente von grosser Bedeutung, ebenso wie die gute Integration mit anderen Middleware-Komponenten wie nachrichtenorientierter Middleware.
Zusätzliche Services wie Reliable Messaging, Transaktions-Unterstützung, Security-Funktionen sowie Service Registries werden ebenfalls oft gefordert.


Der ESB unterstützt also idealerweise den Entwickler von Geschäftsanwendungen, weil er sich nicht mehr um diese zum Teil recht komplexen Details kümmern muss, sondern mit der Applikationsentwicklung beziehungsweise Integration von Anwendungen auf einer abstrakteren Stufe beginnen kann.

Java Business Integration

Wie schon erwähnt, gibt es eine grosse Anzahl verschiedener ESB-Produkte. Dabei kocht(e) leider fast jeder Hersteller sein eigenes Süppchen, was zu Systemen führt, die nicht gut miteinander arbeiten. Konkret bedeutet dies beispielsweise mangelhafte Austauschbarkeit von Komponenten zwischen verschiedenen ESBs. Standards sind in diesem Umfeld aber sehr wichtig, wie man unter anderem an BPEL sehen kann.


Mittlerweile gibt es auch einen ersten Standard: Java Business Integration (JBI) von Sun Micro­systems, der als Java Specification Request entstanden ist (JSR-208). JBI ist ein recht leicht zu verstehender Standard und ist auch ein guter Startpunkt, um wesentliche Kern-ESB-Funktionalität zu definieren.

Der JBI-Standard beschreibt, wie Enterprise-Komponenten über einen Bus miteinander interagieren. Dabei wird ein Plugin-Framework definiert, über das beliebige Komponenten zur Laufzeit geladen oder entfernt werden können. Das Komponenten-Framework kümmert sich dabei um das Lifecycle-Management der Komponenten. Bei der Definition der JBI-Komponenten wird auf bestehende Webservice-Standards wie WSDL zurückgegriffen.


Eine weitere Kernfunktionalität ist der «Normalized Message Router». Dabei handelt es sich um eine ESB-Komponente, die Nachrichten von JBI-Komponenten übernimmt und in standardisierter Form (XML) an andere Kompo-
nenten weiterleitet (Routing, Mediation).


Das Management von JBI-Komponenten erfolgt über einen bekannten Java-Standard: JMX. Die Java Management Extension ist ein standardisierter Weg, wie beliebige Komponenten mit einer einheitlichen Oberfläche verwaltet und konfiguriert werden können. Es ist also nur ein JMX-fähiger Client notwendig, mit dem alle im JBI-Kontext laufenden Komponenten geladen, entfernt, konfiguriert sowie überwacht werden können.
JBI definiert also viele der wesentlichen Funktionalitäten, die man von einem ESB respektive von Komponenten, die auf einem ESB laufen, erwarten kann.




JBI-Konzept von Apache Service Mix

Apache Service Mix für JBI

JBI in der Version 1.0 ist mittlerweile etwa 2 Jahre alt, und es gibt bereits erste ESB-Implementierungen, beispielsweise die Open-Source-Lösung Apache Service Mix. Der Trend geht aber scheinbar sehr stark in diese Richtung, und andere ESBs ziehen nach. Auch existiert mittlerweile eine erhebliche Anzahl an JBI-kompatiblen Komponenten verschiedener Anbieter respektive von verschiedenen Open-Source-Projekten (siehe Kasten).
Die Abbildung auf der vorhergehenden Seite zeigt die Grund-Architektur eines JBI-konformen Enterprise Service Busses. Im «Zentrum» steht dabei der «Normalized Message Bus», im Fall von Apache Service Mix der «Service Mix ESB». Weiter beschreibt der JBI-Standard zwei Arten von Komponenten:



- Binding Components

- Service Components


Binding Components dienen der Kommunikation mit anderen Systemen. Wie in der Abbildung angedeutet zum Beispiel zu SOAP Services, zu Dateien oder JCA-Resourcen, aber auch zu JMS, RMI oder Corba.
Die Service-Komponenten bieten eine Anzahl an Services an, die am Bus direkt verwendet werden können (siehe Kasten). Diese Komponenten können unter anderem zur Prozess-Orchestrierung verwendet werden, zur Nachrichten-Transformation oder zur Regelbearbeitung. Auch das im letzten Artikel vorgestellte Apache Camel kann als JBI-Komponente in Service Mix verwendet werden. Damit können die Fähigkeiten von Camel in der Implementierung von Enterprise Integration Patterns auch innerhalb von Service Mix verwendet werden.


Zwar ist die Verwendung von WSDL etwas «schwergewichtig», aber immerhin wird hier ein bekannter Standard verwendet. Dies ist vermutlich auch der Grund, warum es bereits eine erhebliche Anzahl an JBI-Komponenten gibt. Im Service-Mix-Kontext gibt es ausserdem die Möglichkeit, «leichtgewichtige» POJOs (also einfache Java-Objekte) ohne WSDL-Beschreibung an den Bus zu hängen. Dies sind dann aber auch keine JBI-Komponenten mehr.

Fazit

Die Notwendigkeit, vereinheitlichte und standardisierte Integrationsumgebungen zu schaffen, wurde in den letzten Jahren offensichtlich. Eine Vielzahl von ESB-Produkten kam auf den Markt mit stark unterschiedlicher Funktionalität und Fokus. JBI ist einer der ersten Standards in diesem Umfeld und wird bereits vielfach umgesetzt. Einerseits gibt es mittlerweile eine nennenswerte Anzahl an (Open-Source-) JBI-Komponenten, andererseits beginnen langsam auch erste ESB-Implementierungen, die JBI-konform sind, zu reifen. Apache Service Mix ist eine solche Implementierung und mittlerweile noch ein Apache-Incubator-Projekt.

Dies bedeutet, dass es gerade modifiziert wird, um die von der Apache Software Foundation geforderten Bedingungen zu erfüllen, um dereinst zu einem «vollwertigen» Apache-Projekt zu werden.
Interessant ist in diesem Zusammenhang aber die Dynamik und die Struktur dieser neuen Projekte: Apache ActiveMQ ist ja ein älterer Bekannter im Apache-Umfeld, aber die neueren Projekte Service Mix, Camel sowie teilweise auch CXF waren frühere Codehaus-Projekte und werden teilweise von den gleichen Entwicklern betrieben. Dadurch ergibt sich eine Gruppe von Projekten, die je nach Bedarf kombiniert werden können, dann gut zusammenarbeiten und die Erstellung von Geschäftsanwendungen deutlich vereinfachen können.

Beispiele für Service-Mix-Komponenten

· Bean: Integration einfacher «POJOs» als Service

· Apache ODE: BPEL Engine

· Camel: Integration von Apache Camel

· Drools: JBoss Regel-Engine

· Quartz: Scheduling und Zeit-basierte Trigger

· Verschiedenste Connectoren für Protokolle wie:

· JMS

· Jabber/XMPP

· File

· ftp

· http

· JCA

Der Autor

Alexander Schatten (alexander@schatten.info) ist Assistent am Institut für Softwaretechnik und interaktive Systeme der Technischen Universität Wien.