Acht Grundprinzipien von SOA: Serviceautonomie und Zustandslosigkeit

Im fünften Teil unserer SOA-Serie, in der es um Grundprinzipien der Serviceorientierung geht, erläutern wir Serviceautonomie und Zustandslosigkeit.

Mit der zunehmenden Verbreitung von Automatisierungslogiken in Form von Services gibt es auch ein wachsendes Bedürfnis, die Zuverlässigkeit und Effizienz dieser Services während ihrer Laufzeit zu steigern. Dieser Bedarf wird noch verstärkt, wenn man ein Serviceinventar mit einer großen Menge von wiederverwendbaren Services aufbaut.

Wiederverwendbare Services und Parallelität

Die Wiederverwendbarkeit („Reuse“) von Services ist ein zentraler Bestandteil von SOA. Dies geht so weit, dass strategische Ziele von Organisationen, die SOA verwenden, direkt mit dem erfolgreichen Implementieren von wiederverwendbaren Automatisierungslogiken verbunden werden. Wir müssen deshalb sicherstellen, dass die Services, die wir liefern, nicht nur eine wiederverwendbare Logik besitzen. Vielmehr müssen die Services auch so konstruiert sein, dass sie in der realen Welt wiederverwendbar sind.

In der Regel werden wir aufgefordert, Möglichkeiten für die Wiederverwendung zu konstruieren, zu fördern und zu maximieren. Jeder Service, der als wiederverwendbar klassifiziert wird, wird für eine potenziell große Zahl von nachfragenden Programmen zur Verfügung gestellt. Die Ergebnisse sind vorhersagbar. Mit der Zeit wird der gleiche Service die Automatisierung der verschiedenen Geschäftsprozesse oder Aufgaben erleichtern – und kann Teil zahlreicher Servicekompositionen werden.

Dieser führt zu einem hohen Nutzungsvolumen, unvorhersehbaren Nutzungsszenarien und einer Laufzeitbedingung, die wir besonders vorbereiten sollten, nämlich: gleichzeitiger, paralleler Zugriff. Wenn auf einen Dienst zur gleichen Zeit von zwei oder mehr Serviceverbrauchern zugegriffen wird, werden Instanzen des Service erzeugt. Wie dies konkret geschieht, ist zu einem großen Teil abhängig von der Laufzeitplattform des Dienstleisters.

Es gibt jedoch wichtige Schritte, die wir bei der Gestaltung des Services berücksichtigen sollten, um die zugrunde liegende Service-Logik zu strukturieren und damit den problemlosen, gleichzeitigen Zugriff zu erleichtern.

Das führt uns zu den beiden Konstruktionsprinzipien, die wir in diesem Artikel erläutern:

  • Services sind autonom;
  • Services sind zustandslos.

Wenn ich ein Programm entwickle, das einen bestimmten Service in Anspruch nimmt, weiß ich nicht, – und möchte mich auch nicht darum kümmern – wie viele andere bereits diesen Service nutzen (und wie viele ihn in Zukunft verwenden werden). Ich habe eine Erwartung, was der Service leisten wird auf Basis der Angaben, die im Servicevertrag und vielleicht in zusätzlichen SLAs beschrieben sind. Deshalb werde ich mich auf die Fähigkeit des Service verlassen, ein vorhersehbares Verhalten und eine bestimmte Leistung und Zuverlässigkeit zu liefern – unabhängig davon, wie der Service sonst noch verwendet wird. Die Anwendung dieser Grundsätze trägt letztlich zur Unterstützung eines stabilen und vorhersehbaren Serviceinventars bei.

Serviceautonomie

Serviceorientierung beinhaltet eine strenge Haltung, wenn es zur De-Komposition kommt. Beim Aufbau eines Enterprise Serviceinventars ist es wichtig, jedes Element des Inventars als Standalone-Baustein zu positionieren.

Damit Services eine zuverlässige und vorhersagbare Leistung bereitstellen, müssen sie ihre zugrunde liegenden Ressourcen kontrollieren. Dafür sorgt die Autonomie. Mit dem Autonomieprinzip ist gemeint, dass jeder einzelne Service ein hohes Maß an individueller Eigenständigkeit und Unabhängigkeit haben sollte.

Mit steigender Kontrolle, die ein Service über seine eigene Ausführungsumgebung hat, können wir Abhängigkeiten reduzieren, die ansonsten bei gemeinsam genutzten Unternehmensressourcen benötigt werden. Auch wenn wir nicht immer einen Service mit einem exklusivem Besitz der gekapselten Logik bereitstellen können, ist unser Hauptanliegen, dass es ein vernünftiges Maß an Kontrolle der Ausführungslogik geben muss.

Da es verschiedene Ausmaße der Autonomie geben kann, ist es hilfreich, zwischen ihnen zu unterscheiden. Im Folgenden greifen wir zwei gemeinsame Ebenen heraus:

Service-Level-Autonomie: Die Servicegrenzen trennen Services voneinander, aber jeder Service kann seine zugrunde liegenden Ressourcen noch mit anderen teilen. Zum Beispiel kann ein Wrapper-Service, der eine Legacy-Umgebung kapselt, die auch unabhängig von dem Dienst verwendet wird, Service-Level-Autonomie haben. Er regelt das Legacy-System, teilt aber auch die Ressourcen mit anderen Legacy-Clients.

Echte Autonomie: Die zugrunde liegende Logik ist vollständig unter Kontrolle des Service und auch sein Eigentum. Dies ist typischerweise dann der Fall, wenn eine Logik von Grund auf zur Unterstützung eines bestimmten Dienstes aufgebaut wurde.

