Application Integration Patterns in Enterprise Web Applications

In meiner Masterarbeit, welche ich mit Zweitag als Praxispartner geschrieben habe, wurden Application Integration Patterns als erprobte Konzepte zur Bewältigung dieser Herausforderungen untersucht. Das Thema wurde im Kontext eines Zweitag-Projekts bearbeitet, bei welchem ein monolithisches ERP-Altsystem durch eine Architektur von web-basierten Applikationen abgelöst wird.

Aufbau der Arbeit

Im ersten Teil der Arbeit wurde das Projektteam in einem Fokusgruppen-Interview interviewt, welches anschließend mit Hilfe der qualitativen Inhaltsanalyse nach Mayring analysiert wurde. Auf Basis der Analyse-Ergebnisse konnte der Aufbau des Projektes, die aktuelle Verwendung von Application Integration Patterns, und das Potential für die weitere Verwendung von Patterns erarbeitet werden.

Im zweiten Teil der Arbeit wurde eines der Patterns, welches sich im ersten Teil als potentiell interessant für das Projekt herausgestellt hat, auf seine konkrete Eignung geprüft. Dafür wurde eine für das Projekt repräsentative Beispielarchitektur implementiert, die das Pattern umsetzt. Im Folgenden möchte ich auf den ersten Teil meiner Arbeit eingehen. Der zweite Teil wird Thema eines weiteren Blogbeitrages werden.

Was sind Application Integration Patterns?

Jedes Pattern bezieht sich allgemein gesehen auf ein Problem, welches immer wieder in unserer Umgebung auftritt. Das Pattern beschreiben den Kern eines Lösungsansatzes zu diesem Problem, sodass dieser Ansatz immer wieder verwendet werden kann. [AIS77]

Patterns werden von Lösungen abgeleitet, welche zurvor bereits in der Praxis das Problem erfolgreich behoben haben und können daher als fundierte Herangehensweise an das Problem betrachtet werden [Fo02, S. 10] [HW03, S. 34].

In der Softwareentwicklung gibt es eine Vielzahl von Patterns, viele von ihnen sind jedoch nur für einen speziellen Einsatzzweck oder eine spezielle Softwaresparte relevant [Fo02, S. 2]. Application Integration Patterns sind eine solche Art von Patterns. Sie ermöglichen einen effizienten, zuverlässigen und sicheren Datenaustausch zwischen mehreren Enterprise Applications.

Integrierte Enterprise Web Applications in der Praxis

Im Rahmen des erwähnten Projekts wird eine monolithische, in COBOL implementierte ERP-Anwendung schrittweise abgelöst.

Hierbei werden nach und nach Teilbereiche aus dem Altsystem in einzelnen Web Applications umgesetzt (beispielsweise Artikelstamm, Kundenstamm, Auftragsverwaltung) und wiederum mit dem Altsystem integriert. Der verwendete Funktionsumfang des Altsystem wird so nach und nach reduziert, bis schließlich der Punkt erreicht wird an welchem das Altsystem abgeschaltet werden kann. Diese Vorgehensweise wird auch als Strangler Pattern bezeichnet.

Vorteile des Strangler Patterns

Die damit einhergehende Verteilung der Funktionalität auf mehrere miteinander integrierte Anwendungen bringt eine Vielzahl von Vorteilen mit sich.

• Die Funktionalitäten des Gesamtsystems können anhand ihrer Themen getrennt werden. Wenn das strikt umgesetzt wird, hat jede Applikation lediglich einen Integrationspunkt mit den anderen Applikationen. Die Kundenstamm-Applikation ist zum Beispiel darauf spezialisiert die Kundendaten zu verwalten. Keine anderen Daten werden gespeichert, keine weitere Logik zu anderen Teilen des Systems findet sich in der Applikation. Daher bietet die Applikation nur eine Schnittstelle zum Abrufen und Ändern der Kundendaten an.
• Das parallele Arbeiten an mehreren Teilbereichen der Applikation wird vereinfacht.
• Die Entstehung eines weiteren Monolithen wird verhindert.
• Projektteilnehmer, welche zu einem späteren Zeitpunkt zum Projektteam dazustoßen, können sich einfacher in das Projekt einfinden. Eine Einarbeitung kann sich auch auf die für die Arbeit relevante Teilanwendung des Projekts beschränken.

Herausforderungen im Entwicklungsprozess

Allerdings entstehen durch das Verteilen der Funktionalität auf mehrere Anwendungen auch neue Herausforderungen im Entwicklungsprozess.

