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.

In einer flexiblen Systemarchitektur, die nach service-orientierten Gesichtspunkten aufgesetzt ist, stellt die Überwachung eine besondere Herausforderung dar.Durch die sowohl technische wie auch fachliche Überwachung lassen sich während des Betriebs Trendlinien für die operative Gestaltung ableiten, aber auch Geschäftschancen ableiten.

Unter technischem Monitoring kann man dabei die folgenden Aktivitäten zusammenfassen:

• Überwachung des Systemzustands von deployten Komponenten (gestartet, gestoppt, etc.)
• Überwachen der Randsysteme (Zustand von DB-Tabellen, die ausgelesen werden, etc., Nachrichtenmengen in Queues)
• Überprüfung mögl. vereinbarter Service-Level-Agreements mit dem Ziel eines Frühwarnsystems

Unter fachlichem Monitoring kann man hingegen die folgenden Aktivitäten zusammenfassen:

• Überwachung des Auftragseingangs/Std.
• Überwachung von Auswirkungen durch fachl. getriebene Werbekampagnen
• Messung der Wartezeiten von Anrufern in Call-Centern

Dabei lassen sich viele Aufgabenstellungen im Umfeld BAM auf wenige, sehr gleichartige Prinzipien zusammenfassen:

• Bewertung von Daten anhand konfigurierter Kritierien
• Messung von Zeit, Anzahl, abgeleiteten Werten (z.B. Durchsatz)
• Eskalation bei Überschreitung von Schwellwerten (Trend-Breaks, etc.)

Wie konkret die einzelnen Aufgaben konkret realisiert werden, ist eigentlich gleich - von Bedeutung ist, dass diese gleichartig sind und damit auf die gleiche Art und Weise realisiert werden können.

Implementiert man abstrakte/generische Komponenten, die diese Aufgaben erledigen, meistens auf Basis von XML, erhält man eine investitionssichernde Applikation, die auch späteren Änderungen standhalten kann.

Eine mögliche Architektur für eine solche Komponente kann wie folgt aussehen:

• Erstellung von Adaptern für die einzelnen Zielsysteme. Diese greifen auf die Randsysteme zu und extrahieren die relevanten Daten. Diese liegen entweder in einem allg. Format vor, dass für die BAM Komponente allgemeingültig ist, oder in einem applikationsspezifischen Format auf Basis von XML. Sofern man für ein applikationsspezifisches Format votiert, hat das den Vorteil, das weniger Anpassungen an den betroffenen Randsystemen erforderlich sind. Dafür muss die Integration dann “vor” der BAM Komponente erfolgen.
• Erstellung einer Vorverarbeitung. Diese extrahiert die für den Trigger relevanten Informationen und stellt diese der BAM Komponente in kanonischer Form bereit. Kanonisch bedeutet, dass alle relevanten Informationen wie eindeutige Zuordnungs-ID, relevante Zeitstempel, etc. vorhanden sind
• Erstellung einer Integration. Diese nimmt die extrahierten, kanonischen Daten entgegen und integriert diese zu einer Gesamtsicht. Dabei bleiben alle Daten erhalten, werden aber für Zugriffe zur Verfügung gestellt. Diese Komponente ist ebenfalls in der Lage, Anfragen bzw. Bewertungsqueries zu beantworten, hinsichtlich der Anzahl von Datensätzen zu einem Schlüssel, Zeitstempel, Mittelwerte/Durchsätze. Durch die Verwendung einer zentralen Komponente, die alle Daten verwaltet, können Erweiteurngen in Bezug auf neue Abfragen/Operationen einfach (z.B. über eine Plugin-Architektur) hinzugefügt werden.

Das Hauptaugenmerk liegt sicherlich auf der BAM Komponente selber. Diese muss in der Lage sein, Konfigurationen einzulesen und diese zu verarbeiten. In diesen Konfigurationen wird für jeden Schlüssel hinterlegt, welche Operationen aufgerufen werden und welche Schwellwerte, welche Aktionen auslösen.

Durch diese nicht-monolithische Architektur wird sichergestellt, dass es keinen development-lock-in gibt, sondern kontinuierliche Erweiterbarkeit sichergestellt ist.

