Dez20
lose Kopplung von Systemen

Verteilte, heterogene Systeme zu integrieren ist eine Aufgabe mit vielen Herausforderungen. Insbesondere die Interaktion und die Abhängigkeit zwischen den Systemen ist ein Problemfeld. Zur Lösung wird oft das Paradigma der losen Kopplung herangezogen. Was ist das, wie funktioniert das und was bedeutet dies für die Entwicklung und die Architektur?

Einführung

Problematik verteilter Systeme

Heutige IT Lösungen sind oft über mehrere Systeme verteilt und laufen nicht in einem Speicherbereich oder auf einer Plattform. Verteilte Systeme bringen eine ganze Reihe an Herausforderungen mit sich. Neben der Behandlung von Fehlern bei verteilten Aktionen ist auch die Performance, bei der Remote Kommunikation, ein wesentlicher Problempunkt. Da die einzelnen Systeme meist in verschiedenen Verantwortlichkeiten liegen und auf unterschiedlichen Plattformen laufen bringt dies weitere Anforderungen an Interaktion, Koordination und Verfügbarkeit mit sich. Im Vergleich zu Systemen die nicht verteilt und homogen sind, steigen die Kosten (z.B. Entwicklung, Laufzeit) für die Interaktion. In einer verteilten Systemlandschaft liegt der Schwerpunkt der Architektur nicht bei der Struktur des Systems, sondern bei der Interaktion zwischen den Systemen.

Call-Stack basiertes System

Call-Stack basiertes System

Die Abbildung „Call-Stack basiertes System“ zeigt ein Bestellsystem, das bei Eingang einer Bestellung

  1. im Warenhaus prüft, ob die Ware vorhanden ist
  2. die Kreditkarte über einen CreditService überprüft
  3. die Adresse des Kunden im Kundensystem ermittelt
  4. und zum Schluss, wenn alles erfolgreich ist, das Versandsystem beauftragt, die Waren zu versenden.

Das Bestellsystem ist abhängig vom Warenhaus, dem CreditService , dem Kundensystem und dem Versandsystem. Zudem ist der Prozess der Bestellung im Bestellsystem implementiert. Da die Verbindung zwischen den Systemen die Interaktion ist, sind hier die Ansätze zu finden, um die Abhängigkeiten zu minimieren. Um besser verstehen zu können, wie die Systeme loser gekoppelt werden können, werden zunächst Kommunikationsarten vorgestellt.

Dimensionen der Kopplung

Je enger die Kopplung zwischen zwei Systemen ist, desto mehr Prämissen gelten für die Kommunikation. Im folgenden Beispiel (Quelle EIP) sendet eine Web Applikation Daten an ein Finanz-System über eine direkte Socket-Verbindung, was einer sehr engen Kopplung entspricht.

Enge Kopplung

Enge Kopplung

Die Kopplung von Systemen kann in verschiedenen Dimensionen erfolgen. In diesem Beispiel findet die Kopplung in jeder der aufgelisteten Dimensionen statt:

  • Plattform Technologie: Beide Systeme müssen die interne Repräsentation von Zahlen und Objekten des anderen Systems verstehen
  • Lokation: Die Adresse unter der das Finanzsystem zu erreichen ist muss der Web Applikation bekannt sein
  • Zeit: Beide Systeme müssen zur selben Zeit verfügbar sein
  • Datenfomat: Die Schnittstelle in Form von Parametern und Datentypen beider Systeme müssen aufeinander abgestimmt sein.

Kommunikationsformen und Kommunikationstechniken

Bei der Entkopplung von Systemen spielt die Kommunikationsart eine große Rolle. Ein System, das eine Nachricht versendet, aber keine Kenntnis darüber hat, wer diese Nachricht wann verarbeitet, ist maximal entkoppelt. Dagegen ist es oft der Fall, das ein System auf die Antwort eines anderen Systems, für die weitere Verarbeitung, angewiesen ist. Wichtig ist dabei zwischen der Kommunikationsform (Fire & Forget, Request-Response) und der Kommunikationstechnik (synchron, asynchron) zu unterscheiden. Folgende Kommunikationsarten gibt es:

Fire & Forget

Fire & Forget

Fire & Forget

  1. A sendet Nachricht
  2. A setzt Verarbeitung fort
  3. B empfängt und verarbeitet Nachricht

