Serviceorientierte Architektur (SOA)
Eine serviceorientierte Architektur (SOA) erlaubt den darauf gehosteten Diensten über verschiedene Plattformen und Sprachen hinweg zu kommunizieren, um Anwendungen zu bilden.
Auf einer SOA ist ein Service eine eigenständige Softwareeinheit, die eine bestimmte Aufgabe erfüllt. Diese Einheiten kommunizieren über ein loses Kopplungssystems, um Daten weiterzugeben oder Aktivitäten zu koordinieren.
Die Kopplung lässt sich als lose bezeichnen, weil der Client jedes Dienstes unabhängig von dem Dienst bleibt, den er benötigt. Darüber hinaus kann der Client – der seinerseits ein Dienst sein kann – mit anderen Diensten kommunizieren, auch wenn diese nicht verwandt sind.
SOA schafft eine hohe Interoperabilität zwischen Anwendungen und Diensten und verbessert die Skalierbarkeit, während es gleichzeitig die Kosten für die Entwicklung von Business-Service-Lösungen reduziert.
Zu den wichtigen Prinzipien von SOAs gehören:
- Der Geschäftswert ist wichtiger als die technische Strategie.
- Die strategischen Ziele sind wichtiger als der projektbezogene Nutzen.
- Grundlegende Interoperabilität ist wichtiger als benutzerdefinierte Integration.
- Shared Services sind wichtiger als zweckgebundene Implementierungen.
- Kontinuierliche Verbesserung ist wichtiger als sofortige Perfektion.
Serviceorientierte Architektur ist eine Implementierung des Servicekonzepts oder Servicemodells der Datenverarbeitung. Bei diesem Architekturstil übersetzen Entwickler Geschäftsprozesse in Softwaredienste, auf die das System über eine Reihe streng definierter Anwendungsprogrammschnittstellen (APIs) zugreifen. Eine dynamische Dienstorchestrierung bündelt sie in eine Anwendung.
Die Entstehung von SOA
Jahrzehntelang erforderte die Softwareentwicklung den Einsatz modularer Funktionselemente, die an mehreren Stellen innerhalb einer Anwendung eine bestimmte Aufgabe erfüllen. Allmählich setzte sich jedoch durch, dass Anwendungen sich Komponenten aus Pools von Hosting-Ressourcen teilten und Verteilte Datenbanken abfragten. Deshalb benötigten Unternehmen eine Möglichkeit, ihr verfahrensbasiertes Entwicklungsmodell an diese Realität anzupassen.
Der Remote Procedure Call (RPC) kristallisierte sich als beliebte Lösung heraus, mit der ein Softwareprozess einen anderen so aufrufen kann, als wäre er vor Ort, obwohl er in einer anderen Anwendung, an einem anderen Computer oder in einem anderen Rechenzentrum wohnt.
Das Problem mit dem RPC-Modell war jedoch, dass es zu viele Variationen in der Implementierung zuließ und einige Funktionen nicht bieten konnte:
- Systematisches Instrumentarium zum Bereitstellen von Sicherheit beim Informationsfluss;
- Governance in Bezug auf Zugriffsrechte auf die beteiligten Geschäftsprozesse; und
- Discovery, Verbindungsherstellung und Nachrichtenformate für die Dienste selbst.
Während das durch SOA eingeführte Servicekonzept ein fester Bestandteil des modernen Cloud Computing und der Virtualisierung ist, wurde SOA selbst weitgehend verdrängt.
Hauptziele von SOA
Es gibt drei Hauptziele von SOA, die jeweils unterschiedliche Teile des Anwendungslebenszyklus betreffen.
Das erste Ziel ist es, Prozeduren oder Softwarekomponenten als Services zu strukturieren. Dienste sind so konzipiert, dass sie lose mit Anwendungen gekoppelt sind, sodass sie nur bei Bedarf zum Einsatz kommen. Außerdem sollten Entwickler sie so aufbauen, dass sie möglichst konsistente Anwendungskomponenten bieten.
Das zweite Ziel ist das Bereitstellen eines Mechanismus zum Veröffentlichen verfügbarer Dienste, inklusive ihrer Funktions- und Eingabe/Ausgabe-Anforderungen (Input/Output, I/O, E/A). Die Dienste sollten so beschaffen sein, dass Entwickler sie problemlos in Anwendungen integrieren.
Das dritte Ziel von SOA ist es, die Nutzung dieser Dienste zu kontrollieren, um Sicherheits- und Governance-Probleme zu vermeiden. Sicherheit in SOAs erfordert besonders die Sicherheit der einzelnen Komponenten innerhalb der Architektur; Identitäts- und Authentifizierungsverfahren in Bezug auf diese Komponenten; und Sicherung der tatsächlichen Verbindungen zwischen den Komponenten der Architektur.
Implementierung
SOA ist hersteller- und technologieunabhängig. Das bedeutet, dass eine Vielzahl von Produkten zum Umsetzen der Architektur geeignet sind. Die Wahl hängt also davon ab, was die Architekten erreichen möchten.
SOA wird typischerweise mit Webdiensten wie SOAP (Simple Object Access Protocol) und WSDL (Web Services Description Language) aufgebaut. Weitere verfügbare Implementierungsoptionen umfassen:
- Windows Communication Foundation (WCF);
- gRPC; und
- Messaging – wie mit Java Message Service (JMS), ActiveMQ und RabbitMQ.
SOA-Implementierungen können ein oder mehrere Protokolle verwenden und ein Dateisystem-Tool verwenden, um Daten zu auszutauschen. Die Protokolle sind unabhängig von der zugrunde liegenden Plattform und Programmiersprache. Der Schlüssel zu einer erfolgreichen Architektur ist die Unabhängigkeit der Dienste, so dass diese ihre Aufgaben auf standardisierte Weise ausführen, ohne dass sie Informationen über die aufrufende Anwendung benötigen und ohne dass die aufrufende Anwendung Kenntnisse zu den Aufgaben des Dienstes braucht.
Häufige Anwendungsszenarien für SOA sind:
- Situational-Awareness-Systeme, vor allem für die Luftfahrt und das Militär
- Versorgungssysteme im Gesundheitssystem
- Zugriff mobiler Apps und Spiele auf Funktionen des mobilen Endgeräts (zum Beispiel das GPS)
- Virtualisierte Speichersysteme für Informationen und Content in Museen.
WS- und WSDL-Modelle von SOA
Anfänglich basierten SOA-Implementierungen auf RPC- und Object-Broker-Technologien, die um das Jahr 2000 verfügbar waren. Seitdem haben sich zwei neuere SOA-Modelle herausgebildet:
- Das Webservices-Modell (WS; verlangt eine stark strukturierte und formalisierte Verwaltung von Remote-Prozeduren und -Komponenten)
- Das Representational-State-Transfer-Modell (REST), bei dem der Zugriff auf entfernt gehostete Komponenten von Anwendungen über eine spezielle Internettechnologie erfolgt.
Das WS-Modell verwendet WSDL, um Schnittstellen mit Diensten zu verbinden, und SOAP, um Prozedur- oder Komponenten-APIs zu definieren. Beim WS-Ansatz verbinden sich Anwendungen über einen Enterprise Service Bus (ESB), der Unternehmen dabei hilft, ihre Anwendungen zu integrieren, Effizienz zu gewährleisten und die Data Governance zu verbessern. Das WS-Modell von SOA war nie besonders beliebt, zum einen wegen seiner inhärenten Komplexität, zum andern wegen der Inkompatibilität zwischen dem WS-Ansatz und dem RESTful-API-Modell des Internets. Das Internet und das damit verbundene Cloud-Computing-Modell haben spezifische Probleme mit SOA/WS offengelegt, und insgesamt ist die Branche zu einem anderen Modell übergegangen.
An seiner Stelle hat das REST-Modell breite Akzeptanz erfahren. RESTful-APIs bieten geringen Overhead und sind einfacher zu verstehen. SOA setzt außerdem auf das Prozeduraufrufmodell bei, das üblicherweise in der strukturierten Programmierung verwendet wird, und standardisiert die Art und Weise, wie IT-Profis Geschäftsprozesse automatisieren und verwenden, um Sicherheit und Governance zu gewährleisten.
Vorteile einer serviceorientierten Architektur
Vorteile von SOA sind:
- Wiederverwendbarkeit. Im Idealfall kann ein Dienst Teil mehrerer verschiedener Anwendungen sein. Das wird dadurch erleichtert, dass Entwickler sie in einem Service-Repository speichern und bei Bedarf miteinander verknüpfen. Dadurch sind Services allgemeine Ressourcen, die allen zur Verfügung stehen – vorbehaltlich notwendiger Governance-Einschränkungen. Wenn Unternehmen Dienste wiederverwende, sparen sie Zeit und Entwicklungskosten.
- Einfache Pflege. Da alle Dienste unabhängig sind, können Entwickler sie leicht anpassen und aktualisieren, ohne andere Dienste zu beeinträchtigen. Auch das senkt die Betriebskosten einer Organisation.
- Interoperabilität. Die Standardisierung des Kommunikationsprotokolls ermöglicht es Plattformen, Daten problemlos zwischen Clients und Diensten zu übertragen, unabhängig von den Sprachen, auf denen sie basieren.
- Zuverlässigkeit. SOA generiert zuverlässigere Anwendungen, da es einfacher ist, kleine Dienste zu debuggen als große Codeblöcke.
- Skalierbar. SOA ermöglicht das Ausführen von Diensten auf verschiedenen Servern und erhöht so die Skalierbarkeit. Darüber hinaus ermöglicht erlaubt das standardisierte Kommunikationsprotokoll Organisationen, das Interaktionsniveau zwischen Clients und Diensten zu reduzieren. Somit entsteht beim Skalieren ein vermehrter Traffic, der sich in der Regel noch bewältigen lässt.
Die Vorteile von SOA
Nachteile von SOA sind:
- Hohe Anfangsinvestitionen. Da Entwickler erst einmal ein Repository kleiner, in sich abgeschlossener Dienste entwickeln müssen, sind zu Beginn die Entwicklungskosten vergleichsweise hoch.
- Komplexität bei der Verwaltung. Das Dienstmanagement ist kompliziert, da die Dienste Millionen von Nachrichten austauschen, die schwer nachzuverfolgen sind.
- Lange Ladezeiten. Die Eingabeparameter von Diensten werden jedes Mal validiert, wenn Dienste interagieren, wodurch die Leistung verringert und die Lade- und Antwortzeiten erhöht werden.
SOA und Microservices
REST und das Internet verdrängten die klassische SOA, bevor sie wirklich an Zugkraft gewinnen konnten, und so findet man richtige SOA meist bei Legacy-Anwendungen, die oft um den ESB herum aufgebaut wurden. Der breitere Begriff Services wurden durch das RESTful-Denken in Softwareprozesse statt Geschäftsprozesse umgewandelt, und die softwarezentrische Sichtweise wurde unter dem Begriff Microservices bekannt.
Webservices sind immer noch ein geläufiger Begriff im Cloud Computing, wo er paketierte Cloud-Provider-Services für das Entwickeln Cloud-basierter Anwendungen bezeichnet. Es gibt Dutzende dieser Dienste von allen Public-Cloud-Anbietern, die alle über REST-Schnittstellen erreichbar sind.
Microservices sind kleine Softwarefunktionskomponenten, die ebenfalls mit REST-APIS verbunden sind. In der Praxis setzen solche Architekturen Sicherheit und Governance außerhalb der Service-/Microservice-APIs durch, üblicherweise mit einem Service Broker, der als Vermittler fungiert, um Zugriffsrechte zu authentifizieren. Da Softwareprozesse und Microservices Anwendungen bilden und Anwendungskomponenten miteinander verknüpft und nicht gemäß dem Workflow nacheinander aufgerufen werden, sind SOA-ähnliche Discovery- und Service-Repositorys überflüssig. Die Erkennung und Bindung von Microservices ist stattdessen so definiert, dass sie die Skalierbarkeit unter Last und Ausfallsicherheit unterstützt – Eigenschaften von Software in der Cloud.
Anwendungen nutzen Microservices gemeinsam und Cloud-Anbieter haben oft serverlose Pay-as-you-use-Modelle für Microservice-Hosting im Portfolio. In diesen Fällen gibt es einen formellen Microservice- oder Servicevertrag, um die spezifischen Leistungsgarantien und Zahlungsbedingungen zu beschreiben. Sogar interne Microservices können einen Vertrag haben, wenn die IT-Abteilungen anderen Geschäftsbereichen die Nutzung in Rechnung stellt.