• Da die Funktionsweise einzelner Applikationen auch von der Interaktion mit anderen Anwendungen abhängig ist, muss sie teilweise durch applikationsübergreifende Integrationstests abgedeckt werden. Das Testen in einer isolierten Umgebung ist nicht immer ausreichend.
• Da das Altsystem nach und nach abgelöst wird, müssen die noch produktiven Teile des Systems in die neue Architektur integriert werden. Da das Altsystem während der Umsetzung des Projekts zu jeder Zeit funktionsfähig bleiben soll, wird jede neue Applikation direkt mit dem jeweils relevanten Teil des Altsystems integriert. So besteht keine Abhängigkeit von einem zentralen Integrationspunkt, jedoch wirkt sich diese Vorgehensweise auch auf die Größe der Anwendungen aus.

Die Architektur des Projektes

Aus den Analyseergebnissen des Fokusgruppeninterviews wurde ein Ausschnitt der Architektur des Projektes erarbeitet.

Dieser Ausschnitt zeigt nur Applikationen welche im Projektverlauf implementiert wurden, nicht die in die Architektur integrierten Altsysteme.

Die Applikationen greifen über REST APIs auf die Daten anderer Applikationen zu. Dabei kann jede Anwendung einen Cache mit den zuvor angefragten Daten aus anderen Applikationen vorhalten. Dies ist bei einer Anfrage der Auftragsverwaltung an den Artikelstamm zu sehen. Die aus der Anfrage resultierende Antwort wird im Cache der Auftragsverwaltung gespeichert und bei einer identischen Anfrage wiederverwendet.

Wenn im Artikelstamm die betreffenden Daten nun aktualisiert werden, teilt die Applikation das mittels einer Nachricht der Message-Oriented Middleware mit. Diese verteilt die Nachricht wiederum an alle Applikationen die diese API konsumieren, welche daraufhin ihren Cache zur betroffenen Ressource invalidieren. Bei der nächsten Anfrage erhalten sie so die aktualisierten Daten. Dieses Vorgehen wird im Artikel AMQP in a rest scenario genauer beschrieben.

Das in der Abbildung ebenfalls erkennbare Portal verwaltet Informationen über die im Projekt vorhanden APIs und dient sämtlichen Applikationen, welche APIs innerhalb des Projektes konsumieren, als zentrale Anlaufstelle.

Verwendung von Application Integration Pattern im Projekt

Als Grundgesamtheit für die Suche wurden Pattern aus drei verschiedenen Literaturquellen zu Grunde gelegt:

• „Patterns of Enterprise Application Architecture“ Fowler, 2002 [Fo02]
• „Enterprise Integration Patterns“ Hohpe and Wolf, 2003 [HW03]
• „Service Design Patterns“ Daigneau, 2011 [Da11]

Da sich Application Integration Patterns aus der Architektur und den Applikationen erfolgreicher Projekte ableiten, gehen sie letztendlich auf die persönliche Erfahrung der Autoren zurück. Daher ist die aus den Literaturquellen resultierende Liste von Pattern nicht als vollständig zu verstehen. Auch die im Projekt identifizierten Patterns sind keinesfalls eine vollständige Liste der im Projekt enthaltenen Patterns. Konkret identifiziert wurden:

Service Layer

Das Service Layer [Fo02, S. 133] umfasst alle innerhalb des Projektes bereitgestellten Services (APIs). Durch einen Service bereitgestellten Operationen kapseln häufig komplexe Aktionen innerhalb einer Anwendung in einer verständlichen und handhabbaren Form. So entsteht durch das Service Layer eine auf Interaktion optimierte Sicht auf das Gesamtprojekt. Im konkreten Fall bilden die APIs dieses Layer.

Service Connector

Dieses Pattern [Da11, S. 168] kapselt den für eine Interaktion mit einem Service notwendigen Code in einem Modul. Da dieses Modul in mehreren Applikationen wiederverwendet werden kann, werden Duplikate des Codes vermieden. Im Projekt wird so der Code, welcher für das Konsumieren der APIs benötigt wird, wiederverwendet.

Service Registry

In einer Service Registry [Da11, S. 220] werden Informationen über die im Projekt enthaltenen Services gespeichert. So wird die einheitliche Verwendung und Wiederverwendung der Services unterstützt. Die Portalanwendung ist solch eine Service Registry.

Message Translator

Durch das Message Translator Pattern [HW03, S. 96] können Applikationen, welche Nachrichten in unterschiedlichen Formaten versenden, miteinander integriert werden. Hier wird es konkret verwendet um das Altsystem in das Projekt zu integrieren, indem seine Nachrichten in ein für die Message-oriented Middleware verständliches Format übersetzt werden.

Gateway

