Detailkonzept Service
Diese Seite ist ein Teil der IsyFact-Standards.
Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt.
Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.
Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.
1. Einleitung
Entsprechend der Referenzarchitektur (siehe Referenzarchitektur) stellen IT-Systeme Services über die technische Komponente „Service“ zur Verfügung. Das vorliegende Dokument beschreibt die Aufgaben und die Architektur dieser technischen Komponente. Zu beachten ist, dass die Komponente „Service“ die Services eines IT-Systems lediglich innerhalb der Systemlandschaft verfügbar macht. Um diese Services auch externen Anwendungen zur Verfügung zu stellen, müssen die Services durch ein sogenanntes Service-Gateway exportiert werden.
Das Dokument gliedert sich wie folgt: Im Abschnitt Überblick wird kurz beschrieben, wie sich Services als eigene Komponente "Service" in ein IT-System integrieren. Im Abschnitt Servicelogik werden dann Aufgaben und Aufbau der Servicelogik beschrieben. Die restlichen Abschnitte widmen sich fortgeschrittenen Aspekten wie Transaktionssteuerung, Versionierung und Verfügbarkeit.
2. Überblick
Services gliedern sich über eine technische Komponente „Service“ in die T-Architektur von IT-Systemen ein (siehe Abbildung 1).
Diese technische Komponente besteht aus zwei Teilen: dem Service-Framework und der Servicelogik.
Das Service-Framework bezeichnet die konkrete Technologie, mit der die Services des Anwendungskerns zur Verfügung gestellt werden.
Die Servicelogik enthält Daten und Funktionalität, die für die Bereitstellung des Services relevant sind.
3. Servicelogik
Die Servicelogik gliedert sich, wie der Anwendungskern, in Fachkomponenten. Die Fachkomponenten setzen im wesentlichen Service-Schnittstellen um. Sie decken vier wesentliche Aufgaben ab.
- Transformation
-
Bei einem Service-Aufruf müssen die Transportobjekte der Service-Schnittstelle in passende Objekte des Anwendungskerns umgewandelt werden. Außerdem muss das Ergebnis des Anwendungskerns wieder in ein Transportobjekt der Service-Schnittstelle umgewandelt werden. Transportobjekte sind Klassen, deren einziger Zweck es ist, Daten zu transportieren. Sie definieren lediglich eine Datenstruktur.
- Fehlerbehandlung
-
Ausnahme, die bei der Verarbeitung eines Service-Aufrufs oder im Anwendungskern auftreten, werden in eine Ausnahme der Service-Schnittstelle umgewandelt.
- Autorisierung
-
Für einen Service-Aufruf muss eine Anwendung überprüfen, ob der Aufrufer autorisiert ist die Service-Operation auszuführen.
- Logging
-
Die Komponente muss die Korrelations-ID in den Logging-Kontext einfügen.
| Im Normalfall ist der Funktionsumfang der Fachkomponenten viel geringer als der Funktionsumfang der Entsprechungen im Anwendungskern. Dies liegt darin begründet, dass die Servicelogik die Funktionalität des Anwendungskerns nutzt, um den Service bereitzustellen, und selbst keinerlei Geschäftslogik beinhaltet. Die Schnittstelle zwischen Fachkomponenten im Service und Anwendungskern ist daher eine interne Schnittstelle. |
Die Service-Schnittstellen bestehen aus einer Service-Fassade und einer Exception-Fassade.
3.1. Service-Fassade
Die Service-Fassade implementiert die Service-Operationen als Methoden. Ihre Hauptaufgabe ist die Transformation der Service-Aufrufe in interne Aufrufe des Anwendungskerns sowie die Transformation dessen Antworten in Antworten der Service-Schnittstelle. Dabei transformiert sie die Geschäftsobjekte des Anwendungskerns in Transportobjekte der Service-Schnittstelle und umgekehrt. Hierzu wird in der Regel ein Bean Mapper verwendet. In Einzelfällen können Teile der Transformation auch programmiert werden, sofern der Nutzen daraus den Aufwand nicht übersteigt.
Die Service-Fassade übernimmt auch die Autorisierung des Aufrufs.
Dazu nutzt sie die Möglichkeiten des Bausteins Security.
Voraussetzung für die Autorisierung ist die Auswertung des mitgelieferten Access-Tokens.
Über die Annotation @Secured wird die Berechtigung zum Zugriff auf die Methode anhand der Rechte des Aufrufers geprüft.
Alternativ kann die Annotation @Secured auch an der Service-Fassade selbst verwendet werden, wenn alle Methoden die gleichen Rechte erfordern.
3.2. Exception-Fassade
Die Exception-Fassade ist verantwortlich für die Umwandlung der durch den Anwendungskern oder die Service-Fassade geworfenen Exceptions in Exceptions der Service-Schnittstelle. Dies kann auf mehreren Wegen geschehen. Je nach gewählter Schnittstellentechnologie werden z. B. Annotationen oder eigens dafür geschriebene Klassen oder Methoden verwendet.
Bevor die Exception-Fassade aufgerufen wird, muss die Korrelations-ID aus dem Aufrufkontext im Logging-Kontext registriert sein.
Dies geschieht durch die Annotation @StelltLoggingKontextBereit an der Methode oder an der Service-Fassade selbst.
Dabei gilt es zu beachten, dass die Annotation standardmäßig so konfiguriert ist, dass sie vor den Annotationen ohne Angabe einer Priorität ausgeführt wird, sodass diese immer Zugriff auf die Korrelations-ID haben.
Diese Reihenfolge wird durch Einfügen der Order für den Advisor stelltLoggingKontextBereitAdvisor in der Autokonfiguration IsyServiceApiCoreAutoConfiguration erreicht.
|
Die weiteren Inhalte zum Aufbau, zur Realisierung und zur Nutzung von Service-Schnittstellen wurden wegen ihrer Abhängigkeit zur konkreten Schnittstellentechnologie in den entsprechenden Technologie-Baustein verschoben. Die Inhalte finden sich in den Dokumenten Konzept HTTP-Invoker und Konzept REST-Schnittstellen, sowie Nutzungsvorgaben HTTP-Invoker und Nutzungsvorgaben REST-Schnittstellen. |
4. Übertragung von Metadaten
In jeder Art von Servicekommunikation werden Metadaten übertragen. In der Regel geschieht dies ü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. |
5. Transaktionssteuerung
In der Regel geschieht die Transaktionssteuerung im Anwendungskern. Gibt es allerdings Anforderungen, aus denen heraus die Service-Fassade eine Transaktion über mehrere Aufrufe des Anwendungskerns hinweg bilden muss, so muss diese Transaktion über die Service-Fassade gesteuert werden. Die Aufgabe fällt der Service-Fassade zu, weil es wichtig ist, dass die Fehlerbehandlung auf jeden Fall die Transaktion umschließt. Nur so ist gewährleistet, dass auch Fehler, die beim Commit entstehen, von der Fehlerbehandlung erfasst werden.
Die Transaktionssteuerung wird an der jeweiligen Service-Methode angesetzt. Für das obige Beispiel verdeutlicht dies Listing 1. .Transaktionssteuerung in der Service-Fassade
public class BeispielServiceFassade {
...
@StelltAufrufKontextBereit
@StelltLoggingKontextBereit
@Secured(Rechte.RECHT_ZUGRIFFBEISPIEL)
@Transactional(rollbackFor = Throwable.class, propagation = Propagation.REQUIRED)
public BeispielHolenAntwortTo holeBeispiel(
AufrufKontextTo kontext, BeispielHolenAnfrageTo anfrage)
throws BeispielException {
...
}
...
}Eine Sonderstellung nehmen Services ein, die im Fehlerfall keinen Fehler zurückgeben, sondern die Fehler in der Antwortnachricht übermitteln. Der AOP-Transaktionsmanager wird niemals ein Rollback durchführen, da alle Exceptions abgefangen werden, auf die er reagieren könnte. Um auch in diesem Fall ein Rollback der Transaktion zu erzwingen, ist folgender Aufruf durchzuführen:
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();6. 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.
6.1. Architektur
IT-Systeme bieten pro Service-Version eine eigene Service-Schnittstelle an. Die 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 IT-Systeme. Der Ausgleich der Versionsunterschiede erfolgt ausschließlich im IT-System und nicht im Service-Gateway. Es ist möglich, pro Service-Version ein eigenes Service-Gateway zu erstellen (siehe Abbildung 2).
6.2. Einfacher Fall: Kompatible Erweiterung eines Services
Ein IT-System 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 Service-Schicht des IT-Systems implementiert. Ab einem Stichtag soll zusätzlich noch das Geschlecht 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 Datenzugriffsschicht 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 Service-Schicht 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 IT-Systems. Innerhalb des Service-Gateways existiert keine Geschäftslogik, d.h. die Abbildung von Version 1.0 auf 1.1 findet erst im IT-System statt.
6.3. Komplexerer Fall: Inkompatible Veränderung eines Services
In einem komplexeren Fall kann es passieren, dass die Service-Schnittstelle einer Anwendung komplett umgestaltet wird, sodass die Aufrufe nicht mehr einfach 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 erhalten bleiben. Auch hier enthält das Service-Gateway keine Geschäftslogik.
6.4. Umsetzung
Die Java-Klassen und -Interfaces eines Services existieren in allen Versionen der Service-Schnittstelle und unterscheiden sich inhaltlich durch die in der neuen Version durchgeführten Änderungen.
| Für die Versionierung von Schnittstellen gelten gesonderte Vorgaben, die in IsyFact Versionierung definiert sind. |
Zur Veröffentlichung von API-kompatiblen Änderungen wird im Maven pom.xml eine einstellige Versionsnummer (Minor) gesetzt.
Kompatible Änderungen sind beispielsweise Bugfixes, neue Operationen in der Schnittstelle oder neue, optionale Attribute im Datenmodell.
<dependencies>
...
<dependency>
<groupId>${Organisation.Domäne.Anwendungsname}</groupId>
<artifactId>${Anwendungsname}-${Schnittstellentechnologie}-sst-${Servicename}-v${Major-Version}</artifactId>
<version>${Minor-Version}</version>
</dependency>
...
</dependencies>Bei inkompatiblen Änderungen der Schnittstelle wird die zweistellige Versionsnummer angepasst (Major und Minor); diese wird sowohl in der Artefakt-ID als auch in den Paketnamen der Schnittstelle verwendet. Inkompatible Änderungen der Schnittstelle sind z. B. das Entfernen von Attributen oder Operationen oder das Hinzufügen von Pflichtfeldern.
Bei der Implementierung ist zu beachten, dass die Versionsnummer aus dem Package-Namen auch in die Implementierung übernommen wird.
6.5. Grenzen
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.
7. Verfügbarkeit
Die IsyFact berücksichtigt die folgenden Anforderungen an die Verfügbarkeit von Services in Systemlandschaften.
Hohe Verfügbarkeit: Die IT-Systeme der Systemlandschaft müssen eine hohe Verfügbarkeit aufweisen. Die Berechnung der Verfügbarkeit einer Anwendung ist komplex. In die Berechnung fließen unter anderem betriebliche Aspekte wie Hardwareverfügbarkeit ein, während Wartungsfenster herausgerechnet werden. Weiter könnte man Verfügbarkeit auf der Ebene von angebotenen Services und nicht von IT-Systemen betrachten. Von der Seite der Software ist zu beachten, dass sich in einer serviceorientierten Systemlandschaft die Ausfallwahrscheinlichkeiten multiplizieren, wenn Systeme einander aufrufen.
Schnelles Antwortzeitverhalten im Fehlerfall: Die Nichtverfügbarkeit von Services ist ein Ausnahmefall, auf den angemessen reagiert werden muss. Sollte ein Service nicht verfügbar sein, ist es wichtig, dass die aufrufende Anwendung zügig eine Fehlermeldung erhält. Speziell bei Online-Anwendungen ist der schnelle Erhalt einer Fehlermeldung notwendig. Der Nutzer soll auch im Fehlerfall eine gewohnt schnelle Antwort vom System erhalten. Die genaue Definition des Zeitrahmens, in dem die Fehlermeldung über die Nichtverfügbarkeit beim Aufrufer eintreffen muss, ist anwendungsspezifisch. Die Definition ist dementsprechend durch die jeweiligen Aufrufer vorzunehmen.
7.1. Beispielszenario
Für das Szenario gehen wir im Folgenden davon aus, dass ein IT-System eine Gesamtverfügbarkeit von 98 % aufweisen soll. Hierbei ist zu beachten, dass IT-Systeme in der Regel andere IT-Systeme und Querschnittsanwendungen aufrufen, um Anfragen zu beantworten. Die Gesamtverfügbarkeit sinkt dadurch ab, da zur erfolgreichen Bearbeitung einer Anfrage alle Systeme zeitgleich verfügbar sein müssen. Im Szenario wird für alle Systeme ein Richtwert für die Verfügbarkeit von 99,7 % angenommen. Wie die Beispielrechnung der Verfügbarkeit zeigt, ergibt sich eine Gesamtverfügbarkeit von über 98 % bei einer Verfügbarkeit von 99,7 % pro System.
Eine Berechnung der Gesamtverfügbarkeit nach diesem Schema muss für jedes IT-System einzeln durchgeführt werden. Dabei müssen die berechneten oder gemessenen Verfügbarkeiten aller IT-Systeme zugrunde gelegt werden, die das IT-System aufruft.
| System | Verfügbarkeit |
|---|---|
IT-System |
99,7 % |
Aufgerufenes IT-System 1 |
99,7 % |
Aufgerufenes IT-System 2 |
99,7 % |
Aufgerufene Querschnittsanwendung |
99,7 % |
Service-Gateway (Infrastruktur) |
99,7 % |
Datenbank (Infrastruktur) |
99,7 % |
Gesamtverfügbarkeit |
(99,7 %)6 = 98,21 % |
7.2. Ursachen für Nichtverfügbarkeit
Die möglichen Ursachen für Nichtverfügbarkeit sind unter anderem:
Deployment einer Anwendung: Bei einem Re-Deployment einer Anwendung kommt es zu einer geplanten Auszeit.
Überlastung während Lastspitzen: Im Tagesverlauf variiert die Last, die ein System verarbeiten muss. Manche Systeme antworten bei Lastspitzen zu langsam.
Ausfall von Hard- oder Software: Auf einem Knoten eines Anwendungsclusters ist eine Störung durch einen Hardware- oder Softwareausfall aufgetreten. Der nicht funktionierende Knoten ist dadurch temporär nicht verfügbar, wodurch die verbleibenden Knoten die Last des ausgefallenen Knotens mitverarbeiten müssen.
Umschaltzeit bei Hard- oder Softwareausfall: Bei Ausfall von Hard- oder Software sorgt ein Loadbalancer dafür, dass alle Anfragen nur an die noch funktionierenden Knoten weitergeleitet werden. In dem kurzen Zeitraum, bis der Loadbalancer einen Server-Knoten als ausgefallen markiert („Umschaltzeit“), kommt es jedoch zur Nichtverfügbarkeit von Services. In diesem Zeitraum werden Anfragen nicht beantwortet die noch an den ausgefallenen Knoten geleitet werden.
|
Die Regeln, nach denen der Loadbalancer entscheidet, wann ein Server-Knoten nicht mehr verfügbar ist, können üblicherweise konfiguriert werden. Beispielsweise kann ein Loadbalancer alle paar Sekunden per Script („Health-Check“) überprüfen, ob ein Server-Knoten noch verfügbar ist. Erst nach einer festgelegten Anzahl fehlgeschlagener fachlicher Anfragen und negativem Health-Check leitet dann der Loadbalancer keine Anfragen mehr an diesen Knoten. Unabhängig von der Konfiguration kann es trotz Loadbalancer und Anwendungscluster zu wenigen nicht beantworteten Anfragen und somit zu einer Nichtverfügbarkeit kommen. |
Batchläufe: Wenn lang laufende Batches in Geschäftsanwendungen durchgeführt werden, dürfen in dieser Zeit keine Meldungen gemacht werden. So werden Dateninkonsistenzen vermieden. Meldungsaufrufe sind in dieser Zeit nicht verfügbar und werden von der Geschäftsanwendung nicht beantwortet.
Retries des Loadbalancers: Tritt ein Ausfall von Hard- oder Software auf (siehe Ausfall von Hard- oder Software oben), bekommt der Loadbalancer beim Weiterleiten einer Anfrage an einen ausgefallenen Knoten ein Timeout. Loadbalancer können so konfiguriert werden, dass sie in diesem Fall die gleiche Anfrage an einen noch funktionierenden Knoten weiterleiten und nicht sofort eine Fehlermeldung an den Aufrufer zurückgeben. Für den Aufrufer hat der Service dadurch eine längere Antwortzeit. Der Aufrufer hat keine Möglichkeit dieses Timeout/Retry-Verhalten des Loadbalancers zu beeinflussen und auf seine Bedürfnisse anzupassen. Die lange Antwortzeit kann aufseiten des Aufrufers leicht zu einem Timeout führen.
Verschlimmerung von Nichtverfügbarkeiten: Die aufrufende Anwendung reagiert nicht angemessen auf eine Nichtverfügbarkeit eines Service. Beispiele:
-
Der Client versucht Retries, obwohl der Service-Aufruf aus fachlicher Sicht entfallen könnte (optionaler Aufruf).
-
Die fachliche Verarbeitung wird nicht rechtzeitig abgebrochen, obwohl ein verpflichtender Service-Aufruf bereits fehlgeschlagen ist.
-
Die Bearbeitung der Anfrage dauert bekanntermaßen beim Service-Anbieter sehr lange. Der Aufrufer hat einen sehr knappen Timeout gesetzt und schickt Aufrufwiederholungen. Dies verschlimmert die Antwortzeiten der Service-Aufrufe und führt eventuell zu Duplikaten beim Service-Anbieter.
Eine weitere bekannte Ursache für Nichtverfügbarkeit ist die Umgebungskonfiguration, Firewall-Verbindungen nach einer definierten Zeit automatisch zu schließen. Zustandsbehaftete Verbindungen wie sie bei Datenbank-Clients eingesetzt werden, sind von dieser Restriktion betroffen. Diese Clients müssen vorsehen, dass Sie eine von der Firewall geschlossene Verbindung erkennen und wieder neu aufbauen. Dieses Thema wird im Konzept JPA/Hibernate behandelt.
Die IsyFact setzt als Transportprotokoll für Service-Kommunikation durchgängig HTTP ein. HTTP ist ein zustandsloses Protokoll und baut bei jeder Anfrage eine neue Verbindung zwischen Client und Server auf. HTTP 1.1 bietet einen Mechanismus an, mehrere Anfragen über eine TCP-Verbindung zu transportieren. Wenn eine Schnittstellentechnologie diesen Mechanismus nutzt, müssen die TCP-Verbindungen vor ihrer Verwendung validiert werden.
7.3. Maßnahmen
Folgende Maßnahmen können ergriffen werden, um die Anforderungen an die Verfügbarkeit zu gewährleisten.
7.3.1. Anwendungscluster mit Loadbalancer
Die TI-Architektur der IsyFact setzt die hohen Verfügbarkeitsanforderungen durch Clustering der Applikations- und Datenbankserver um. Anwendungen werden redundant auf mehr als einem Server installiert. Kommt es zu einem Hard- oder Softwareausfall auf einem Server-Knoten, so werden alle Anfragen von einem vorgeschalteten Loadbalancer auf einen anderen Server-Knoten umgeleitet. Durch die Redundanz wird die Verfügbarkeit von Services bei auftretenden Hard- oder Softwareausfällen erhöht. Trotzdem kann es auch hier noch zu Nichtverfügbarkeit kommen.
7.3.2. Knotenweises Deployment
Diese Maßnahme hilft bei Nichtverfügbarkeit aufgrund von geplanten Wartungsarbeiten. Im Clusterbetrieb besteht die Möglichkeit, diese Knoten für Knoten auszuführen. Bevor das Deployment auf einem Knoten ausgeführt wird, wird dem Loadbalancer mitgeteilt, dass der Knoten nicht mehr verfügbar ist. Während des Deployments des Knotens verarbeiten die restlichen Knoten alle ankommenden Anfragen. Nach Abschluss des Deployments des Knotens wird dem Loadbalancer mitgeteilt, dass der Knoten wieder zur Verfügung steht. Dann kann das Deployment des nächsten Knotens nach dem gleichen Schema erfolgen. Dadurch können Services im Zeitraum von Wartungsarbeiten voll verfügbar gehalten werden.
7.3.3. Time-To-Live
Ein Service-Aufruf ist nur für eine bestimmte Zeit gültig. Diese Zeitspanne wird als Time-To-Live (TTL) bezeichnet. Der Aufrufer definiert die TTL und legt so fest, wie lange er bei einem Aufruf auf eine Antwort wartet. Hierdurch wird eine schnelle Antwortzeit gewährleistet.
7.3.4. Aufrufwiederholung (Retry)
Von Loadbalancern ausgeführte Retries können zu einer Erhöhung der Antwortzeit führen. Loadbalancer innerhalb der Plattform sind deshalb so zu konfigurieren, dass fehlgeschlagene Anfragen nicht an andere Knoten weitergeleitet werden. Eine Wiederholung von Aufrufen ist ausschließlich vom Aufrufer auszuführen. So kann der Aufrufer je nach Fachlichkeit entscheiden, bei welchen Anfragen Wiederholungen sinnvoll sind.
Grundsätzlich sind Retries nur mit größter Vorsicht anzuwenden! Hierfür gibt es mehrere Gründe:
Ruft ein Client einen Service auf und erhält einen technischen Fehler, so kann der Client anhand des technischen Fehlers in der Regel nicht einwandfrei erkennen, ob seine Anfrage nicht doch auf dem Server erfolgreich verarbeitet wurde. Beispielsweise kann durch einen Netzwerkausfall zwar die Netzwerkverbindung zum Server abgebrochen sein, das hindert den Server aber nicht daran, eine bereits in Verarbeitung befindliche Service-Anfrage weiterzuverarbeiten. In einem solchen Fall würde ein automatischer Retry dazu führen, dass ein und dieselbe Service-Anfrage zweimal ausgeführt würde. Dies kann bei nicht-idempotenten Service-Operationen fatale Auswirkungen haben (z. B. Löschen von falschen Daten).
Eine automatische Aufrufwiederholung kann im Falle einer echten Nichtverfügbarkeit zu einer erhöhten Netzwerklast führen und so die Nichtverfügbarkeit auch anderer Anwendungen in der Anwendungslandschaft erhöhen. Die Situation wird daher durch die Aufrufwiederholung deutlich verschlechtert.
Insbesondere bei einem Timeout eines TTL ist jedoch ein Retry mit großer Vorsicht zu genießen, da nicht klar ist, ob die Service-Anfrage nicht doch durch den Server bearbeitet wird. In einem solchen Fall führt eine Aufrufwiederholung zu einer erhöhten Last auf dem Server und kann im schlechtesten Fall zu einer echten Nichtverfügbarkeit des Services bzw. des kompletten Servers führen.
|
In Anbetracht der potenziellen Probleme der Aufrufwiederholung und der Tatsache, dass eine Aufrufwiederholung nur für idempotente Service-Operationen überhaupt zulässig ist, sollte von einer automatischen Aufrufwiederholung als Maßnahme zur Erhöhung der Verfügbarkeit in der Regel abgesehen werden. Ausgenommen davon sind Aufrufe, bei denen nur Daten gelesen werden, wie z. B. Suchen im Suchverfahren oder Abfragen von Verzeichnissen wie Schlüsselverzeichnis, Benutzerverzeichnis oder Behördenverzeichnis. Hierfür soll grundsätzlich eine Aufrufwiederholung durchgeführt werden. Diese ist sinnvoll über die folgenden Parameter konfigurierbar:
Die Parameter sind Bestandteil der betrieblichen Konfiguration (s. Konzept Konfiguration). |
7.3.5. Deaktivierung von Services
Aufgrund von Wartungsaktivitäten oder Batches (z. B. einer Datenmigration) in einer Fachanwendung kann es vorkommen, dass der Meldungsservice einer Fachanwendung vorübergehend deaktiviert wird. Andere Services wie z. B. eine Auskunft können während dieser Zeit regulär ausgeführt werden. Während der Meldungsservice deaktiviert ist, wird dem Aufrufer eine entsprechende Fehlermeldung zurückgesendet. Da die Anforderung besteht, auch andere Services vorübergehend deaktivieren zu können, werden generell alle Services deaktivierbar gemacht.