Die BAM Kompenten kann dabei über diverse Wege selber Statistiken bereitstellen (Hit/Miss Ratio, Trends, etc.), die Aussagen über die Intensität und den “Erfolg” der implementierten Regeln geben.

Die Aktionen, die eine BAM Komponente ausführen kann, sollte wiederum in Form von Plugins vorhanden sein. Dadurch ist maximale Flexibilität gewährleistet und jede Aktion für sich kann über das kanonische Datenmodell alle relevanten Informationen abgreifen.

Die Implementierung kann beispielsweise auf Basis eines ESB erfolgen, indem über eine Registry die vorhandenen Plugins registriert werden (je nach Kategorie (Aktion, Operation)). Die BAM Komponente kann über die Registry dynamisch abfragen, welche Operationen zu Verfügung stehen und damit autonom entscheiden, welche Trigger überhaupt aktiviert werden. Diese wiederum greifen über das zentrale Datenmodell auf die Faktenbasis zu und lösen über ihre Ergebnisse ggf. Aktionen in der BAM Komponente aus.

Über diese enge aber trotzdem loose Verzahnung von einzelnen Komponente lässt sich Flexiblität und schnelle Änderbarkeit zentral und verteilt realisieren - eine service-orientierte Architektur auf Basis (eventuell) eines ESB.

Im Rahmen dieser kurzen Ausführungen habe ich vorgestellt, wie auf Basis eines konkreten Geschäftsnutzens eine service-orientierte Architektur verwendet werden kann, um dynamisches Business Activity Monitoring zu implementieren. Als Standardarchitektur kann dabei ein Enterprise-Service Bus eingesetzt werden, der das kanonische Aufrufen von Komponenten ermöglicht und sicherstellt. Im Rahmen einer service-orientierten Architektur kann somit eine “SOA in Klein” etabliert werden, die genau die benötigten Anforderungen umsetzt.

Im Rahmen des SOA Expertenrats der Computerwoche hat Rolf Schumann einen Artikel über Mashups veröffentlicht.

Ich gehe eigentlich nicht davon aus, dass sich in nennenswerter Weise Mashups in näherer Zeit etablieren werden. Die Idee hinter einem Mashup ist, Daten aus unterschiedlichen Quellen zu rekombinieren, um darüber Mehrwert zu erzeugen.
Dazu bedarf es aber einiger Voraussetzungen:

• Die Daten müssen vorhanden und entsprechend zugreifbar sein
• Die Verknüpfung sollte einfach und schnell erfolgen

Das Vorhandensein von Daten ist dabei in den wenigsten Fällen ein Problem, aber allein das hoch-integrative Beispiel von Kartenmaterial zeigt auf, dass es um die Datenverknüpfung von internen wie externen Daten geht. Aus Datenschutzgründen ist es für Unternehmen sicherlich schwierig zu akzeptieren, dass Daten von außen den Daten “im Inneren” beigemischt werden. Der Mehrwert von Mashups kann schließlich in den wenigsten Fällen komplett im Unternehmen selber geleistet werden.

Vielmehr ist der Datenbestand im Unternehmen der Ausgangspunkt für ein Mashup. Darauf aufbauend können anschließend Daten “von extern” dazugezogen werden, um diese Informationen zu visualisieren oder wie-auch-immer anzureichern. Zumal die meisten Datentöpfe für diese Art der Verwendung auch nicht vorbereitet sind.

Neben diesen Problemen sind auch Aspekte des Zugriffs noch ungeklärt. Zugriffsschutz auf interne Daten muss auch bei Verwendung von Mashups erhalten bleiben. Dazu gibt es AFAIK in der “Szene” noch keine Antworten.

Die einfache Bereitstellung ist sicherlich auch noch ein riesiges Problem. Yahoo hat gezeigt, wie es “vereinfacht” gehen kann, aber ob dies das Ende der Fahnenstange ist, darf bezweifelt werden. Auch Google arbeitet in diesem Gebiet mit, auch hier dürften Innovationen noch zu erwarten sein. Das Credo muss auch hier sein, dass das Mashup

• einfach und
• für den Fachbereich verständlich

erstellt werden kann. Nur dann ist die Akzeptanz da, diese neue Möglichkeit aufzugreifen und Lösungen “mal eben so” zu erstellen und zu nutzen.