Hier bietet sich eine asynchrone Kommunikationstechnik an (z.B. MQ)

Request – delayed Response

Request - delayed Response

Request – delayed Response

  1. A sendet Nachricht
  2. A setzt Verarbeitung fort
  3. B empfängt und verarbeitet Nachricht
  4. B sendet Antwort Nachricht
  5. A empfängt und verarbeitet Antwort Nachricht

Hier bietet sich eine asynchrone Kommunikationstechnik an (z.B. MQ).

Request-Response

Request - Response

Request – Response

  1. A ruft System B auf
  2. A unterbricht Verarbeitung und wartet
  3. B verarbeitet Aufruf und Antwortet
  4. A setzt Verarbeitung fort und verarbeitet Antwort

Hier bietet sich eine synchrone Kommunikationstechnik an (z.B. HTTP)

Lösungsansatz lose Kopplung

Entkopplung der Interaktion

Mit loser Kopplung sollen die Abhängigkeiten zwischen Systemen minimiert werden. Das heißt, dass bei der Integration mit einem System, möglichst wenig Prämissen für die Interaktion gelten und somit die Kommunikationspartner möglichst unabhängig voneinander sind. Im Kapitel „Dimensionen der Kopplung“ wurde die enge Kopplung zwischen einer Web Applikation und einem Finanz-System durch eine Socket-Verbindung gezeigt, sowie die Dimensionen der Kopplung.

Enge Kopplung

Enge Kopplung

Eine entkoppelte Integration löst diese Prämissen auf. Im folgenden wird eine asynchrone Nachricht von der Web-Anwendung zum Finanzsystem über einen Channel geschickt und somit eine Entkopplung erreicht.

Lose Kopplung

Lose Kopplung

Folgende Möglichkeiten der Entkopplung stehen zur Verfügung (als Unterpunkte zu den Entkopplungsmöglichkeiten sind Lösungsansätze aufgelistet):

  • Entkopplung der Schnittstelle (Datenformat)
    • Message / Event Versand
    • Mediation zwischen Schnittstellen
    • stabile Service-Schnittstelle, unabhängig von der API des Providers
  • Entkopplung der Kommunikations- / Transport-Technik
    • Mediation bzw. Adapter (z.B. MQ auf HTTP)
  • Entkopplung der System-Verfügbarkeit (Zeit)
    • Redundanter Datenbestand / Cache
    • asynchroner Message Versand (Puffer)
  • Entkopplung der Lokation der Systeme
    • Channel
    • DNS

Über die Entkopplung müssen die Systeme bei der Kommunikation weniger Kenntnisse voneinander haben, wodurch die Interaktion toleranter für Unterbrechungen und Änderungen wird. Dafür steigt die Komplexität der Lösung und die Effizientz (Performance) der Kommunikation sinkt. Diese Entkopplung der Interaktion lässt sich auch auf das Eingangs-Beispiel des Bestellsystems anwenden. Über Mediations können die Systeme bei der Kommunikation entkoppelt werden, wodurch das Bestellsystem weniger Kenntnis über die anderen Systeme hat. Es bleibt allerdings das Problem, dass der Prozess im Bestellsystem implementiert und koordiniert wird. Damit bleibt es entweder

  • bei einer synchronen Request-Response Kommunikation, wodurch die Systeme immer noch zeitlich voneinander Abhängig sind
  • oder das Bestellsystem muss eine asynchrone Kommunikation unterstützen und den Zustand der Bestellung speichern und die Verarbeitung unterbrechen, solange es auf die Antwort eines anderen Systems wartet.

Beide Alternativen sind nicht optimal. Es ist sinnvoll die Steuerung des Prozesses auszulagern und damit eine weitere Entkopplung des Bestellsystem zu erreichen.

Auslagerung der Steuerung

In der Abbildung „Call-Stack basiertes System“ ist deutlich zu sehen, dass das Bestellsystem die koordinierende Aufgabe hat. Über Request-Response Aufrufe werden die notwendigen Aktionen ausgeführt um die Bestellung durchzuführen. Dies führt zu einer hohen Abhängigkeit des Bestellsystems zu den angrenzenden Systemen in Bezug auf fachliche Schnittstellen als auch Verfügbarkeit. Um diese Abhängigkeiten aufzulösen, muss die Steuerung des Bestellablaufes, also des Prozesses, ausgelagert werden.

