Flex Gateway Neu
API Governance Neu
Monitoring API ManagerWenn Sie Integrationsexperte sind, haben Sie wahrscheinlich bereits Integrationsdesignmuster verwendet oder implementiert. Es stehen mehrere Dutzend Muster zur Verfügung – von kanonischen Datenmodellmustern und Fassadendesignmustern bis hin zu Messaging-, Routing- und Kompositionsmustern.
All diese Integrationsdesignmuster dienen als „Formel“ für Integrationsfachleute, die damit dann Daten, Anwendungen, Systeme und Geräte erfolgreich miteinander verbinden können. Diese Muster werden wir im Folgenden an einem Integrationsdesignmuster veranschaulichen, das in Service-Driven Approaches to Architecture and Enterprise Integration vorgestellt wird.
Integrationsdesignmuster „Kanonisches Datenmodellmuster“
Das kanonische Datenmodell wird als „ältestes“ Integrationsdesignmuster angesehen. Bei diesem Muster wird ein Messaging- oder Datenmodell erstellt, das von Benutzern direkt oder indirekt genutzt werden kann. Die Daten und/oder die Nachrichten werden dann über eine Integrationsplattform (zum Beispiel einen Enterprise Service Bus) weitergeleitet und dort anschließend in ein kanonisches Standardformat konvertiert.
Dieses Integrationsdesignmuster wird in Unternehmen aus verschiedenen Gründen häufig verwendet. Zunächst einmal reduziert es die Wartungskosten eines Unternehmens maßgeblich. Darüber hinaus verringert es auch die „Lernkurve“ der Integration, da Integrationsfachleute keine neuen Datenstrukturen verstehen müssen. Stattdessen können sie mit dem kanonischen Modell arbeiten und Integrationsprojekte schneller abschließen.
Es gibt jedoch auch einen Nachteil: Das kanonische Integrationsdesignmuster ist zeitaufwendig, da das Modell von Grund auf neu erstellt werden muss.
Integrationsdesignmuster „Fassadendesignmuster“
Ein zweites Beispiel für ein Integrationsdesignmuster ist das Fassadenmuster. Dieses Muster soll einige der Nachteile des kanonischen Datenmodellmusters beseitigen. Dazu werden vereinfachte Schnittstellen ohne kanonische Modelle definiert. Im Hintergrund werden die Nachrichten in diesen Schnittstellen jedoch in das kanonische Modell konvertiert.
Ein Vorteil dieses Integrationsdesignmusters besteht darin, dass die Schnittstellen nicht auf dem kanonischen Modell basieren. Daher wirken sich an dem kanonischen Modell vorgenommene Änderungen nicht direkt auf die Schnittstellen und ihre Benutzer aus. Unternehmen müssen also nicht alle Schnittstellen ändern, die auf diesem Modell beruhen.
Ein Nachteil des Designmusters der Fassadenintegration besteht darin, dass es zu erhöhten Wartungsressourcen und -kosten führt. Dies liegt daran, dass im Gegensatz zum kanonischen Datenmodellmuster sowohl die Umwandlungs- als auch die Integrationslogik verwaltet und gewartet werden müssen.
Nutzung von Integrationsdesignmustern
Kanonische Datenmodellmuster gehören zu den vielen verschiedenen verwendeten Integrationsdesignmustern. Jedes Muster dient einem spezifischen Zweck – zum Beispiel der Übermittlung von Ereignissen zwischen Anwendungen oder der Verwendung von Anwendungsnachrichten, sobald sie verfügbar werden.
Für eine effiziente Nutzung von Integrationsdesignmustern müssen Sie zunächst einen neuen Integrationsansatz einführen: API-led Connectivity. Erfahren Sie mehr über API-led Connectivity und die Anwendung dieses Ansatzes bei der Implementierung von Integrationsdesignmustern.