Services

Synchrone Service-Aufrufe bieten 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. Der Sender wartet auf die Antwort, bevor er seine Verarbeitung fortsetzt.

Deswegen sind synchrone Service-Aufrufe in der Regel eine vergleichsweise zeitintensive Operation. Häufig ist es sinnvoll, Service-Aufrufe nach Möglichkeit einzusparen. Das Sparen von Aufrufen kann jedoch auch Nachteile in Bezug auf Wartbarkeit bedeuten, wenn beispielsweise Redundanzen oder komplexe Caches implementiert werden müssen. Die Abwägung darüber muss während der Erstellung des Systementwurfs geschehen.

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.

Für asynchrone Service-Aufrufe gelten dieselben Vorgaben wie für synchrone Service-Aufrufe. Sie unterscheiden sich im Ablauf dahingehend, dass der Sender nicht aktiv auf die Antwort des Empfängers wartet. Stattdessen wird die Verarbeitung erst durch die Antwort des Empfängers wieder aufgenommen, z.B. in Form eines Callbacks.

Asynchrone Service-Aufrufe können z.B. dann eingesetzt werden, wenn eine länger dauernde Verarbeitung durch den Empfänger eine direkte Rückmeldung unmöglich macht.

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.

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 Web-Services 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.

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.

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.