Kommunikation
In einer Systemlandschaft ist Kommunikation ein Element, das die technische Architektur prägt. Die Art und Weise, wie IT-Systeme miteinander kommunizieren, bestimmt maßgeblich ihre Effizienz, Wartbarkeit und Zuverlässigkeit. Ein technischer Blick auf die Kommunikation schafft Klarheit über:
-
die Kopplungsgrade zwischen Systemen, und damit über die Flexibilität bei sich ändernden Anforderungen,
-
die Fehlertoleranz und Resilienz, etwa durch die Wahl zwischen synchronen und asynchronen Kommunikationsmustern, und
-
das Lastverhalten und Antwortzeiten, entscheidend für die Nutzererfahrung und Stabilität.
Die Festlegungen hinsichtlich der Kommunikation sind strategische Architekturentscheidungen für die Umsetzung einer Systemlandschaft. Werden die Entscheidungen nicht oder implizit getroffen, erhöht sich das Risiko schwer wartbarer Abhängigkeiten, ineffizienter Schnittstellen und insgesamt einer Architektur, die den Anforderungen an moderne, behördliche Informationssysteme nicht gerecht wird.
1. Grundlagen
IT-Systeme kommunizieren auf Basis von Services. Wenn ausschließlich IT-Systeme innerhalb der Systemlandschaft miteinander kommunizieren, spricht die Referenzarchitektur von interner Servicekommunikation. Wenn die Kommunikation auch Systeme einschließt, die außerhalb liegen, verwendet die Referenzarchitektur den Begriff externe Servicekommunikation.
1.1. Metadaten und Nutzdaten
IT-Systeme tauschen in der Kommunikation untereinander Daten aus. Diese lassen sich in Metadaten und Nutzdaten unterteilen.
Metadaten können technischer oder fachlicher Natur sein. Sie sind nicht mit einer konkreten Anfrage verknüpft und werden in der Regel mit jedem Aufruf einer Schnittstelle übertragen. Zu den Metadaten gehören u.a.:
-
Daten zu übergreifenden Aspekten der Servicekommunikation wie z.B. Caching oder das Aushandeln von Formaten,
-
IDs zum Tracing von Service-Aufrufen,
-
Daten zur Authentifizierung und Autorisierung, oder
-
Metadaten dritter Systeme, die durchgeschleift werden.
Metadaten werden in der Regel in Klartext übertragen und nicht verschlüsselt oder anderweitig kodiert.
|
Die Verwendung von externen Standards bleibt davon unberührt. So überträgt der Standard OAuth 2 beispielsweise Informationen zur Autorisierung einer Anfrage BASE64-kodiert. |
Die Übertragung von Metadaten geschieht in der Regel über Schlüssel-Wert-Paare (englisch: key-value pairs), z.B. in HTTP-Headern oder JMS-Properties.
Die folgende Tabelle zeigt, welche Metadaten in der IsyFact standardisiert übertragen werden.
| Metadaten | Benennung | Herleitung |
|---|---|---|
Korrelations-ID |
|
ID zur Nachverfolgung von Aufrufen innerhalb einer Anwendungslandschaft. |
Bearer Token |
|
Vorgabe des Standards OAuth 2.0. |
Nutzdaten auf der anderen Seite beinhalten alle Daten, die zur Verarbeitung eines konkreten Service-Aufrufs benötigt werden. Sie bilden die eigentliche, fachliche Schnittstelle und beschreiben sowohl die Daten der Anfrage sowie der Antwort.
Die IsyFact standardisiert die Art und Weise, wie Nutzdaten spezifiziert, dokumentiert und technisch verarbeitet werden.
1.2. Kommunikationsarten
Ein zentrales Element der technischen Architektur ist die Wahl geeigneter Kommunikationsmuster zwischen IT-Systemen. Kommunikationsmuster ordnen sich synchroner Kommunikation und asynchroner Kommunikation zu. Die Wahl der Kommunikationsmuster beeinflusst direkt die technische Architektur und Umsetzung der IT-Systeme. Die gewählten Kommunikationsmuster tragen ebenso maßgeblich dazu bei, die Qualitätskriterien der Architektur und der IT-Systeme zu erfüllen.
Die IsyFact empfiehlt grundsätzlich den Einsatz asynchroner Kommunikation, insbesondere bei der Umsetzung verteilter Systeme, zeitkritischer Prozesse, der Verarbeitung großer Datenmengen und der Realisierung skalierbarer und resilienter Architekturen. Die Entscheidung für ein Kommunikationsmuster muss jedoch kontextabhängig und anhand der geforderten Qualitätskriterien der Architektur und der IT-Systeme erfolgen.
1.2.1. Synchrone Kommunikation
Synchrone Kommunikation eignet sich besonders gut zur Umsetzung von vergleichsweise einfachen, gut überblickbaren und stark gekoppelten Abläufen oder Anwendungen bei denen eine einfache Implementierung das zentrale Kriterium ist. Aufgrund der Tatsache, dass der Sender auf die Antwort des Empfängers wartet, sind Transaktionen, die mehrere IT-Systeme umfassen, bis zu einem gewissen Grad beherrschbar.
Synchrone Kommunikation ist häufig in Form des Request-Response-Musters umgesetzt. Dies befähigt Sender und Empfänger, querschnittliche Aspekte wie Sicherheit, Logging oder Fehlerbehandlung direkt und vollumfänglich umzusetzen. Dies wiederum wirkt sich positiv auf die Sicherheit, Zuverlässigkeit und Wartbarkeit der IT-Systeme aus.
Synchron kommunizierende IT-Systeme sind ebenso einfacher in eine Systemlandschaft zu integrieren, da sie in der Regel keine zusätzlichen Infrastrukturkomponenten benötigen. Sie sind, geeignete Kommunikationsstandards vorausgesetzt, interoperabel und besitzen eine hohe Kompatibilität.
1.2.1.1. Herausforderungen
Die Tatsache, dass der Sender auf die Antwort des Empfängers wartet, kann zu Wartezeiten und, letztendlich, zu Skalierungsproblemen führen. Dieser Effekt verstärkt sich durch verschachtelte Aufrufe oder Kaskaden. Er steht hohen Anforderungen an die Effizienz von IT-Systemen entgegen.
Ebenso wirken sich Fehler oder Ausfälle des Empfängers direkt auf den Sender aus. Geschehen Fehler oder Ausfälle an viel genutzten Stellen, oder innerhalb einer Verkettung von Aufrufen, kann sich dies auf weite Teile der Systemlandschaft auswirken und erhebliche Auswirkungen auf deren Zuverlässigkeit besitzen.
1.2.2. Asynchrone Kommunikation
Asynchrone Kommunikation ermöglicht die Umsetzung komplexer und voneinander entkoppelter Abläufe. Die Wahl des Kommunikationsmusters entscheidet darüber, ob die Verantwortung der Verwaltung von Nachrichten bei dafür spezialisierten Infrastrukturkomponenten liegt, und ob sich Sender und Empfänger gegenseitig kennen.
Die Entkopplung von Sender und Empfänger ermöglicht eine bessere Lastverteilung und Skalierbarkeit. Dies wirkt sich positiv auf die Effizienz der IT-Systeme aus.
Asynchrone Kommunikationsflüsse sind robuster gegenüber temporären Ausfällen einzelner IT-Systeme, da Nachrichten zwischengespeichert und später verarbeitet werden können. Dies erhöht die Zuverlässigkeit der gesamten Systemlandschaft.
1.2.2.1. Herausforderungen
Aufgrund des hohen Grades an Entkopplung herrscht in einer asynchron kommunizierenden Systemlandschaft eventual consistency als eine Form schwacher Konsistenz vor. Dies müssen alle asynchron kommunizierenden IT-Systeme berücksichtigen.
Asynchron kommunizierende IT-Systeme benötigen in der Regel zusätzliche Infrastrukturkomponenten und integrieren sich daher nicht so leicht in eine bestehende Systemlandschaft. Zur Nachrichtenübermittlung ist meist eine Infrastrukturkomponente für Messaging oder Event Streaming vorhanden. Die Nachvollziehbarkeit von Abläufen ist komplexer, da Kommunikationsflüsse nicht linear verlaufen und Zustände verteilt sein können, und erfordert ein geeignetes Tracing und Monitoring. Die zusätzlichen Infrastrukturkomponenten müssen in die Umsetzung querschnittlicher Aspekte wie Sicherheit, Zuverlässigkeit und Wartbarkeit einbezogen werden.
2. Kommunikationsmuster
Die Referenzarchitektur sieht die folgenden Kommunikationsmuster zur Kommunikation zwischen IT-Systemen vor: Request-Response, Message-Queue sowie Publish/Subscribe mit der Unterform Event Streaming.
2.1. Request-Response
Das Request-Response-Muster bietet die Möglichkeit der direkten Kommunikation zwischen zwei IT-Systemen. Hierbei schickt der Sender eine Anfrage (englisch: request) an den Empfänger. Der Empfänger bearbeitet die Anfrage und schickt eine Antwort (englisch: response) an den Sender zurück.
Je nachdem, ob Sender oder Empfänger synchron oder asynchron miteinander kommunizieren, wartet der Sender auf die Antwort, bevor er seine Verarbeitung fortsetzt, oder nimmt die Verarbeitung frühestens durch die Antwort des Empfängers wieder auf. Ob zwei IT-Systeme synchron oder asynchron über Request-Response miteinander kommunizieren, muss anhand der zu erfüllenden Qualitätskriterien abgewogen werden. Die Abwägung muss während der Erstellung des Systementwurfs geschehen.
Das Request-Response-Muster ist gut verstanden und wird von einer Vielzahl an Technologien, Frameworks und Werkzeugen unterstützt. Es ist aufgrund seiner einfachen Struktur verständlich und vergleichsweise leicht umsetzbar. Das Muster ist gut für Interaktionen zwischen Backends und Frontends geeignet, bei denen eine direkte Antwort mit klar definiertem Zeitverhalten erwartet wird, oder es in kurzer Zeit eine Vielzahl von kleineren, klar definierten Interaktionen gibt.
2.1.1. Stärken
Das Request-Response-Muster erfüllt bei stabilen Netzwerken und kurzen Verarbeitungszeiten auch hohe Anforderungen zur Zuverlässigkeit. Fehler lassen sich direkt anhand der Antwort erkennen und behandeln. Die Kommunikation zwischen zwei IT-Systemen ist klar definiert und leicht nachvollziehbar, was sich positiv auf die Wartbarkeit auswirkt. Anforderungen an die Sicherheit lassen sich leicht und gezielt durch Mechanismen wie Authentifizierung und Autorisierung erfüllen.
2.1.2. Herausforderungen (synchron)
Da im synchronen Fall der Sender blockiert, bis die Antwort vom Empfänger kommt, kann dies zu Skalierungsproblemen führen. Die Latenz und der Durchsatz sind in diesem Fall begrenzt, oder der Sender läuft in einen Timeout. Diese Effekte verstärken sich, wenn der Empfänger viel Zeit für die Verarbeitung der Anfrage benötigt, oder dazu weitere, kaskadierende Aufrufe tätigt. Empfänger wiederum skalieren auch nur begrenzt, insbesondere bei vielen gleichzeitigen Anfragen. Sie müssen jede Anfrage sofort bearbeiten, was Ressourcen bindet. Hohe Qualitätsanforderungen im Bereich der Effizienz können unter diesen Umständen schwer zu erfüllen sein.
Im synchronen Fall berücksichtigt die Fehlerbehandlung fachliche und technische Fehler beim Empfänger, aber in der Regel keine Ausfälle der Netzwerke oder Infrastruktur. Solche Fehler, besonders im Fall von kaskadierenden Aufrufen, benötigen eine robuste Fehlerbehandlung. Hohe Qualitätsanforderungen im Bereich der Zuverlässigkeit können unter diesen Umständen schwer zu erfüllen sein.
2.1.3. Herausforderungen (asynchron)
Den Herausforderungen im synchronen Fall können IT-Systeme dadurch begegnen, indem sie das Request-Response-Muster asynchron anwenden. Hierbei ergeben sich, im Wesentlichen aus der Entkopplung von Anfrage und Antwort, andere Herausforderungen. Während bei den anderen Kommunikationsmustern Infrastrukturkomponenten diese Herausforderungen auffangen, fallen sie beim Request-Response-Muster Sender und Empfänger zu.
Durch die Asynchronität erfolgen die Antworten nicht direkt, sondern zeitverzögert, und nicht zwingend in der Reihenfolge der Anfragen. Der Sender muss die Antworten aktiv beziehen (oder einen Callback anbieten), richtig zuordnen und Nebenläufigkeiten sowie Antworten in beliebiger Reihenfolge verarbeiten können. Dies kann Auswirkungen auf die funktionelle Eignung haben.
Für eine Erfüllung hoher Qualitätsanforderungen im Bereich der Zuverlässigkeit sollte die asynchrone Verarbeitung durch eine robuste Fehlerbehandlung unterstützt werden. Hier stehen eine Vielzahl von Resilienz-Mustern zur Verfügung.
|
Eine gute Einführung zu Resilienz mit Verweisen auf weitere Quellen findet sich unter: 10 patterns for more resilient applications: a gentle start into resilient software design |
2.1.4. Vorgaben
Das Request-Response-Muster wird in der IsyFact auf Basis von REST umgesetzt.
Aufrufe nach dem Request-Response-Muster finden über das Protokoll HTTP statt und werden sowohl zur internen als auch externen Servicekommunikation genutzt. HTTP-Anfragen bzw. HTTP-Antworten erlauben es an drei Stellen, anwendungsspezifische Daten zu übertragen: in der URL, in den Headern sowie im Body.
Header enthalten Metadaten.
Der Body enthält Nutzdaten.
Bei Anfragen mittels GET und DELETE, die keinen Body erwarten, enthalten URL-Parameter Nutzdaten.
Allerdings gilt zu beachten, dass URLs (und damit auch die URL-Parameter) an vielen Stellen aufgezeichnet und in Logs geschrieben oder in Caches gehalten werden.
Hierbei sind z.B. datenschutzrechtliche Aspekte zu prüfen, wenn URL-Parameter personenbezogene Daten enthalten.
Im Zweifelsfall ist die Methode POST die empfohlene Alternative, um solche Nutzdaten im Body zu übertragen.
2.2. Message-Queue
Das Kommunikationsmuster Message-Queue ist ein asynchrones, entkoppeltes Kommunikationsmodell. Es basiert auf dem Prinzip, dass ein Sender eine Nachricht in eine Warteschlange (englisch: queue) stellt, die vom Empfänger zu einem späteren Zeitpunkt verarbeitet wird. Dies entkoppelt Sender und Empfänger voneinander.
Das Kommunikationsmuster Message-Queue eignet sich für Interaktionen, die keine direkte Antwort benötigen, keine hohen Anforderungen an das Zeitverhalten stellen und robust gegenüber Fehlern sein müssen. Das Message-Queue-Muster benötigt eine Infrastrukturkomponente, den Message-Broker, welche die Kommunikation zwischen Sender und Empfänger ermöglicht. Zur Umsetzung der Infrastrukturkomponente gibt viele bewährte Produkte, die auch hohe Anforderungen an die Kommunikation über Message-Queues erfüllen.
2.2.1. Stärken
Message-Broker nehmen Sender und Empfänger viele Aufgaben ab und erledigen sie zuverlässig an zentraler Stelle. Sie speichern Nachrichten persistent und überbrücken so Ausfälle der Empfänger. Außerdem übernehmen sie Wiederholungsversuche, kümmern sich um unzustellbare Nachrichten und garantieren die Zustellung der Nachrichten. Message-Broker können so die Zuverlässigkeit der Kommunikation der IT-Systeme untereinander maßgeblich positiv beeinflussen.
Sender und Empfänger können durch die lose Kopplung unabhängig voneinander skalieren. Sender werden nicht durch langsame Empfänger blockiert, was Engpässe reduziert und den Gesamtdurchsatz des Systems verbessert. Message-Broker ermöglichen zudem eine Lastverteilung, indem Instanzen des Empfängers dynamisch hinzugefügt oder entfernt werden. Dies hat eine positive Auswirkung auf die Leistungseffizienz der Sender und Empfänger. Durch die lose Kopplung sind außerdem Änderungen an Sender oder Empfänger isoliert möglich, solange das Nachrichtenformat stabil bleibt. Dies wirkt sich positiv auf die Wartbarkeit der Sender und Empfänger aus.
2.2.2. Herausforderungen
Message-Broker sind zentrale Infrastrukturkomponenten. Um ihre Stärken konsequent zu nutzen, müssen sie korrekt konfiguriert und betrieben werden.
Ein Ausfall oder temporäre Störungen des Message-Brokers wirken sich direkt nachteilig auf die Zuverlässigkeit der Kommunikation von weiten Teilen der Systemlandschaft aus. Zur Minderung dieser Risiken sollte der Message-Broker redundant betrieben werden. Außerdem sollten Maßnahmen gegen eine Überlastung des Brokers getroffen werden.
Message-Broker sind sicherheitskritische Infrastrukturkomponenten. Sie müssen entsprechend abgesichert werden, da sie Nachrichten von vielen Systemen verarbeiten und speichern. Nachrichten können potenziell im Message-Broker abgefangen oder manipuliert werden. Zur Minderung dieser Risiken sind zusätzliche Sicherheitsmaßnahmen wie Signierung, Verschlüsselung oder Zugriffskontrollen nötig.
Message-Broker sollten nach dem Prinzip at-least-once funktionieren: Die Zustellung der Nachrichten wird garantiert, aber Duplikate sind möglich. Schreibende Operationen, die durch Nachrichten ausgelöst werden, sind dementsprechend idempotent zu spezifizieren und umzusetzen.
Die unter Stärken beschriebene Lastverteilung benötigt ein entsprechendes Monitoring sowie eine Möglichkeit zur dynamischen Skalierung des Empfängers. Sind diese nicht vorhanden, und der Empfänger kann die Nachrichten nicht schnell genug verarbeiten, führt dies zu potenziell unbegrenzt anwachsenden Queues, die in Folge wiederum Speicher- oder Stabilitätsprobleme für den Message-Broker bedeuten.
2.2.3. Vorgaben
Message-Broker müssen JMS (Jakarta Messaging, ehemals Java Message Service) unterstützen. Das Muster Message Queue wird ausschließlich in der Kommunikation innerhalb der Systemlandschaft eingesetzt.
JMS-Nachrichten bestehen aus Header, Properties und einem Body. Die Properties unterteilen sich noch einmal in applikationsspezifische Properties, die nur für Publisher und Subscriber Bedeutung haben, sowie provider-spezifische und Standard-Properties, die zur Verarbeitung der JMS-Nachrichten durch den Message-Broker gedacht sind.
Applikationsspezifische Properties enthalten Metadaten. Der Body enthält Nutzdaten. Nutzdaten werden im XML-Format übertragen und mittels XSD spezifiziert.
Diese Vorgabe steht vollständig in Einklang mit der JMS-Spezifikation.
Für die Übertragung von Nutzdaten sieht die JMS-Spezifikation fünf Formate vor.
Die Architekturvorgabe sieht die alleinige Nutzung der Ausprägung TextMessage vor, die Nutzdaten als Zeichenkette erwartet.
|
Weitere Details zu JMS-Nachrichten finden sich in der JMS-Spezifikation im Kapitel 3. Jakarta Messaging message model. Besonders relevant für die Referenzarchitektur sind die Abschnitte 3.3. Jakarta Messaging messages sowie 3.11. Jakarta Messaging message body. |
2.3. Publish/Subscribe
Das Kommunikationsmuster Publish/Subscribe (Pub/Sub) ist ein asynchrones, ereignisgesteuertes Modell. Es ermöglicht die Entkopplung von Sendern (Publishern) und Empfängern (Subscriber), indem Nachrichten durch Publisher an ein zentrales Thema (Topic) veröffentlicht und von mehreren Subscribern abonniert werden können. Publisher und Subscriber kennen sich nicht.
Publish/Subscribe eignet sich gut, wenn es um die Verteilung von Ereignissen (englisch: events) an mehrere Subscriber geht. Ereignisse übermitteln zum Beispiel Benachrichtigungen oder Zustandsänderungen und benötigen keine Antwort des Subscribers.
2.3.1. Stärken
Publish/Subscribe unterstützt die gleichzeitige Zustellung von Nachrichten an mehrere Subscriber und ermöglicht dadurch effiziente parallele Arbeitsabläufe. Dies wirkt sich positiv auf die Leistungseffizienz beider Kommunikationsteilnehmer aus.
Publisher und Subscriber sind voneinander entkoppelt. Publisher arbeiten unabhängig von den Subscribern, was eine einfache Erweiterung oder Entfernung von Subscribern erlaubt. Änderungen an Publisher und Subscriber sind isoliert möglich, solange das Format der Nachrichten stabil bleibt. Dies wirkt sich positiv auf die Wartbarkeit der Publisher und Subscriber aus.
2.3.2. Herausforderungen
Das Muster Publish/Subscribe benötigt ebenso einen Message-Broker als zentrale Infrastrukturkomponente. Demnach bestehen Ähnlichkeiten zu den Herausforderungen des Musters Message-Queue.
Darüber hinaus ist in der Regel nicht garantiert, dass alle Subscriber eine Nachricht erhalten. Bei temporärer Nichtverfügbarkeit eines Subscribers können Nachrichten verloren gehen, sofern keine Persistenz oder Replay-Mechanismen vorhanden sind. Die Einhaltung von Konsistenzkriterien über mehrere Subscriber hinweg erfordert robuste Mechanismen für den Umgang mit Teilfehlern und erneuter Zustellung.
Ebenso gibt es in der Regel keine Garantie für eine (globale) Reihenfolge der Nachrichten. Wenn diese wichtig ist, lohnt sich ein Blick auf Event Streaming.
Schließlich darf der Inhalt von Nachrichten nur Informationen beinhalten, die alle Subscriber erhalten dürfen.
2.3.3. Event Streaming
Event Streaming ist eine Form des Publish/Subscribe-Musters, bei der Events kontinuierlich von Produzenten (Producer) erzeugt, veröffentlicht und von einem oder mehreren Konsumenten (Consumer) verarbeitet werden. Bei Event Streaming steht die dauerhafte, sequenzielle Verarbeitung von Ereignisströmen im Vordergrund. Entsprechende Produkte stellen hierzu ein geordnetes, wiederholbares Event-Log bereit. Das bedeutet, dass Konsumenten vergangene Events wiederholt verarbeiten können, um zum Beispiel ihren Zustand wiederherzustellen.
Die Stärken von Event Streaming decken sich im Wesentlichen mit denen des Musters Publish/Subscribe. Das geordnete, wiederholbare Event-Log adressiert die Herausforderung, dass Subscriber bei Ausfällen nicht alle an sie gerichteten Nachrichten erhalten.
Zusätzliche Stärken und Herausforderungen ergeben sich daraus, dass Produkte im Bereich Event Streaming in der Regel auf Echtzeitanforderungen bezüglich der Event-Verarbeitung und Hochverfügbarkeit ausgelegt sind. Dadurch skalieren sie gut horizontal und können große Mengen an Events verarbeiten, sowie eine Vielzahl von Produzenten und Konsumenten anbinden. Dadurch bedeuten sie allerdings auch einen vergleichsweise hohen Aufwand bei Installation, Konfiguration und Betrieb als Infrastrukturkomponenten anderer Kommunikationsmuster. Sie stellen wesentlich höhere Anforderungen an die Hardware-Infrastruktur (Rechen- und Speicherkapazität) und an andere Infrastrukturkomponenten (u.a. Monitoring).
3. Kommunikation mit externen Systemen
Die Kommunikation mit externen Systemen basiert auf Webservices. Wird ein Service von einem externen System angeboten, wird er als externer Service bezeichnet. Im Folgenden werden zwei Szenarien betrachtet:
Aufruf von Services der Systemlandschaft: Durch die Systemlandschaft wird externen Systemen die Schnittstelle eines Backends in Form eines Webservices zur Verfügung gestellt. Hierbei definiert das Backend selbst keinen Webservice. Vielmehr definiert das Backend, wie bei der internen Kommunikation auch, eine Schnittstelle. Diese Schnittstelle wird dann durch ein eigenständiges IT-System als Webservice exportiert. Dies geschieht mittels eines Service-Gateways, das als Service-Provider bezeichnet wird. Für jede Schnittstelle, die als Webservices exportiert werden soll, muss ein eigener Service-Provider definiert werden.
Nutzung von externen Services: Ähnlich wie im vorigen Fall ruft das interne IT-System den externen Service nicht direkt auf. Es ruft ein eigenständiges IT-System auf, welches den externen Service als Schnittstelle in die Systemlandschaft importiert. Dies geschieht ebenfalls mittels eines Service-Gateways, das als Service-Consumer bezeichnet wird. Das interne IT-System ruft dann lediglich die Schnittstelle des Service-Consumers auf. Für das interne IT-System ist dieser Aufruf nicht von einem Aufruf zu einem anderen internen IT-System zu unterscheiden. Für jeden Webservice, der in die Systemlandschaft importiert werden soll, muss ein eigener Service-Consumer definiert werden.
Die Service-Gateways stellen somit die Schnittstelle einer Systemlandschaft zur Außenwelt dar.