Ein Gateway [Fo02, S. 466] ist ebenfalls ein Ansatz um ein Altsystem in eine neuere Architektur einzubinden. Sein Ansatz ist jedoch generischer und nicht nur auf Messaging-Systeme anwendbar, da es ein Interface für das Altsystem bereitstellt, welches wie ein Interface der neu hinzugefügten Applikationen beschaffen ist. Mit Hilfe dieses Patterns werden im Projekt unter anderem COBOL-Datendateien für die Web Applications lesbar gemacht.

Kombinieren der Message, Message Channel, Publish-Subscribe Channel und Message Router Pattern zum Verteilen von Nachrichten

Die Patterns Publish-Subscribe Channel [HW03, S. 113], Message [HW03, S. 81-83], Message Channel [HW03, S. 76-81] und Message Router [HW03, S. 92] werden gemeinsam verwendet und bilden so die Funktionsweise der Message-oriented Middleware ab. Dabei abonniert eine Menge von Subscribern Nachrichten zu einem bestimmten Thema. Publisher senden nun Nachrichten an die Middleware, welche auf Basis bestimmter Kriterien entscheidet, welchem Thema die Nachricht zugeordnet und somit an die entsprechenden Subscriber weitergeleitet wird.

Eine solche Middleware besteht hauptsächlich aus drei Bestandteilen:

• Message Channels, in welche die veröffentlichenden Applikationen ihre Nachrichten senden können. Die im Projekt verwendete Message-oriented Middleware RabbitMQ nennt diese Komponente „Exchanges”.
• Message Router, welche entscheiden wie die Nachrichten weitergeleitet werden. Im Kontext von RabbitMQ „Routes”.
• Publish-Subscribe Channels, an welche die Middleware die weitergeleiteten Nachrichten sendet und aus denen abonnierende Subscriber die Nachrichten entgegennehmen. Bei RabbitMQ wird hier für jeden Subscriber eine eigene „Queue” erstellt, in die die Nachricht weitergeleitet wird.

Die Kombination dieser Pattern, so wie sie im Projekt verwendet wird, ergibt folgende Konstruktion:

Die vom Publisher in den Message Channel veröffentlichte Nachricht wird durch den Message Router konsumiert (hier ein Content Based Router). Dieser kann anhand der Präsenz einzelner Felder in der Nachricht und deren Inhalt entscheiden, wohin die Nachricht weitergeleitet wird [HW03, S. 213]. Im Beispiel führt das dazu, dass die Nachricht nur an den oberen Publish-Subscribe Channel weitergeleitet wird. Da dieser wiederum nur von den oberen beiden Subscribern, jedoch nicht vom unteren abonniert wurde, erhalten auch nur sie die Nachricht.

Potential zur Umsetzung weiterer Patterns im Projekt

Es konnte auch Potential für die Integration von weiteren Pattern im Projekt gefunden werden. Das sind unter anderem das Message Store [Fo02, S. 487] und das Linked Service [DA11, S. 77] Pattern.

Durch das Message Store Pattern ist es möglich, versendete Nachrichten zentral vorzuhalten anstatt sie mit erfolgreicher Auslieferung und Verarbeitung zu löschen. So können im weiteren Projektverlauf hinzugefügte Applikationen die verpassten Nachrichten nachträglich konsumieren, um so auf einen konsistenten Stand kommen. Dies könnte zum Beispiel durch Verwendung von Apache Kafka als Message-Oriented Middleware umgesetzt werden.

Das Linked Service Pattern beschreibt, wie der Konsument eines Services nur auf Basis der empfangenen Antworten weitere Services und mögliche Anfragen innerhalb des aktuellen Service entdecken kann. Hierbei ist er resistent gegen Änderungen am Aufbau des Service oder dessen URLs. Dieses Pattern wird im zweiten Teil der Arbeit, im Rahmen einer Architektur aus Hypermedia APIs, beispielhaft implementiert. Ein weiterer Blogbeitrag wird das Pattern und die Beispielarchitektur genauer beschreiben.

Zusammenfassend lässt sich sagen, dass die Relevanz von Application Integration Patterns für Web Applications bestätigt wurde. Teile des untersuchten Projekts wurden bewusst anhand verschiedener Patterns aufgebaut, während andere Teile sich analog zu existierenden Patterns entwickelt haben.

Quellen

[AIS77] Christopher Alexander et al A Pattern Language: Towns, Buildings, Construction. Oxford University Press, 1977. ISBN: 9780195019193‍

[Fo02] Martin Fowler: Patterns of Enterprise Application Architecture. 1st edition. Addison-Wesley Professional, Nov. 2002. ISBN: 9780321127426‍

[HW03] Gregor Hohpe and Bobby Woolf: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. 1st edition. Addison-Wesley Professional, Oct. 2003. ISBN: 9780321200686‍

[Da11] Robert Daigneau: Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services. 1st edition. Addison-Wesley Professional, Nov. 2011. ISBN: 9780321544209