The Spoken Word

In diesem Artikel geht es um die Entwicklung von Komponenten für den ESB. In diesem Falle konkret für einen JBI-basierten ESB. Dabei soll erläutert werden, wie Komponenten geschnitten/abgegrenzt werden können und was bei der Entwicklung zu beachten ist. Dem Fehlerhandling wird ebenfalls ein eigener Absatz gewidmet.

Durch den ESB wird eine Architektur beschrieben, die die komponentenorientierte Entwicklung von Integrationsarchitekturen fördert. Dabei werden von einem ESB bestimmte Eigenschaften erwartet, die von den Herstellern in unterschiedlicher Weise umgesetzt werden können.

Im Rahmen des JCP (=Java Community Process) wurde für die Java Plattform eine ESB-konforme Spezifikation erstellt, die unter dem Namen JBI (=Java Business Integration) firmiert. Darin wird eine Kompontenarchitektur beschrieben, die den Lebenszyklus sowie die Interaktion von Komponenten beschreibt, die für die Java Plattform entwickelt werden.

Bei der Entwicklung von Konnektoren kommt es darauf an zu klären, was konkret geleistet werden soll und wie diese Funktion allgemein umgesetzt werden kann.

Das Ziel der Entwicklung von JBI/ESB Komponenten ist es, wiederverwendbare Komponenten zu schaffen, um damit zukünftige Probleme lösen zu können, ohne das Rad buchstäblich neu zu erfinden.

Aus diesem Grunde sollte bei der Umsetzung von Anforderungen in zwei Stufen vorgegangen werden:

1. Beschreibung des konkreten Lösungsvorschlags

2. Zerlegung der speziellen Lösung in eine allg. Lösung und eine spezifischen Anteil (Dekomposition)

Sollen beispielsweise Datensätze aus einer Datenbanktabelle gelesen werden, zu denen es einen Steuersatz in einer anderen Datenbanktabelle gibt, so kann man dieses Problem in einer JBI-Komponente kapseln, die genau dieses Szenario beschreibt. Schafft man jedoch eine wiederverwendbare Komponte, so könnte diese allg. eine Spalte aus einer Tabelle auslesen und anhand dessen weitere Datensätze aus einer anderen Tabelle lesen, wobei die Spalte als Einschränkung verwendet wird. Die Tabellen bzw. die entsprechende(n) Spalte(n) können dabei parametrisiert werden. Auf diesem Wege erreicht man eine Lösung, die nicht nur für ein konkretes und spezifisches Problem anwendbar ist, sondern für eine ganze Klasse von Problemstellungen verwendet werden kann.

Auch bei der Weiterverarbeitun kann man grundsätzliche Abläufe von speziellen Eigenheiten versuchen zu trennen, um damit die Nutzbarkeit der Investition (leverage) zu maximieren und für die Zukunft geringere Aufwände zu produzieren.

Über unterschiedliche Projekte hinweg kann sich somit und dadurch ein Unternehmen eine ganze Sammlung von Komponenten erarbeiten, die für Folgeprojekte zu Verfügung stehen und in diesen genutzt werden können (technical business assets). Durch die konsequente Verwendung von Standards ist dabei eine langfristige Investitionssicherheit gegeben.

Ebenfalls ergeben sich aus den Komponenten Anwendungsmuster, die in die weiteren Architektuplanung einbezogen werden können, um auch Fremdsysteme entsprechend der vorhandenen Pattern zu steuern - auch hier kann weitergehend die Investition genutzt werden.

Entscheidet man sich dafür, die
eigenen Middlerware auf einen Enterprise Service Bus zu heben, so
könnte man dies 1:1 tun. Das Ergebnis wäre relativ
monolithisch, schwer erweiterbar und käme dem Gedanken des ESB
vermutlich nicht nahe. Anstelle dessen sollte man sich konkret
anschauen, was ein ESB für Konzepte anbietet und wie diese
Konzepte sinnvoll Verwendung finden.