Bestellprozess

Bestellprozess

Das Bestellsystem startet bei Eingang einer Bestellung den Bestellprozess über eine asynchronen Nachricht. Die weitere Verarbeitung erfolgt in einer Prozess-Engine. hier werden die notwendigen Aktionen in der richtigen Reihenfolge durchgeführt. Es werden Zustände gespeichert, synchrone und asynchrone Kommunikation mit den Systemen unterstützt und die gesamte Interaktion zwischen den Systemen koordiniert. Die beteiligten Systeme haben somit keinerlei direkte Verbindung mehr untereinander und sind lose gekoppelt. Es spielt auch keine Rolle, ob die Interaktion synchron (Request-Response) oder asynchron (Request-delayed Response) erfolgt. Die Auslagerung der Koordination eines Prozesses ist somit ein wesentlicher Bestandteil der losen Kopplung.

Event Driven Architecture

Ein wesentlich radikalerer Ansatz ist, die Regeln der Interaktion und die Verantwortlichkeiten grundlegend zu ändern. Anstatt eine Nachricht an einen bestimmten Empfänger zu senden, oder in einem Prozess einzelne Systeme aufzurufen, wird ein Event gesendet bzw. auf einen EventBus gestellt. Nun weiß der Sender nicht mehr, welche Methode ausgeführt wird, noch wer die Nachricht verarbeitet. Das Bestellsystem sendet nur noch das Event „OrderReceived“, es startet nicht direkt den Bestellprozess über eine Nachricht, noch kennt die Prozess-Engine die Abhängigkeiten zwischen den Systemen.

Event basierte Systeme

Event basierte Systeme

Die Abbildung „Event basierte Systeme“ zeigt, wie eine Nachricht auf den Event Bus gestellt wird, an den verschiedene Systeme angebunden sind, die auf die Events reagieren können. Zusätzlich werden Events in einer Event Historie Datenbank gespeichert. Somit ist nachvollziehbar, welche Events wann aufgetreten sind. Auch eine Historienbildung ist damit möglich. Die Daten der Systeme müssen in einen bestimmten Ursprungszustand gebracht werden, anschließend können die Events aus der Event Historie Datenbank nochmal ausgeführt werden.

Beispiel Event basierte Systeme

Beispiel Event basierte Systeme