Aber auch wie Wiki’s oder Weblogs nach einer ganzen Weile Einzug ins Unternehmen halten, wird auch das Mashup seinen Platz in der Unternehmenswelt finden - und sei es nur als leichtgewichtige Möglichkeit, die Unzulänglichkeiten der im Einsatz befindlichen Applikationen “einfach” zu überspielen, indem dynamische Datenverknüpfungen  “on demand” geschaffen werden, um Fragen zu beantworten.

Nicht umsonst ist die statische Verknüpfung von an sich dynamischem Inhalt der große Vorteil. Diesen für die Geschäftswelt sichtbar zu machen und durch die IT in geordneten Bahnen umzusetzen ist sicherlich eine Herausforderung, die kommen wird. Nur wann - wie immer schwer abzusehen

Ein Kommentar zum gleichnamige Weblog-Eintrag der Computerwoche.

Die ganzen Themen im/um den Bereich SOA/ESB/EDA/XYZ drehen sich doch, richtigerweise, darum, wie die IT dem Druck nach Veränderung begegnen kann.

Insofern stimme ich Hr. Kürpick absolut zu, dass ein ESB selber keine Alleinlösung ist. Ein Herzstück mit Sicherheit, aber nicht ohne organisatorisches Rückgrat.

Wobei sich die Themen langsam auf die Bereiche “zurückziehen”, auf denen sie sinnvoll eingesetzt werden können. Damit ergibt sich für die IT die Möglichkeit, mit etablierten Standards zum Einen auf Frage nach Veränderung zu beantworten. Zum Anderen ergibt sich aber auch die Möglichkeit, diese Frage geordnet zu beantworten.

Mit einem ESB als Rückgrat schafft sich die IT eine Infrastrukturplattofrm, die ausbaufähig und wartbar ist/bleibt. Darauf aufbauend können service-orientierte Architekturen implementiert werden, die dem Nutzen der Fachbereiche dienen (wobei das ein ESB nicht auch täte).

Aus diesem Grunde sehe ich die aktuellen Entwicklungen vermehrt als Chance der IT, auf anstehende Probleme mit Lösungen zu antworten, die zu einem gewissen Maße ausgereift sind.

Dabei muss ein ESB nicht zwangsläufig als Produkt verstanden werden, auch wenn es mittlreweile viele Produkte gibt. Die zugrundeliegenden Architekturen und Design-Ideen können in vielen Umgebungen umgesetzt werden.

Auf dem Basic Thinking Blog gibt es was nettes zu lesen zum Thema Blogging ohne Leser, bzw. wie man an Leser kommt.

Das Thema ist wichtig und auch in gewisser Weise interessant (da Zeitungen und Journalisten prinzipiell das gleiche Problem haben).

Dabei ist es aus meiner Sicht in erster Linie wichtig, dass man interessante Themen behandelt und diese aus seiner persönlichen Erfahrung heraus betrachtet. Dadurch dass jeder Mensch einen individuellen Hintergund hat, können Dinge, die dem Einen leicht fallen, für jemand anders ziemlich problematisch sein.

Die Quintessenz aus dem BTB Artikel: Authentisch sein, Persönliches mitteilen, und vor allem keine Trivialitäten kund tun - denn die interessieren mal überhaupt nicht

Die ganzen Artikel und Empfehlungen, wie man “technisch” an neue Leser kommt, sind interessant, aber nur vordergründig. Spannend ist doch vielmehr aus eigener Kraft an Leser zu kommen (einerseits) und diese auch zu halten (andererseits). Die Optimierung des Weblogs für Suchmaschinen ist sicherlich nicht unwichtig, aber auch nicht kriegsentscheidend.

Schlußendlich kann ich ihm nur zustimmen und zwar auf ganzer Linie Und als Übung für das Schreiben von Artikeln und die Möglichkeit, in den “Flow” zu kommen, ist Blogging eine extrem gute Möglichkeit. Selbst wenn keiner mitlesen sollte