Findet neben einem ESB noch ein
Applikationsserver Verwendung (z.B. als größere
Laufzeitumgebung) so erweitern sich die Möglichkeiten der
Architektur um einiges und müssen daher mit Bedacht bewertet
werden.

Folgende Konzepte eines Java gestützten
ESB (JBI) sollen betrachtet werden:

• JBI Komponente

• JBI Shared Library

• Service Unit

• Service Assembly

• Message Exchange Listener

JBI Komponente

Eine JBI Komponente stellt eine
wiederverwendbare Funktionalität für den Bus zur Verfügung.
Das kann z.B. die Fähgikeit sein, XSLT-Transformationen
auszuführen, oder CSV Dateien zu generieren. Alle Funktionen,
die an mehr als genau einer Stelle Verwendung finden sollen (und
nicht für einen konkreten Anwendungsfall spezifisch sind),
sollten als JBI Komponente realisiert werden.

Bei allen anderen Teilkomponenten ist
es relativ schwierig zu entscheiden. Wenngleich die Spezifikation das
hergibt, halte ich es für relativ … schwach

JBI Shared Library

Für shared libraries gibt es einen
klassischen Anwendungsfall: Klassen, die übergreifend in JBI
Komponenten verwendet werden sollen. Diese Bibliotheken stehen dem
gesamten Bus zur Verfügung und sind daher für übergreifende
Funktionalitäten sinnvoll.

Service Unit

Eine Service-Unit ist die Instanz einer
JBI Komponente. Diese werden über XML Dateien parametrisiert. Da
in solchen XML Beschreibungen auch „anderweitige“ Konfigurationen
abgelegt werden können, sollte beim Design explizit darauf
geachtet werden, dass nur SU-spezifische Konfigurationen dort
abgelegt werden, da ansonsten die Übersichtlichkeit leidet.

Service Assembly

Eine Service-Assembly stellt die
logische Bündelung von Service-Units dar. Aus diesem Grunde
sollte ein SA auch nur aus denjenigen SU’s bestehen, die für die
Anwendung notwendig ist. Dabei sollten die SA’s in sinnvolle und
applikationsspezifische Blöcke geschnitten werden.

Message Exchange Listener

Das Konzept der Message Exchange
Listener sorgt dafür, dass man eine Möglichkeit hat, auf
Veränderungen und Serviceaufrufe zu reagieren. Darüber kann
man globales Fehlerhandling, Logging, etc. implementieren. Durch die
Implementierung an einer zentralen Stelle kann damit das gesamte
Verhalten der Plattform beeinflusst werden.

Die Beeinflussung kann dabei positiv
wie negativ sein. Da je nachdem, wie komplex die Operationen sind,
die in einem MEL abgehandelt werden, kann dabei die Gesamtperformance
leiden. Aus diesem Grunde sollte jeder MEL so aufgebaut werden, dass
möglichst früh in der Verarbeitung festgestellt werden
kann, ob der Exchange evtl. verworfen werden kann (da nicht alle
Matching-Kriterien erfüllt sind).

Fazit

Die Verwendung eines Enterprise Service
Bus stellt erstmal keine direkt höheren Anforderungen als ein
anderes IT-Produkt oder Middleware-Plattform. Allerdings sollte man
sich mit den Grundlagen und Architekturkonzepten dieses Prinzips
vertraut machen, um die Möglichkeiten voll ausschöpfen zu
können und sich nicht von Anfang an in eine grundsätzliche
architektonische Sackgasse bewegen.

Best Practices
Auf Wiederverwendbarkeit hin
designen

• bereits bei der Planung einer
  neuen Strecke sollte man sich überlegen, welche generischen
  Komponenten benötigt werden. Eine zu starke Fokussierung auf
  den konkreten Anwendungsfall löst zwar vielleicht das Problem,
  reduziert aber den Nutzen, den Wiederverwendbarkeit bringt. Gerade
  bei der Verarbeitung von Datenformaten sollte auf den kleinsten
  gemeinsamen Nenner hin entwickelt werden, sodass die Spezialisierung
  über die Parametrisierung erfolgt