In der Abbildung „Beispiel Event basierte Systeme“ ist zu sehen, dass das Event „Order received“ vom Warenhaus (prüft ob die Ware vorhanden ist), dem Credit Service (prüft die Kreditkarte) und dem Versandsystem (versendet die Waren) empfangen wird. Das Versandsystem kann die Waren aber gemäß der Bestellung erst versenden, wenn es weiß, dass die Waren vorhanden sind und die Kreditkarte ok ist. Es muss also warten, bis das Warenhaus und der CreditService das Event „Order received“ verarbeitet und ihrerseits entsprechende Events versendet haben. In einer Call-Stack basierten Architektur oder in einer Prozess-Engine, werden die einzelnen Aktionen in der notwendigen Reihenfolge aufgerufen. In einer Event getriebenen Architektur müssen verschiedene Events kombiniert werden (Complex Event Processing) um eine weitere Aktion auszuführen. Im Beispiel werden die Waren versendet, wenn die Events  „Order received“, „Waren vorhanden“ und „Credit OK“ eingegangen sind. Diese Intelligenz kann entweder im Versandsystem oder in einem extra Koordinator implementiert sein. Im Vergleich zu einem Call-Stack oder einer Prozess-Engine ist dieser Ansatz jedoch deutlich komplexer und im Quellcode schwerer nachzuvollziehen. Im Beispiel ist zusätzlich zu sehen, dass das Versandsystem seine eigene read-only Kopie der Kundendaten hat und somit nicht abhängig ist von der Verfügbarkeit und der Schnittstelle des Kundensystems. Ändert sich eine Adresse im Kundensystem, wird ein Event „Adress Changed“ versendet. Das Versandsystem empfängt dieses Event und ändert seinen lokalen Kundenbestand. Auf dieses Event können sich auch weitere Systeme registrieren, die ebenso lokale Datenbestände haben oder sonst ein Interesse an einer Adressänderung. Der Sender, also das Kundensystem, ist davon unabhängig, welche Empfänger auf das Event „Adress Changed“ reagiert. Es können auch weitere Systeme hinzugefügt werden, ohne dass die vorhandenen davon betroffen sind (sofern das Event sich nicht ändert). Die Interaktion ist somit streng asynchron nach dem Fire & Forget Prinzip. Die Verantwortlichkeit wird vom Sender zum Empfänger übertragen. Nicht der Sender muss ein System aufrufen oder eine Nachricht an einen dedizierte Empfänger senden, sondern der Empfänger ist für die Reaktion auf ein Event und dessen Verarbeitung verantwortlich. Das Complex Event Processing bietet zudem interessante Möglichkeiten der Auswertung. Wenn ein Event „Kreditkartenzahlung“ von ein und dem selben Kunden innerhalb weniger Stunden aus Sydney in Australien und aus Stuttgart kommt, liegt vermutlich ein Kreditkartenbetrug vor. Auch technische Systeme wie ein ABS basieren auf einer Event Architektur. Sensoren publizieren Events, die von einer Steuereinheit ausgewertet werden. Z.B. ergeben die Events „Bremse betätigt“, „Geschwindigkeit Fahrzeug > 0“ und „Umdrehungsgeschwindigkeit Rad = 0“, dass das Rad beim Bremsen blockiert, woraufhin das Steuersystem die Bremse löst. Auch das tägliche menschliche Leben basiert auf Events. Wir reagieren auf Ereignisse, wie ein klingelndes Telefon, ein Hungergefühl oder auf den Eingang eines Versicherungsantrages. Event basierte Systeme sind somit etwas natürliches. Vorteil des Ansatzes ist die strenge lose Kopplung. Zudem skaliert das Gesamtsystem sehr gut, da es keinen zentralen Koordinator gibt, der sich als Nadelöhr entpuppen kann und kein System befindet sich in einem Wartezustand in dem laufende Threads blockiert sind wie bei einem Call-Stack. Nachteil ist, dass keine Transaktionsklammer gesetzt werden kann. Bei auftretenden Fehlern müssen Kompensationen durchgeführt werden, die einzelnen Systeme müssen Undo-Funktionen anbieten um die durch Events ausgelösten Aktionen im Fehlerfall rückgängig machen zu können. Ein weiterer Nachteil ist, dass durch das Fehlen eines Call-Stacks oder einer Prozess-Engine, eine Koordination der durchzuführenden Aktionen in einer Prozess- oder Ablaufkette extrem schwierig ist.

Prozesse und Events

Die goldene Lösung liegt, wie so oft, in der Mitte. Eine Kombination aus Prozess-Steuerung und Events ist in den meisten Fällen ideal. Wann immer keine Koordination und Reihenfolge der Events notwendig ist, bietet sich der Event basierte Ansatz an. Die Koordination, also das Complex Event Processing, kann auch für eine Event getriebene Architektur ausgelagert werden. Hier ist ein Ansatz , dass anstelle einer Prozess-Engine, eine State-Engine den Zustand einer Bestellung koordiniert und aufgrund von Events anpasst. Erst wenn ein definierter Zustand erreicht ist (Waren vorhanden und Kreditkarte geprüft), wird die Bestellung versendet. Auch eine Kombination aus Prozess und Events ist möglich.

Kombination Prozess und Event Driven Architecture

Kombination Prozess und Event Driven Architecture

Die Abbildung „Kombination Prozess und Event Driven Architecture“ zeigt diese Kombination. Das Bestellsystem sendet das Event „Order received“, welches von der Prozess-Engine empfangen wird und den Bestellprozess startet. Im Prozess werden die einzelnen Aktionen einer Bestellung koordiniert und am Schluss das Event „Bestellung geprüft“ gesendet. Dieses wird vom Versandsystem empfangen. Zusätzlich empfängt das Versandsystem das Event „Adress changed“ um die Kundendaten aktuell zu halten. Es bleibt somit festzuhalten, dass eine Prozess-Engine ein wesentlicher Bestandteil einer Integrations-Architektur ist, in der lose Kopplung ein angestrebtes Ziel ist.

Verkürzung der Kommunikationsstrecke