In modernen Geschäftsumgebungen gibt es eine ganze Reihe von Standardanwendungen und selbst entwickelten Lösungen. Gerade letztere haben sich in der Vergangenheit entwickelt, da Standardkomponenten nicht immer den Erfordernissen eines modernen Geschäftsbetriebs gerecht wurden. Die Standardanwendungen hingegen haben oftmals durch komplizierte und/oder unbrauchbare Schnittstellen ausgezeichnet, die in vielen Fällen den Wünschen der Anwender zuwiderliefen, anstatt diese zu unterstützen.

In diesem Umfeld hat sich EAI entwickelt - als Möglichkeit, beliebige Anwendungen in einem heterogenen Umfeld miteinander zu verknüpfen. Dies erfolgt auch Ebene der Daten und erfolgt über orchestrierten und geordneten Austausch der Daten über Anwendungsebenen hinweg.

Die Notwendigkeit ist dabei relativ klar, wenn man überlegt, das ein Unternehmen Daten zwischen Anwendungen austauschen können muss. Sofern die bestehenden Anwendungen hinreichend “gute” Export-/Importmöglichkeiten bietet, gibt es erstmal keine Notwendigkeit, eine EAI Infrastruktur zu realisieren. Steigt aber die Anzahl der Schnittstellen an, bzw. sollen viele Datenstrecken realisiert werden, führt dies zu Point-to-Point Verbindungen, die nicht gewünscht sind, da der Verwaltungsaufwand und die Administration extrem steigt. Zudem wird das ganze Gebildet recht schnell unübersichtlich.

In diesem Umfeld bietet sich ein zentraler Hub an, der für den Datenaustausch zuständig ist - die EAI Plattform.

Die Frage, die technisch interessant ist, ist die nach der Motivation. Reichen die Argumente, die eine EAI Plattform bieten kann:

• Auflösen der Point-to-Point Verbindungen
• Entflechtung und Harmonisierung der unterschiedlichen Datenströme
• schnelle und zentrale Anpassung bzw. Änderbarkeit von Datenflüssen

aus, um sich für eine Einführung zu entscheiden?

Diese Frage hat sich sicherlich vor einiger Zeit noch gestellt, als es wenige Alternativen gibt - diese waren vor allem auch noch zumeist proprietär. Das immer gleiche Problem, dass es zu lösen gab und gibt ist, dieses:

Auf welche Art und Weise kann die IT auf die sich immer schneller ändernden Anforderungen der Geschäftswelt reagieren? Ergänzt wird dies in letzter Zeit noch mit dem Zusatz: Welchen Beitrag zum Gesamtergebnis eines Unternehmens kann die IT leisten?

Um die Gunst der IT-Entscheider ranken sich mittlerweile die Konzepte EAI, SOA, EDA und ESB.

Dabei verspricht EAI, das Business zu beschleunigen, indem die Datenströme in einem Unternehmen beschleunigt und “gestreamlined” werden. In einem Umfeld, in dem vor allem der Datenaustausch als zentrales Problem gesehen wird, die Anwendungen für sich genommen aber funktional ausreichend sind, ist dies die richtige Entscheidung. Hierbei handelt es sich also um eine Infrastruktur-Disziplin.

Dem gegenüber verspricht SOA die Geschäftsprozesse zu beschleunigen, in dem die Geschäftsprozesse analysiert werden, aufgespaltet werden in Komponenten (sogenannte Services) und anschließend über eine dynamische Orchestrierung wieder zusammengefügt werden. Hier wird ein Schritt weiter gegangen, als bei der EAI Architektur. Anstelle die Datenströme zu optimieren (und damit implizit auch einen Beitrag zur Geschäftsprozessoptimierung in zeitlicher Hinsicht) wird bei SOA der Geschäftsprozess insofern in den Mittelpunkt gestellt, als die Abbildung des gesamten Prozesses in technischer Form zu einer ganzheitlichen Orchestrierbarkeit führt. Hierbei gehört der zugehörige Datenaustausch natürlich mit ins Konzept, wird aber eher zweitrangig “mitbehandelt”. Der EAI Gedanke wird mit einbezogen und ggf. ein Teilen umgesetzt, der Fokus liegt aber klar auf dem Prozess.

