Services
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 (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
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 erst durch die Antwort des Empfängers wieder auf, z.B. in Form eines Callbacks.
Ob zwei IT-Systeme synchron oder asynchron über Request-Response miteinander kommunizieren, muss anhand der zu erfüllenden Qualitätskriterien abgewogen werden. Das Request-Response-Muster ermöglicht so asynchrone Kommunikation, wo trotzdem direkte Antworten benötigt werden. Die Abwägung muss während der Erstellung des Systementwurfs geschehen.
2.1.1. Protokoll für Request-Response
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. Queueing
Beim Queueing baut ein Message-Broker eine Punkt-zu-Punkt-Verbindung zwischen zwei IT-Systemen auf. Dies geschieht in Form einer Queue. Ein IT-System tritt fest als Sender auf, eines als Empfänger. Der Sender ist nun in der Lage, dem Empfänger über die Queue Nachrichten zu schicken. Die Nachrichten sind anhand eines zentral definierten Formats strukturiert. Der Sender enthält keine direkte Antwort vom Empfänger.
Für das Queueing infrage kommende Message-Broker müssen JMS (Jakarta Messaging, ehemals Java Message Service) unterstützen. Queueing wird ausschließlich in der internen Servicekommunikation 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. |
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.
4. Versionierung
Die Notwendigkeit, Services in mehreren Versionen anbieten zu können, ist bedingt durch die Vielzahl an Service-Nutzern, die bei Änderung an einem Service nicht alle zeitgleich auf die neue Version eines Service umschalten können. Daher ist es notwendig, dass in einem – möglichst klein zu haltenden – Übergangszeitraum mehrere Versionen eines Service parallel betrieben werden können.
Die Versionierung wird auf der Ebene von Services, nicht Service-Operationen ausgeführt, da diese Ebene von ihrer Granularität zu den üblichen fachlichen Änderungen passt.
Es kann vorkommen, dass in einem Systemrelease neue Versionen von mehreren Services ausgeliefert werden.
4.1. Architektur
Backends bieten pro Service-Version eine eigene Service-Schnittstelle an. Die unterschiedlichen Versionen des Services verwenden alle denselben Anwendungskern. Die für die Versionierung notwendigen Transformationen sind Teil der jeweiligen Service-Schnittstelle (z.B. das Einfügen eines Standardwerts für neu hinzugefügte Attribute). In komplexen Fällen kann es auch notwendig sein, den Anwendungskern zu erweitern und die Versionierung dort zu behandeln. Die Entscheidung dafür ist im Systementwurf zu dokumentieren.
Externe Services werden durch Service-Gateways bereitgestellt. Die Versionierung eines Services muss also auch auf Ebene des Service-Gateways durchgeführt werden. Ein Service-Gateway ist ein rein technischer Protokoll-Wandler, der Webservices in interne Schnittstellen konvertiert. Im Service-Gateway erfolgt daher immer nur ein einfaches Mapping auf die entsprechenden Service-Schnittstellen der angebundenen Backends. Der Ausgleich der Versionsunterschiede erfolgt ausschließlich im Backend und nicht im Service-Gateway. Es ist möglich, pro Service-Version ein eigenes Service-Gateway zu erstellen.
4.2. Abwärtskompatible Erweiterung eines Services
Ein Backend stellt einen Service bereit, mit dem Personendaten gemeldet werden können. Parameter dieser Meldung sind Vor- und Nachname sowie das Geburtsdatum. Dazu gibt es einen Meldung-Service in der Version 1.0. Dieser wird in der Serviceschicht des Backends implementiert. Ab einem Stichtag soll zusätzlich noch der Geburtsort gemeldet werden. Im bisherigen Datenbestand wird dieses neue Attribut auf den Wert "unbekannt" gesetzt. Der bestehende Service wird um dieses Attribut erweitert und erhält die Versionsnummer 1.1. Anwendungskern und Persistenzschicht müssen ebenfalls erweitert werden. Aus Gründen der Rückwärtskompatibilität soll aber weiterhin die Version 1.0 des Service angeboten werden. Dazu wird ein neuer Service innerhalb der Serviceschicht implementiert, der die Meldung entgegennimmt, das fehlende Attribut mit dem Wert "unbekannt" ergänzt und dann den Anwendungskern aufruft.
Werden die beiden Services durch ein Service-Gateway nach außen verfügbar gemacht, existieren dort zwei parallele Mappings auf die jeweiligen Services des Backends. Innerhalb des Service-Gateways existiert keine Geschäftslogik, d.h. die Abbildung von Version 1.0 auf 1.1 findet erst im Backend statt.
4.3. Inkompatible Veränderung eines Services
In einem komplexeren Fall kann es passieren, dass Services von Backends so umgestaltet werden, dass die Aufrufe nicht mehr aufeinander abgebildet werden können. Wird in so einem Fall ein neuer Service eingeführt, während der alte Service noch verfügbar bleiben muss, müssen die inkompatiblen Verarbeitungslogiken im Anwendungskern parallel unterstützt werden. Auch hier enthält das Service-Gateway keine Geschäftslogik.
| Eine Versionierung ist nur dann sinnvoll, wenn kleine Änderungen an der Schnittstelle zwischen den Versionen auftreten. Für den Fall, dass sich die Schnittstelle sowohl syntaktisch als auch semantisch grundlegend ändert, sollte anstatt einer neuen Version besser eine eigenständige, neue Schnittstelle entstehen. |