Oftmals ist eine synchrone Request – Response Kommunikation notwendig und kann nicht durch andere, asynchrone, Lösungen ersetzt werden. Dies ist meist bei lesenden Zugriffen der Fall, wobei die Performance hier auch ein kritischer Faktor ist, z.B. wenn ein Anwender vor dem Bildschirm auf die Antwort wartet oder in einem Batch Massendaten verarbeitet werden. Wenn bei einer Remote-Kommunikation über ein Netzwerk die Performance nicht garantiert werden kann, müssen beide Kommunikationspartner näher zusammengebracht und die Kommunikationsstrecke verkürzt werden. Am Beispiel einer HOST (Großrechner) – Java Kommunikation werden im folgenden verschiedene Ansätze aufgezeigt.

HOST ruft Java

HOST ruft Java

Die Abbildung „HOST ruft Java“ zeigt ein HOST-Modul, das ein Java Modul, das auf einer Middleware liegt, über eine synchrone Request – Response Kommunikation, aufruft. Das Java Modul liest Daten aus einer Datenbank und liefert diese mit der Response zurück. Die Kommunikation erfolgt über ein Netzwerk.

Cache

Die erste Möglichkeit die Kommunikations-Performance zu verbessern ist ein Cache.

HOST ruft Java mit Cache

HOST ruft Java mit Cache

Das HOST Modul schaut zuerst in einem lokalen Cache, ob die Daten dort vorhanden sind. Nur wenn nicht, werden die Daten remote vom Java Modul gelesen und zusätzlich in den Cache gestellt. Der Ansatz hat mehrere Nachteile. Die Performance wird nur verbessert, wenn die Daten wirklich im Cache vorhanden sind. Bei einer niedrigen Cache Hit Ratio ist keine Verbesserung der Performance zu erreichen. Zudem stellt die Aktualität der Daten im Cache ein Problem dar. Es muss eine Lösung gefunden werden, wie lange die Daten im Cache vorgehalten werden dürfen. Auf der anderen Seite ist dies eine sehr günstige Lösung.

WebSphere auf zOS

Eine weitere Möglichkeit ist, das Java Modul auf der HOST Infrastruktur auszuführen. WebSphere auf zOS bietet die Möglichkeit den WebSphere Application Server auf zOS auszuführen. Über den WOLA Adapter von IBM kann eine Speicher zu Speicher Kommunikation erfolgen zwischen dem HOST Modul und dem Java Modul.

HOST ruft Java auf WAS Z

HOST ruft Java auf WAS Z

Der Vorteil ist die extrem gute Performance, da keine Netzwerk-Kommunikation mehr stattfindet. Nachteil sind potentiell hohe Kosten für WAS Z und das nur der WebSphere Application Server für zOS zur Verfügung steht. Einen Tomcat oder JBoss kann man nicht verwenden.

HOST-Zugriffs-Modul

Anstatt das gesamte Java Modul auf den HOST zu bringen, wird nur die Datenbank auf den HOST verlagert. Neben dem Java Modul wird ein eigenes HOST basiertes Datenzugriffsmodul implementiert. Wichtig ist dabei, sicherzustellen, dass im HOST-Modul keine redundante Logik implementiert wird, sondern dies ausschließlich den Datenbankzugriff implementiert.

HOST mit eigenem Zugriffsmodul

HOST mit eigenem Zugriffsmodul

Vorteil ist auch hier eine extrem gute Performance. Nachteil ist, dass dies nur geht, wenn es sich um reine Datenzugriffe handelt. Wird Logik aus dem Java Modul benötigt, funktioniert dieser Ansatz nicht, da sonst die Logik redundant im HOST Modul implementiert werden müsste. Ein weiterer Nachteil ist, dass das HOST Modul und das Java Modul gemeinsam weiter entwickelt und produktiv geschaltet werden müssen, wenn sich das Datenmodell ändert.

Replizierter Datenbestand mit Update-Events

Die letzte Möglichkeit ist, auf dem HOST eine Datenbank zur Verfügung zu stellen, die unabhängig ist von der Datenbank des Java Moduls. Diese Datenbank wird über ein Update Event aktuell gehalten. Ändern sich die Daten in der Master-Datenbank des Java Moduls, wird ein Update-Event an das Replica des HOST-Modul gesendet, worauf die Daten aktualisiert werden. Wichtig ist, dass die Datenbank auf dem HOST read-only ist. Updates dürfen nur über das Java Modul erfolgen.

HOST mit eigener DB und UpdateEvent