Betrachtet man EDA, so handelt es sich nicht um eine technische Lösung, sondern vielmehr um ein Architekturpattern, die Event-Driven-Architecture. Diese zielt darauf ab, gerade in gewachsenen Strukturen dazu zu kommen, sich von festen Zeitpunkten zu lösen und die Plattform und die darauf laufenden Applikationen eng aneinander zu koppeln. Dabei wird jeder Prozessschritt an den nächsten angekoppelt (unter Verwendung von Triggern oder ähnlichen Ereignissteuerungen), um damit eine möglichst enge Verzahnung zu erreichen. Durch eine solche Kopplung soll erreicht werden, dass auf unnötige Wartezeiten verzichtet wird. Hierbei handelt es sich ganz klar um eine techologisch losgelöste Vorgehensweise, die sowohl mit EAI Plattformen als auch mit SOA Architekturen umgesetzt werden kann.

Als letztes tritt ESB an, die Gunst der IT’ler zu erwerben. Dabei handelt es sich um eine Architektur und Plattform, um Komponenten mit bestimmten Schnittstellen in ein Ganzes zu führen. Das bedeutet, man installiert eine Plattform und installiert auf dieser Plattform einzelne Komponenten. Jede dieser Komponenten hält sich an eine vorgegebene Schnittstelle und die Plattform kümmert sich um die Ansteuerung der einzelnen Module. Welche davon in welcher Reihenfolge angesprochen werden, ist der jeweiligen Konfiguration zu entnehmen, die mit ausgeliefert wird. Dadurch können Änderungen sehr schnell umgesetzt werden, da lediglich die Konfiguration angepasst wird. Im Falle von Änderungen an den Komponenten, müssen nur die jeweiligen Komponenten angepasst werden, die Konfigurationen nehmen die Änderungen beim Deployment automatisch auf.

Hierbei handelt es sich sowohl um ein Architekturpattern, dass nicht zwangsläufig an eine konkrete Plattform gebunden ist. Andererseits bieten diverse Hersteller Produkte dieser Kategorie an, die allesamt die notwendigen Voraussetzungen mitbringen.

Die Frage nach dem Gesamtsieger ist relativ einfach zu erklären, da es keinen tatsächlichen Sieger gibt. Stattdessen bearbeiten alle Anwärter Teilgebiete des Ganzen, das sinnvolll zusammengefügt werden will.

Folgender Ansatz kann gewählt werden, um zu einer Lösung zu gelangen:

• Implementierung der Middleware auf Basis eines ESB. Hierbei wird einfache Erweiterbarkeit und schnelle Umkonfiguration von statischen Datenstrecken sichergestellt.
• Implementierung von Datenstrecken auf Basis von etablierten EAI Patterns. Hiermit wird erreicht, dass synchronisierte Datenströme, die evtl. unter Performanceaspekten zu realisieren sind, in einer einheitlichen und zentral administrierten Plattform aufgebaut werden. Es wird ein ESB verwendet, ohne auf irgendwelche Aspekte der EAI zu verzichten
• Unterstützung der Geschäftsprozesse durch eine SOA Architektur. Auf Basis eines ESB ist sichergestellt, die Vorteile der zentralen Komponenteregistrierung zu nutzen, die Flexibilität einer SOA aber weiterhin zur Verfügung zu haben. Durch die Registrierung weiterer Komponenten zur Laufzeit können dabei Funktionalitäten wie Geschäftsregeln (Business Rules), Orchestrierungen (BPEl, BPM, etc.) oder Aktivitätsüberwachung (BAM) unkompliziert nachgerüstet werden.
• Als generelles Schema für die Implementierung sollte dabei der EDA Gedanke aufgegriffen werden. Durch eine ereignisgesteuerte Abarbeitung werden Leerlaufzeiten vermieden und damit maximale Agilität sichergestellt. Optimierungen einer Stelle des Prozesses wirken sich damit unmittelbar auf die nachgelagerten Stellen aus.

Um alles nochmal kurz zusammen zu fassen: Es wurden die Probanden EAI, SOA, EDA, ESB betrachtet. Dabei haben sich alle als tauglich erwiesen, bieten aber nur in sich verzahnt maximale Flexibilität. Diese wird dann erreicht, wenn auf Basis eines ESB die statischen Datenstrecken über EAI Architekturen abgebildet werden. Die flexiblen Bestandteile werden nach SOA Patterns abgebildet. Die grundsätzliche Vorgehensweise richtet sich dabei nach EDA Prinzipien (also mit maximaler Flexibilität).

