Service Oriented Architecture
Fachliche Fähigkeiten als gemeinsame Dienste
Die Idee und ihr Nutzen
Ein Kunde meldet seiner Versicherung einen Wasserschaden, Fall 4711. Um den Schaden zu regulieren, also zu prüfen und zu bezahlen, muss die Versicherung drei Dinge können: die Deckung durch den Vertrag prüfen, ein Gutachten eines externen Partners einholen und am Ende die Zahlung beauftragen. Für jede dieser fachlichen Fähigkeiten gibt es ein eigenes Programm, das sie als Dienst bereitstellt: den Vertragsdienst, den Partnerdienst und den Zahlungsdienst. Jeder Dienst nimmt Anfragen in einer fest vereinbarten Form an, der Vertragsdienst zum Beispiel Vertragsnummer und Schadendatum, und jeder Ablauf im Unternehmen kann ihn nutzen. Das Programm, das den Schaden Schritt für Schritt bearbeitet, heißt Regulierungsprozess. Es nutzt diese Dienste, statt etwa die Regeln der Deckungsprüfung selbst nachzubauen. Jeder Aufruf des Regulierungsprozesses geht zuerst an die Integrationsschicht, ein Vermittlungsprogramm, das den Aufruf an den zuständigen Dienst weiterleitet. Diese Bauweise heißt Service Oriented Architecture, abgekürzt SOA, auf Deutsch dienstorientierte Architektur. „Dienstorientiert“ meint, dass jeder Ablauf die fachlichen Fähigkeiten der Versicherung als Dienste aufruft, statt sie selbst zu programmieren.
Wie funktioniert es?
Für Wasserschaden 4711 fragt der Regulierungsprozess über die Integrationsschicht nach der Deckung. Die Integrationsschicht leitet Vertragsnummer und Schadendatum an den Vertragsdienst weiter. Der Vertragsdienst antwortet „4711: gedeckt“ und nennt den Datenstand, auf dem die Antwort beruht, also den Zeitpunkt, zu dem die Vertragsdaten zuletzt aktualisiert wurden. Die Integrationsschicht gibt die Antwort an den Regulierungsprozess weiter. Danach fordert der Regulierungsprozess das Gutachten zu Fall 4711 an, ebenfalls über die Integrationsschicht, und die Integrationsschicht leitet die Anforderung an den Partnerdienst weiter. Der Partnerdienst liefert das Gutachten mit der Fallnummer 4711 zurück, und die Integrationsschicht reicht das Gutachten an den Regulierungsprozess weiter. Liegen Deckung und Gutachten vor, gibt eine Sachbearbeiterin den Betrag frei. Erst dann beauftragt der Regulierungsprozess über die Integrationsschicht den Zahlungsdienst mit der Zahlung.
Ein Dienst ist hier ein Programm, das eine fachliche Fähigkeit für andere Programme bereitstellt und als einziges die Regeln dafür pflegt. Der Vertragsdienst ist allein für die Deckungsprüfung verantwortlich, der Partnerdienst für die Gutachten externer Partner und der Zahlungsdienst für die Annahme freigegebener Zahlungsaufträge. Ein Dienst muss nicht klein sein, und verschiedene Dienste müssen nicht von verschiedenen Teams betrieben werden. Jeder Dienst bietet seine Fähigkeit über eine Schnittstelle an. Eine Schnittstelle legt fest, welche Angaben ein Dienst erwartet, welche Antworten er liefert und was diese Antworten bedeuten. Für die Deckungsprüfung erwartet der Vertragsdienst Vertragsnummer und Schadendatum und antwortet mit „gedeckt“ oder „nicht gedeckt“ und dem Datenstand. Das Team des Vertragsdienstes vereinbart diese Schnittstelle mit den Teams, deren Programme den Vertragsdienst nutzen. Der Vertragsdienst bietet die Schnittstelle an, und der Regulierungsprozess ruft sie über die Integrationsschicht auf. Die Teams vereinbaren auch, wie lange der Vertragsdienst die alte Form der Schnittstelle nach einer Änderung weiter anbietet. Jede Antwort trägt Fallnummer und Datenstand, damit der Regulierungsprozess Deckung und Gutachten eindeutig Fall 4711 zuordnen kann und keine Antworten verwechselt.
Die Integrationsschicht leitet Anfragen an den richtigen Dienst weiter und übersetzt bei Bedarf Datenformate. Ein Beispiel ist das Datenformat des Gutachterpartners, also des externen Partners, dessen Gutachten der Partnerdienst liefert. Über Deckung oder Auszahlung entscheidet die Integrationsschicht nicht. SOA legt nicht fest, wie die Dienste technisch verbunden werden; die Integrationsschicht ist eine von mehreren Möglichkeiten. Andere Umsetzungen verbinden Dienste direkt miteinander oder über Nachrichten.
Antwortet der Vertragsdienst nicht, ist die Deckung ungeklärt. Die Integrationsschicht meldet dem Regulierungsprozess „Deckung ungeklärt“ und macht daraus keine Ablehnung, denn der Vertragsdienst hat nicht „nicht gedeckt“ gesagt, sondern gar nichts. Der Regulierungsprozess wartet oder fragt später erneut. Wie lange der Regulierungsprozess wartet und wie oft er erneut fragt, vereinbaren das Team des Regulierungsprozesses und das Team des Vertragsdienstes vorab.
SOA: der Regulierungsprozess nutzt Dienste über die Integrationsschicht
Wann ist es sinnvoll und wann nicht?
Eine SOA lohnt sich
- Viele Abläufe im Unternehmen brauchen dieselben fachlichen Fähigkeiten. Die Versicherung bearbeitet Schäden in Abläufen für Privatkunden, für Firmenkunden und für Kfz-Schäden, und jeder dieser Abläufe muss die Deckung prüfen, Partner einbinden und Zahlungen auslösen. Ohne gemeinsame Dienste müsste das Team jedes Ablaufs Deckungsprüfung, Einbindung der Partner und Zahlung selbst bauen. Mit SOA kann auch ein neuer Ablauf für Gewerbeschäden Vertragsdienst, Partnerdienst und Zahlungsdienst nutzen, ohne deren Regeln neu zu bauen.
- Jede fachliche Regel soll nur in einem Dienst gepflegt werden. Baut jedes Team die Deckungsprüfung in seinem Ablauf selbst nach, entstehen mehrere Fassungen derselben Regel. Die Deckungsprüfung für Privatkunden rechnet dann vielleicht anders als die für Firmenkunden, obwohl dieselben Vertragsbedingungen gelten.
- Fremdsysteme ändern ihre Datenformate. Ist das Format des Gutachterpartners direkt in jeden Ablauf eingebaut, müssen die Teams der Abläufe für Privatkunden, für Firmenkunden und für Kfz-Schäden ihren Ablauf ändern, sobald der Gutachterpartner sein Format ändert. Mit dem Partnerdienst passt das zuständige Team nur den Partnerdienst oder die Übersetzung in der Integrationsschicht an, und der Regulierungsprozess bleibt unverändert.
Eine SOA ist nicht das Richtige
- Eine kleine Anwendung wird nur von einem Team entwickelt. In einer SOA ginge jeder Aufruf der Deckungsprüfung über das Netz und die Integrationsschicht, obwohl nur dieses eine Team die Deckungsprüfung nutzt. Dann baut das Team die Anwendung als Modular Monolith: Die Deckungsprüfung ist ein eigenes Modul innerhalb eines einzigen Programms, also ein Programmteil, den andere Programmteile nur über festgelegte Aufrufe nutzen. Andere Programmteile rufen dieses Modul direkt im Programm auf. Ein Netzwerkaufruf, der scheitern kann, entfällt, ebenso der Betrieb einer Integrationsschicht.
- Nur ein einziger Ablauf braucht eine Fähigkeit, und daran ändert sich absehbar nichts. Ein Beispiel ist eine Regel, die nur im Ablauf für Kfz-Schäden vorkommt. Ein eigener Dienst hätte dann nur diesen einen Nutzer. Das Team des Ablaufs für Kfz-Schäden baut die Regel deshalb direkt in seinen Ablauf ein. Einen eigenen Dienst muss dann niemand betreiben, und der Ablauf nutzt die Regel ohne Aufruf über die Integrationsschicht.
- Ein Ablauf braucht sehr viele Abfragen in kurzer Folge. Ein Beispiel sind 10.000 Deckungsprüfungen für eine einzige Hochrechnung. Dauert ein Aufruf über die Integrationsschicht 50 Millisekunden, brauchen 10.000 Aufrufe nacheinander mehr als acht Minuten. Dann baut das Team des Vertragsdienstes die Hochrechnung in den Vertragsdienst ein. Jede Deckungsprüfung ist dann ein Aufruf innerhalb desselben Programms ohne Weg über das Netz.
- Viele Teams sollen ihre Dienste unabhängig voneinander ausliefern. In einer SOA laufen alle Aufrufe durch die gemeinsame Integrationsschicht, und bringt das Team des Zahlungsdienstes eine neue Version heraus, muss oft erst das Team der Integrationsschicht die Weiterleitung oder Übersetzung anpassen. Dann bauen die Teams Microservices: Jedes Team betreibt kleine Dienste mit eigener Datenbank, die einander meist direkt aufrufen. Jeder aufrufende Dienst verarbeitet das Datenformat des aufgerufenen Dienstes selbst. Das Team des Zahlungsdienstes liefert eine neue Version dann aus, ohne auf das Team der Integrationsschicht zu warten.
Nachteile und typische Fehler
Die Schnittstellen der Dienste und ihre Versionen müssen zwischen vielen Teams abgestimmt werden. Ändert das Team des Vertragsdienstes zum Beispiel die Schnittstelle der Deckungsprüfung, müssen die Teams der Abläufe für Privatkunden, für Firmenkunden und für Kfz-Schäden ihre Abläufe prüfen und gegebenenfalls anpassen. Deshalb braucht es Regeln, wie lange alte Versionen einer Schnittstelle weiter angeboten werden. Jeder Aufruf über das Netzwerk dauert länger als ein Aufruf innerhalb eines Programms und kann scheitern; jeder Ablauf muss deshalb mit ausbleibenden Antworten umgehen können. Die Integrationsschicht nimmt den Abläufen Weiterleitung und Übersetzung ab, ist aber ein zusätzliches Programm mit eigenem Betrieb, das ständig erreichbar sein muss. Weil alle Aufrufe durch die Integrationsschicht laufen, warten bei hoher Last alle Abläufe gleichzeitig auf die Integrationsschicht.
Typische Fehler und woran man sie erkennt:
- Regeln in der Integrationsschicht: Das Team der Integrationsschicht baut fachliche Regeln ein, die in die Dienste gehören, etwa die Regel, ab welchem Schadenbetrag ein Gutachten nötig ist. Jede Änderung an solchen Regeln muss dann das Team der Integrationsschicht umsetzen. Erkennbar ist das an Änderungswünschen, die sich vor dem Team der Integrationsschicht stauen.
- Keine Antwort als Ablehnung: Der Vertragsdienst antwortet nicht, und die Integrationsschicht meldet dem Regulierungsprozess „nicht gedeckt“. Der Regulierungsprozess lehnt den Schaden ab, und der Kunde erhält eine Ablehnung, obwohl der Vertragsdienst gar nichts gesagt hat. Erkennbar ist das an Ablehnungen, die zeitlich mit Ausfällen des Vertragsdienstes zusammenfallen.
- Ausfall der Integrationsschicht: Die Integrationsschicht fällt aus. Weil alle Aufrufe über die Integrationsschicht laufen, erreicht kein Ablauf mehr einen Dienst, und alle Abläufe stehen still, auch wenn alle Dienste laufen. Erkennbar ist das an Fehlern in den Abläufen für Privatkunden, Firmenkunden und Kfz-Schäden zur selben Zeit.
- Unabgestimmte Änderung: Das Team des Vertragsdienstes ändert die Bedeutung einer Angabe, ohne die Teams der Abläufe für Privatkunden, für Firmenkunden und für Kfz-Schäden einzubeziehen. Der Vertragsdienst meldet „gedeckt“ zum Beispiel künftig auch für Schäden, die nur teilweise gedeckt sind. Abläufe, die sich auf die alte Bedeutung verlassen, zahlen dann solche Schäden voll aus. Erkennbar ist das an Fehlern in mehreren Abläufen unmittelbar nach einer neuen Version des Vertragsdienstes.
- Verwechselte Antwort: Der Regulierungsprozess wartet zugleich auf Gutachten zu Fall 4711 und zu einem zweiten Fall. Der Partnerdienst liefert ein Gutachten ohne Fallnummer und Datenstand zurück. Der Regulierungsprozess ordnet das Gutachten dem falschen Fall zu. Erkennbar ist das an Gutachten, deren Inhalt nicht zum Schaden passt.
Weiterführend
Verwandte Ansätze
- Enterprise Service Bus: beschreibt eine gemeinsame Vermittlungssoftware wie die Integrationsschicht, über die Dienste Nachrichten austauschen und Formate übersetzt werden.
- Orchestration: ein steuernder Ablauf ruft mehrere Dienste in festgelegter Reihenfolge auf, so wie der Regulierungsprozess Vertragsdienst, Partnerdienst und Zahlungsdienst nutzt.
- Timeout: begrenzt, wie lange der Regulierungsprozess auf einen Dienst wartet, etwa wenn der Vertragsdienst nicht antwortet.
Quellen
- OASIS: Reference Model for Service Oriented Architecture 1.0: Standard von 2006, der SOA als Vorgehen beschreibt, verteilte Fähigkeiten zu organisieren und zu nutzen, und Dienst, Schnittstelle, Dienstbeschreibung sowie Vereinbarungen zwischen dem Betreiber eines Dienstes und seinen Nutzern festlegt.
- The Open Group: Service-Oriented Architecture. What Is SOA?: beschreibt einen Dienst als wiederholbare fachliche Tätigkeit mit festgelegtem Ergebnis, deren Inneres der Nutzer nicht kennen muss.