HOST mit eigener DB und UpdateEvent

Vorteil ist die sehr gute lese Performance und die Entkopplung des HOST Moduls von dem Java Modul. Nachteil ist, dass es bei sehr häufigen Änderungen zu Performanceproblemen kommen kann. Auch sind Updates darüber nicht möglich.

Fazit

Lose Kopplung bietet einen Weg um die Abhängigkeit von Systemen zu minimieren. Für die Interaktion zwischen Systemen gelten weniger Prämissen und sie wird toleranter für Unterbrechungen und Änderungen in den Systemen. Dafür steigt die Komplexität und die Performance der Kommunikation sinkt. Wie viel lose Kopplung bei der Interaktion sinnvoll ist, ist somit eine Abwägung zwischen Effizientz, Komplexität und Fehlertoleranz.

Waage der Kopplung

Waage der Kopplung

Problematik von klassischen Altsystemen

Das Problem bei vielen klassischen Altsystemen ist, dass bei diesen meist die Steuerung in einem Fachsystem über einen Call-Stack implementiert ist. Bei HOST-Systemen oftmals auch unter der Prämisse, dass der komplette Ablauf in einer Transaktion ausgeführt wird. Die Systeme sind damit nicht darauf vorbereitet, dass sie mit Fehlern in einzelnen Teilschritten umgehen müssen, da durch die Transaktion entweder alles oder gar nichts durchgeführt wird. Auch sind die Altsysteme oft auf die Daten in der Rückantwort der angrenzenden Systeme angewiesen, da diese im nächsten Arbeitsschritt verarbeitet werden. Kurz gesagt, klassische Architekturen setzen auf eine synchrone Request – Response Kommunikation auf, sowohl bei lesender als auch bei schreibenden Kommunikation. Erschwert wird diese Problematik wenn IMS basierte Systeme einen Call out auf nicht IMS Systeme machen müssen. In der Zeit zwischen Request und Response ist die komplette IMS Region blockiert. Extrem performante Interaktionen sind hier somit gefordert. Lose Kopplung, und die Steigerung in Form der Event basierten Architektur, setzt eine komplett andere Denkweise voraus als bei synchronen Request – Response Ansätzen. Bei einem Altsystem, das auf synchronem Request – Response aufsetzt, ein Subsystem herauszulösen und dieses über eine lose, asynchrone Kopplung anzubinden bedeutet, die Architektur des Systems zu ändern. Ein solcher Architektur-Change ist aufwendig und teuer und kann nicht immer durchgeführt werden. Dies bedeutet, dass es Bedarf an synchroner Request – Response Kommunikation gibt solange Altsysteme angebunden werden müssen, bei denen ein Architektur-Change nicht durchgeführt werden kann.

Szenarien

Nach der grauen Theorie jetzt noch zwei konkrete Szenarien um die Theorie zu veranschaulichen.

lesender Zugriff HOST -> SAP

Das Szenario zeigt ein Bestandssystem auf dem HOST, das Kundendaten vom SAP basierten Geschäftspartner benötigt.

HOST ruft SAP remote und synchron

HOST ruft SAP remote und synchron

In diesem Szenario benötigt das Bestandssstem auf dem HOST lesenden Zugriff auf die Geschäftspartnerdaten im SAP. Der Zugriff erfolgt mit einer synchronen Request – Response Kommunikation, da die Daten sofort und ohne Verzögerung benötigt werden. Wenn die Performance auf der Netzwerkstrecke und auch die Verfügbarkeit von SAP nicht garantiert werden kann, muss die Interaktion entkoppelt und die Kommunikationsstrecke verkürzt werden.

HOST liest SAP Daten aus Replica

HOST liest SAP Daten aus Replica

Die Abbildung „HOST liest SAP Daten aus Replica“ zeigt die Lösung eines redundanten Datenbestandes der Geschäftspartnerdaten auf dem HOST. Auf diese Daten greift das Bestandssystem lokal und ausschließlich read-only zu. Damit ist eine hohe Performance gewährleistet und eine Unabhängigkeit von der Verfügbarkeit des SAP Systems. Änderungen in den Geschäftspartnerdaten dürfen nur im SAP System durchgeführt werden. Diese werden über ein asynchrones Update Event publiziert. Daraufhin wird der Datenbestand auf dem HOST aktualisiert. Dies führt zusätzlich zu einer Unabhängigkeit von der Verfügbarkeit des HOST Systems im SAP.