Über ein solches Vorgehensmodell können sowohl die Anforderungen von statischen, hochperformanten Datenströmen, als auch von flexiblen Prozessen, die an die Geschäftswelt angelehnt sind, realisiert werden. Durch die Verwendung eines ESB wird die zukünftige Erweiterbarkeit sichergestellt, ohne eine spätere Gefährdung der Stabilität in Kauf zu nehmen (da nur isolierte Komponenten betrachtet werden).

Bei der Verwendung von JMS-basierten Messaging-Systemen wie z.B. ActiveMQ oder JbossMQ kann der Nachrichtenaustausch in zweierlei Facetten ablaufen:

• als qualitativer Nachrichtenaustausch, also mit Nachrichten beschränkter Größe
• als quantitativer Nachrichtenaustausch, also mit Nachrichten, die eine erhebliche Größe erreichen können

Den erstgenannten Fall behandeln die Messaging-Systeme meist ziemlich gut und auch die Performanceanforderungen können meist gut erreicht werden.

Begibt man sich jedoch auf das Gebiet des Massendatentransfers unter Performancebedingungen, quasi der Königsdisziplin, da die Systeme dabei an ihre Grenzen gebracht werden, handelt es sich um ein völlig anderes Bild.

In der Standardkonfiguration können die wenigsten Messaging-Systeme eine solche Last bewältigen, da die Systeme für Allround-Aufgaben konfiguriert sind und teilweise eine Menge Feintuning benötigen.

Ein exemplarischer Fall ist dabei die verwendete Datenbank. Wird diese nicht explizit auf Performance hin optimiert, kann ein immenses Potenzial an Geschwindigkeit ungenutzt verloren gehen.

Durch die intelligente Partitionierung der einzelnen Bereiche einer Datenbank (Index-Space, LOB-Space, etc.) kann der Datenbank angezeigt werden, wie die einzelnen Bereiche verwendet werden sollen. Auch eine Optimierung der Chunk-Sizes können einiges bringen. Bei der Chunk-Size handelt es sich um die Blockgröße, mit der die Datenbank die Daten ins Dateisystem schreibt. Je größer die Daten sind und je kleiner die Chunk-Size ist (bzw. je weiter diese von der mittleren Nachrichtengröße entfernt liegt), desto mehr I/O Operationen sind notwendig, um die Daten zu persistieren.

Eine Anpassung auf die mittlere Nachrichtengröße kann hierbei Verbesserungen in diversen Vielfachen bringen.

Am Beispiel von JBossMQ kann man auch sehr gut erkennen, wie sich das Speichermanagement auwirken kann. Bei JBossMQ handelt es sich um das Standard-Messagingsystem, dass bis JBossAS 4.2 Verwendung findet. Dias System kennt dabei zwei verschiedene Typen von Nachrichten: Hard-Messages und Soft-Messages.

Bei den Hard-Messages handelt es sich um Nachrichten, die komplett im Speicher vorliegen. Bei den Soft-Messages handelt es sich um Nachrichten, die als Referenz im Speicher liegen, deren Inhalt bei Bedarf aber aus der Datenbank bzw. dem persistenten Speicher nachgeladen werden müssen.

Dabei verwendet JBossMQ einen LRU-Cache (=Last Recently Used), um zu bestimmen, welche Nachrichten aus dem Speicher entfernt werden und welche dort verbleiben. Das Ziel ist, Nachrichten erstmal komplett im Speicher zu halten und erst nach einer Weile zu entfernen (”softenen”), um damit eine schnelle Verfügbarkeit zu sichern.

Im Falle von Nachrichten, die erst sehr viel später abgearbeitet werden, kann sich über die Zeit eine erklägliche Menge von Nachrichten ansammeln.

Dabei beim Start des JBossMQ Systems diese Nachrichten erstmal komplett in den Speicher geladen werden, führt dies zu

- langen Startzeiten

- hohem Speicherverbrauch