Natürlich ist es für ein Serviceinventar wünschenswerter, dass es vollständig autonome Services enthält. Dies hilft nicht nur, besser mit Skalierbarkeitsproblemen umzugehen, wie beispielsweise gleichzeitigen Zugriffsbedingungen. Es ermöglicht auch, Services zuverlässiger zu positionieren, um Single-Point-of-Failure-Risiken entgegenzuwirken, die oft bei Nutzung wiederverwendbarer Automatisierungslogiken einhergehen. Da es jedoch in der Regel die Generierung neuer Servicelogiken voraussetzt und oft besondere Überlegungen zur Servicebereitstellung erfordert, kann dies erhebliche zusätzliche Kosten und einen erhöhten Aufwand bedeuten.

Zustandslosigkeit von SOA

Während Autonomie im Allgemeinen in der IT gut verstanden wird, gibt es oft weniger Klarheit, was unter Zustandsinformation zu verstehen ist. Aus diesem Grund befassen wir uns vorher kurz mit dem Zustands-Management, bevor wir uns dem Prinzip Zustandslosigkeit widmen.

Ein Zustand bezieht sich auf eine bestimmte Verfassung oder Lage von etwas. Ein fahrendes Auto befindet sich im Zustand der Bewegung, während ein parkendes Auto sich in einem stationären Zustand befindet. In der Business-Automatisierung ist es Usus, dass eine Software zwei primäre Zustände hat, die ihm zugeordnet sind:

  • aktiv
  • passiv

Der erste Zustand ist der Status eines Programms, wenn es aufgerufen oder ausgeführt wird. Es tritt dann in einen aktiven Zustand ein. Der zweite Zustand tritt ein, wenn das Programm nicht gebraucht wird. Es befindet sich dann in einem passiven oder nicht-aktivierten Zustand.

Wenn wir Programme entwerfen, sind wir natürlich vor allem daran interessiert, was passiert, wenn sie aktiv sind. Wir sind auch daran interessiert, dass wir zusätzliche Zustände haben, die wir dem Programm zuschreiben und die bestimmte Arten von aktiven Bedingungen darstellen. In Bezug auf unsere Diskussion zum Zustands-Management gibt es zwei Hauptbedingungen:

  • zustandslos (stateless)
  • zustandsbefaftet (stateful)

Diese Begriffe werden verwendet, um die aktive oder Laufzeitbedingung eines Programms zu identifizieren. Bezug genommen wird dabei auf die Verarbeitung, die es zur Ausführung einer bestimmten Aufgabe braucht. Wenn man eine bestimmte Aufgabe automatisiert hat, muss das Programm Daten verarbeiten, die spezifisch für diese Aufgabe sind. Wir können uns auf diese Daten mit Zustandsinformationen beziehen.

Mehr Artikel aus der SOA-Serie:

Acht Grundprinzipien von SOA: Service Discoverability und Servicekomposition.

Acht Grundprinzipien von SOA: Serviceabstraktion und Wiederverwendbarkeit.

Acht Grundprinzipien von SOA: Serviceverträge und lose Kopplung.

Acht Grundprinzipien von serviceorientierter Architektur (SOA).

Ein Programm kann aktiv sein, aber es muss nicht unbedingt Zustandsinformationen verarbeiten. In diesem Ruhezustand wird das Programm als zustandslos betrachtet. Wie Sie vielleicht schon erraten haben, ist ein Programm, das aktiv Zustandsinformationen verarbeitet oder speichert, zustandsbehaftet.

Da die Verarbeitung nach wiederverwendbaren und komponierten Services verlangt und der gleichzeitige Zugriff sich normalerweise erhöht, nimmt auch die Notwendigkeit zu, die Serviceverarbeitungslogik zu optimieren. Bei der Gestaltung von serviceorientierten Architekturen benötigt das Zustands-Management deshalb besondere Aufmerksamkeit. Dabei liegt der Fokus auf dem Management von Zusandsinformationen innerhalb der Architektur.

Dieses Prinzip besagt, dass Services den Umfang an Zustandsinformationen, die sie managen müssen, minimieren sollten. Ebenso sollten sie die zustandsbehaftete Dauer minimieren. In einer serviceorientierten Lösung repräsentiert die Zustandsinformation in der Regel die Daten, die in einer aktuellen Serviceaktivität verarbeitet werden. Während zum Beispiel ein Service eine Nachricht verarbeitet, ist er vorübergehend zustandsbehaftet. Wenn ein Service für längere Zeit im Zustand zustandsbehaftet verweilt, wird seine Fähigkeit, gleichzeitig für andere Verbraucher verfügbar zu sein, beeinträchtigt.

Wie bei der Autonomie ist Zustandlosigkeit die bevorzugte Bedingung für Services und fördert die Wiederverwendbarkeit und Skalierbarkeit. Damit ein Service so wenig wie möglich beansprucht wird, muss die zugrunde liegende Servicelogik unter Berücksichtigung von stateful/stateless designt werden. Darüber hinaus sollte die Architektur selbst mit Erweiterungen für die Verschiebung von Zuständen ausgestattet werden.

Was kommt als nächstes?

Zustandslosigkeit und Autonomie gehen im Servicedesign Hand in Hand. Jedes dieser Prinzipien unterstützt die Ziele des anderen – und beide unterstützen schließlich die grundlegenden Ziele von SOA. Im letzten Teil dieser Serie werden wir einige Schlüsselbeziehungen zwischen serviceorientierten Design-Prinzipien diskutieren und zeigen, wie die Anwendung dieses Paradigmas durch die Verwendung von Serviceabstraktionsschichten erhöht werden kann.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!

Erfahren Sie mehr über Softwareentwicklung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close