Im folgenden die Vor- und Nachteile dieser Lösung:

thumbs_upHOST System hat lokalen und performanten Zugriff auf die Daten (kein Problem mit blockierter IMS Region)

thumbs_up HOST System ist unabhängig von der Schnittstelle und der Verfügbarkeit des SAP Systems

thumbs_up SAP System ist unabhängig von der Verfügbarkeit des HOST Systems bei Datenänderungen

thumbs_up HOST ist unabhängig von Datenmodell- / Schnittstellenänderungen im SAP System

thumbs_up weitere Nutzer können sich auf das Update Event registrieren und lokale Daten updaten (Publish-Subscribe)

thumbs_down initiales Befüllen des replizierten Datenbestandes

thumbs_down Performance Issue bei häufigen Updates des Datenbestandes

thumbs_down Gefahr, dass weitere Attribute im Replica aufgenommen werden, die es nicht im Master-Datenbestand gibt (anderes Datenmodell im Replica als im Master) und dritte Systeme Interesse an diesen zusätzlichen Attributen haben und die Geschäftspartnerdaten vom Bestandssystem beziehen anstatt vom SAP

Kommunikation Java <-> HOST

Das Szenario zeigt ein Java Modul das schreibend und lesend auf und ein HOST Modul zugreift. Ideal wäre im schreibenden Fall eine lose Kopplung über eine asynchrone fire & forget oder Request – delayed Response Kommunikation. im Szenario ist dies nicht möglich und eine synchrone Request – Response Kommunikation ist notwendig. Es wird eine Mediation zwischen dem Java und dem HOST Modul eingefügt, um die Systeme voneinander zu entkoppeln.

Java -> HOST Kommunikation über Mediation

Java -> HOST Kommunikation über Mediation

Im Szenario wird die Mediation auf einem ESB-Produkt, z.B. IBM WebSphere ESB,  ausgeführt wird. Die Kommunikation zwischen Java Modul und ESB erfolgt über HTTP, die Kommunikation zwischen ESB und HOST über MQ.

Java -> HOST Kommunikation über ESB Mediation und MQ

Java -> HOST Kommunikation über ESB Mediation und MQ

Hierbei erfolgt zweimal eine Kommunikation über ein Netzwerk. Zudem wird die asynchrone Kommunikationstechnik MQ für eine Request – Response Kommunikation verwendet, wobei ein synchrones Verhalten simuliert wird, da die Mediation im ESB auf die MQ Antwort wartet. Hierfür gibt es mit IMSConnect eine geeignetere Technologie.

Java -> HOST Kommunikation über ESB Mediation und IMSConnect

Java -> HOST Kommunikation über ESB Mediation und IMSConnect

Die Umstellung auf IMSConnect zeigt auch den Vorteil der losen Kopplung über eine Mediation. Für das Java Modul ändert sich nichts. Die Schnittstelle bleibt identisch und auch der Aufruf über HTTP. Das Szenario wird erweitert um eine Kommunikation vom HOST Modul zum Java Modul und um den Bedarf einer extrem hohen Performance in der Kommunikation. Die Lösung ist WebSphere auf zOS.

Java -> HOST Kommunikation über WAS Z Mediation

Java -> HOST Kommunikation über WAS Z Mediation

Das Grundprinzip bleibt das Gleiche wie bisher. Das Java Modul und das HOST Modul werden über eine Mediation entkoppelt. Der Unterschied ist, dass alle Komponenten auf der HOST Infrastruktur ausgeführt werden und keine Kommunikation über ein Netzwerk stattfindet, was zu einer hohen Performance führt. Zusätzlich ist so eine bidirektionale Kommunikation möglich, also nicht nur Java ruft HOST, sondern auch HOST ruft Java. Die komplette Verarbeitung kann durch den Einsatz von WAS Z in einer über Java und HOST Modul übergreifenden Transaktionsklammer ausgeführt werden.

Weiterführende Informationen

[Update 23.12.2013: Die Bilder des Artikels werden jetzt angezeigt]

Ein Kommentar zu “
Dez20
lose Kopplung von Systemen

  1. Pingback: Event Driven Architecture | discoveration

Schreibe einen Kommentar

Anmelden um einen Kommentar abzugeben.

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*