Um dies zu umgehen, kann man das JBossMQ so anpassen, dass Nachrichten beim Start nur als Referenz geladen werden, bzw. das System so anzupassen, dass aus einer Hardreference sofort eine Softreference wird. Das verkürzt die Startzeiten ganz erheblich und entlastet massiv den Speicherverbrauch. Damit erkauft man sich aber auch das Problem, dass das Einladen von Nachrichten länger dauert, als im normalen Falle.

Hierbei kann man zwar insgesamt die Frage stellen, wie es überhaupt zu so einem Verhalten kommen kann, aber wenn Zielsysteme über einen längeren Zeitraum nicht erreichbar sind, kann das je nach Datendurchsatz schneller geschehen, als einem oftmals lieb ist.

Die notwendigen Anpassungen sind aber leider nicht über die reine Konfigurationen machbar, sondern bedingen Eingriffe in den Quelltext, die wohl überlegt sein wollen, damit keine unerwünschten Nebeneffekte(Datenverlust, reine in-Memory Persistierung, permanente Garbage Collection, etc. pp.) auftreten.

Der Hype um die service-orientierten
Architekturen ist ziemlich hochgekocht und hatte auch durchaus seine
Berechtigung. Die vermutete Lösung aller Probleme jenseits der
Architekturen, Silos und Programmiersprachen hat extrem
verheißungsvoll geklungen und dieses Versprechen wurde auch zu
guten Teilen eingehalten.

Durch die Verwendung von Web-Services
ist es schließlich möglich, aus der Java-Welt heraus einen
Mainframe mit CICS anzusprechen, die Ergebnisse direkt als XML an
eine Oracle-Datenbank zu schicken und noch eine Statusmeldung an
einen Python-basierten Service zu schicken. Das diese Services quer
über den Erdball verteilt liegen können, ist dabei
lediglich das Sahnehübchen auf der Messlatte des Erreichten.

Allerdings wurde dabei eine wichtige
Eigenschaft übersehen: Die „Struktur des Ganzen“ - die
Architektur halt.

Über das Protokoll SOAP war
lediglich geklärt, wie die einzelnen Services austauschen und
worauf jeder Service bauen kann – was er erhält. Ferner hat
sich jeder Dienstanbieter dazu verpflichtet gesehen, ein Datenformat
zu nennen, mit dem seine Dienste aufgerufen werden können. Diese
haben dann alles Mögliche gemacht: PDF’s erstellt, Berechnungen
durchgeführt, Zahlen und Charts und Grafiken überführt,
etc.

Wie die ganze Orchestrierung dahinter
abläuft – das hat niemand gesagt. Also hat jeder seine eigenen
Überlegungen angestellt und daraus sind die unterschiedlichsten
Resultate hervor gekommen. Teilweise waren diese sinnvoll, teilweise
eher „proprietär“. Aus diesem Grunde ist die Entwicklung der
ESB-Architektur ein Meilenstein in der SOA Entwicklung und könnte
dem „Durchbruch von SOA in der Breite“ dienen.

Die Definition von SOA und ESB ähneln
sich dabei sehr stark: anstelle einer konkreten, spezifischen Vorgabe
handelt es sich vielmehr um eine Ansammlung von Eigenschaften, die
für das jeweilige Konstrukt prägend sind.

Ob es sich dabei um die Kombination von
SOAP/Web-Services im Falle von SOA oder JbossESB im Falle von ESB
handeln muss, ist diskutierbar. Schließlich führen viele
Wege zum Ziel und diese Freiheit ist gut und wichtig. Durch die
Festlegung von Eigenschaften ist es freigestellt, wie diese in der
jeweiligen Umgebung realisiert werden können. Anhand dieser kann
aber jeder Auftraggeber sehr einfach prüfen, welche Güte
die umgesetzte Lösung eines Dienstleisters hat und inwieweit
sich dieser an die Referenzeigenschaften gehalten hat.

Wenn man die gewonnenen Erkenntnisse
auf die Software-Entwicklung überträgt, so kann man dort
sehr einfach Analogien feststellen. Am Anfang der Entwicklung hat
jeder so gearbeitet, wie es ihm beliebte. Die Build-Prozesse wurden
dabei über „ant“ in erste Bahnen gelenkt. Durch die
konsequente Weiterentwicklung in Richtung „maven“ ist nun ein
neuer Meilenstein erreicht: ein vorgegebenes Framework für die
Software-Entwicklung mit einer einheitlichen Abhängigkeitsverwaltung,
einer einheitlichen Verzeichnisstruktur und vielem mehr.
Kontrollierte Freiheit.

Diese Entwicklung scheint nun auch im
Bereich der SOA Einzug zu halten – und dies ist absolut
begrüßenswert!

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

Mit dem Schlagwort „Business Activity Monitoring“ wird ein relativ aktuelles Buzzword umschrieben, hinter dem sich die fachliche Überwachung von technisch umgesetzten Prozessen versteckt. Die Idee dabei ist, dass in einer flexiblen IT-Welt unterschiedliche Ereignisse dynamisch eintreten können und diese oft erst relativ weit hinten auf einem Zeitstrahl erkannt werden können. Oftmals werden die Informationen eines Unternehmens in einem Data-Warehouse zusammengefasst. Auf diesem Datenbestand können dann Analysen und Berichte aufgesetzt werden. Das ist für viele Daten soweit okay, allerdings bietet es auch das Problem, dass Daten niemals zeitnah zur Verfügung stehen.

Da Busienss Activity Monitoring setzt aber direkt auf Ebene der Datenströme auf und kann dadurch sehr viel zeitnäher informieren. Dabei werden durch die Fachbereiche „interessante“ Kriterien definiert, die eine Aktivität beschreiben – Bestellungen, Orderaufgaben, Bearbeitungsstati. Während nun all diese Aktionen zu Reaktionen innerhalb der IT-Welt führen, greift die/eine BAM-Komponente die unterschiedlichen Datenströme ab und bewertet sie anhand der vorgegebenen Kriterien.

Als Reaktion kann durch so eine Komponente beispielsweise bewertet werden, wie lange eine Orderausführung benötigt, an welcher Stelle im Prozess Verzögerungen aufgetreten sind und wie sich diese entlang des gesamten Ausführungsprozesses verteilen. Alternativ kann auch im „Livebetrieb“ der Erfolg von Werbemaßnahmen bewertet werden, da erkennbar ist, für welche Produkte Bestellungen eingehen. Insofern sind mannigfaltige, sehr zeitnah ausführbare, Analysen möglich. Die Historisierung kann dabei entweder auch innerhalb der Plattform, oder in einem Data-Warehouse erfolgen.

Die Integration von BAM in eine bestehende Plattform kann dabei ganz unterschiedliche Ausmaße annehmen. Verwendet man als Rückgrat einen ESB (=Enterprise Service Bus) bzw. ein entsprechendes Konzept, so kann die Integration sehr transparent erfolgen, da Produkte wie beispielsweise Apache ServiceMix die Möglichkeit bieten, die gesamte Kommunikation innerhalb des Buses abzugreifen und vor-/nachzuverarbeiten. Findet eine SOA Einsatz, die auf einen ESB verzichtet, so kann ein Interceptor-Pattern angewendet werden, um einen BAM-Layer einzuziehen. Die Änderungen sind dabei ebenfalls eher gering, können aber zu einer weitreichenden Datenbasis führen, die durch die Änderung an einer zentralen Stelle in der Architektur hervorgerufen wird.

Egal, welchen Ansatz für die Integration gewählt wird, ein auf jeden Fall wichtiger Punkt ist die Performance der Plattform. Da diese Auswertung on-top auf die bestehende Plattform aufgezogen wird, ist es notwendig, diesen Layer so schlank wie möglich zu halten, um die Gesamtperformance nur minimal zu beeinflußen. Daher sollte hier, egal wie die konkrete Lösung aussieht, lediglich ein Store-and-forward Prinzip Verwendung finden. Die empfangenen Nachrichten sollen gespeichert bzw. an ein Messaging-System oder anderweitigen persistenten Speicher übergeben werden und die Verarbeitung soll sofort weiterlaufen. Eine tatsächliche Echtzeit-Verarbeitung ist für dieses Konstrukt nur in wenigen Fällen sinnvoll (in denen es keine zeitlichen Restriktionen gibt) und aus diesem Grunde sollte jeder Eingriff minimal-invasiv (medizinisch gesprochen) vorgenommen werden.