Was ist serviceorientierte Architektur?
Service-oriented architecture (SOA, serviceorientierte Architektur) ist eine Methode der Softwareentwicklung, bei der Softwarekomponenten, sogenannte Services, zur Erstellung von Geschäftsanwendungen verwendet werden. Jeder Service bietet eine Geschäftsfunktion, und die Services können auch plattform- und sprachübergreifend miteinander kommunizieren. Entwickler nutzen SOA, um Services in verschiedenen Systemen wiederzuverwenden oder mehrere unabhängige Services zu kombinieren, um komplexe Aufgaben zu erfüllen.
Zum Beispiel benötigen mehrere Geschäftsprozesse in einem Unternehmen die Funktion der Benutzerauthentifizierung. Anstatt den Authentifizierungscode für alle Geschäftsprozesse neu zu schreiben, können Sie einen einzigen Authentifizierungsservice erstellen und ihn für alle Anwendungen wiederverwenden. In ähnlicher Weise müssen fast alle Systeme in einer Gesundheitsorganisation, wie Patientenverwaltungs- und elektronische Gesundheitsaktensysteme (EHR), Patienten registrieren. Diese Systeme können einen einzigen, gemeinsamen Service aufrufen, um die Aufgabe der Patientenregistrierung durchzuführen.
Was sind die Vorteile der serviceorientierten Architektur?
Serviceorientierte Architektur (SOA) hat verschiedene Vorteile gegenüber den traditionellen monolithischen Architekturen, in denen alle Prozesse als eine einzelne Einheit ablaufen. Einige der wichtigsten Vorteile von SOA sind die folgenden:
Schnellere Markteinführung
Die Entwickler verwenden Services über verschiedene Geschäftsprozesse hinweg wieder, um Zeit und Kosten zu sparen. Sie können Anwendungen mit SOA viel schneller zusammenstellen als durch das Schreiben von Code und die Durchführung von Integrationen von Grund auf.
Effiziente Wartung
Es ist einfacher, kleine Services zu erstellen, zu aktualisieren und zu korrigieren als große Code-Blöcke in monolithischen Anwendungen. Die Änderung eines Services in der SOA hat keine Auswirkungen auf die Gesamtfunktionalität des Geschäftsprozesses.
Bessere Anpassungsfähigkeit
SOA ist besser an den technologischen Fortschritt anpassbar. Sie können Ihre Anwendungen effizient und kostengünstig modernisieren. So können zum Beispiel Organisationen des Gesundheitswesens die Funktionen älterer elektronischer Aufzeichnungssysteme für Patientendaten in neueren cloudbasierten Anwendungen nutzen.
Was sind die Grundprinzipien der serviceorientierten Architektur?
Es gibt keine fest definierten Standardrichtlinien für die Implementierung einer serviceorientierten Architektur (SOA). Allerdings gibt es einige Grundprinzipien, die bei allen SOA-Implementierungen gleich sind.
Interoperabilität
Jeder Service in einer SOA enthält Beschreibungsdokumente, die die Funktionalität des Services und die damit verbundenen Bedingungen festlegen. Jedes Client-System kann einen Service ausführen, unabhängig von der zugrunde liegenden Plattform oder Programmiersprache. Beispielsweise können Geschäftsprozesse Services nutzen, die sowohl in C# als auch in Python geschrieben sind. Weil es keine direkten Wechselwirkungen gibt, wirken sich Änderungen in einem Service nicht auf andere Komponenten aus, die diesen Service nutzen.
Lose Verkoppelung
Services in SOA sollten lose verkoppelt sein und so gering wie möglich von externen Ressourcen wie Datenmodellen oder Informationssystemen abhängen. Sie sollten auch zustandslos sein und keine Informationen aus vergangenen Sitzungen oder Transaktionen beibehalten. Auf diesem Weg hat die Änderung eines Services keine signifikanten Auswirkungen auf die Client-Anwendungen und andere Services, die diesen Service nutzen.
Abstraktion
Kunden oder Benutzer von Services in SOA müssen die Code-Logik oder Implementierungsdetails des Services nicht kennen. Für sie sollten die Services wie eine Blackbox erscheinen. Die Kunden erhalten die erforderlichen Informationen darüber, was der Service leistet und wie er zu nutzen ist, durch Serviceverträge und andere Dokumente zur Servicebeschreibung.
Granularität
Services in einer SOA sollten eine angemessene Größe und einen angemessenen Umfang haben, idealerweise in einer diskreten
Geschäftsfunktion pro Service. Die Entwickler können dann mehrere Services verwenden, um einen zusammengesetzten Service zur Ausführung komplexer Vorgänge zu erstellen.
Was sind die Komponenten in serviceorientierter Architektur?
Es existieren vier Hauptkomponenten in der serviceorientierten Architektur (SOA).
Service
Services sind die grundlegenden Bausteine einer SOA. Sie können privat sein – nur für interne Benutzer einer Organisation – oder öffentlich – über das Internet für jeden zugänglich. Jeder Service hat drei individuelle Hauptfunktionen.
Service-Implementierung
Bei der Service-Implementierung handelt es sich um den Code, der die Logik für die Ausführung der spezifischen Servicefunktion, wie beispielsweise die Benutzerauthentifizierung oder die Rechnungskalkulation, aufbaut.
Service-Anbieter
Der Service-Anbieter erstellt, pflegt und bietet einen oder mehrere Services an, den/die andere nutzen können. Unternehmen können ihre eigenen Services erstellen oder sie von Drittanbietern beziehen.
Service-Konsument
Der Service-Konsument fordert den Service-Anbieter auf, einen bestimmten Service auszuführen. Das kann ein ganzes System, eine Anwendung oder ein anderer Service sein. Der Service-Vertrag legt die Regeln fest, die der Service-Anbieter und der Konsument bei der Interaktion miteinander beachten müssen. Service-Anbieter und Konsumenten können verschiedenen Abteilungen, Organisationen und sogar Branchen angehören.
Service-Register
Ein Service-Register oder Service-Repository ist ein über das Netz zugängliches Verzeichnis der verfügbaren Services. Es speichert Dokumente zur Service-Beschreibung von Service-Anbietern. Die Beschreibungsdokumente enthalten Informationen über den Service und wie man mit ihm kommuniziert. Die Konsumenten von Services können die von ihnen benötigten Services leicht über das Service-Register finden.
Wie funktioniert die serviceorientierte Architektur?
In einer serviceorientierten Architektur (SOA) funktionieren die Services unabhängig und stellen ihren Benutzern Funktionen oder Datenaustausch zur Verfügung. Der Konsument fordert Informationen an und sendet Eingabedaten an den Service. Der Service verarbeitet die Daten, führt die Aufgabe aus und sendet eine Antwort zurück. Wenn eine Anwendung beispielsweise einen Autorisierungsservice nutzt, gibt sie dem Service den Benutzernamen und das Passwort. Der Service verifiziert den Benutzernamen und das Passwort und gibt eine entsprechende Antwort zurück.
Kommunikationsprotokolle
Services kommunizieren nach festgelegten Regeln, die die Datenübertragung über ein Netz regeln. Diese Regeln werden als Kommunikationsprotokolle bezeichnet. Zu einigen Standardprotokollen für die Implementierung einer SOA gehören die folgenden:
• Simple Object Access Protocol (SOAP)
• RESTful-HTTP
• Apache Thrift
• Apache ActiveMQ
• Java Message Service (JMS)
Sie können sogar mehr als ein Protokoll in Ihrer SOA-Implementierung verwenden.
Was ist ein ESB in einer serviceorientierten Architektur?
Der Enterprise Service Bus (ESB) ist eine Software, die Sie für die Kommunikation mit einem System verwenden können, das über mehrere Services verfügt. Er stellt die Kommunikation zwischen Services und Servicenutzern unabhängig von der Technologie her.
Vorteile von ESB
Ein ESB bietet Kommunikations- und Transformationsfunktionen über eine wiederverwendbare Service-Schnittstelle. Sie können sich einen ESB als einen zentralen Service vorstellen, der Serviceanfragen an den entsprechenden Service weiterleitet. Er wandelt die Anfrage auch in ein Format um, das für die zugrunde liegende Plattform und Programmiersprache des Services akzeptabel ist.
Welches sind die Grenzen bei der Implementierung einer serviceorientierten Architektur?
Eingeschränkte Skalierbarkeit
Die Skalierbarkeit des Systems wird erheblich beeinträchtigt, wenn Services viele Ressourcen gemeinsam nutzen und sich koordinieren müssen, um ihre Funktionen zu erfüllen.
Zunehmende Wechselwirkungen
Systeme mit serviceorientierter Architektur (SOA) können im Laufe der Zeit immer komplexer werden und mehrere Wechselwirkungen zwischen den Services entwickeln. Sie können schwer zu ändern oder zu debuggen sein, wenn mehrere Services sich gegenseitig in einer Schleife aufrufen. Gemeinsam genutzte Ressourcen, wie beispielsweise zentralisierte Datenbanken, können das System ebenfalls verlangsamen.
Single Point of Failure
Bei SOA-Implementierungen mit einem ESB bildet der ESB einen Single Point of Failure (einzelner Ausfallpunkt). Es handelt sich um einen zentralisierten Service, was der Idee der Dezentralisierung, für die SOA eintritt, widerspricht. Wenn der ESB ausfällt, können Clients und Services überhaupt nicht mehr miteinander kommunizieren.
Was sind Microservices?
Die Microservices-Architektur besteht aus sehr kleinen und vollkommen unabhängigen Softwarekomponenten, den so genannten Microservices, die sich auf eine einzige Aufgabe spezialisieren und fokussieren. Microservices kommunizieren über APIs, also über Regeln, die Entwickler erstellen, damit andere Softwaresysteme mit ihrem Microservice kommunizieren können.
Der Architekturstil der Microservices ist am besten für moderne Cloud-Computing-Umgebungen geeignet. Sie arbeiten oft in Containern – unabhängigen Softwareeinheiten, die den Code mit all seinen Abhängigkeiten zusammenfassen.
Vorteile der Microservices
Microservices sind unabhängig skalierbar, schnell, portabel und plattformunabhängig – Eigenschaften, die die Cloud ausmachen. Sie sind außerdem entkoppelt, was bedeutet, dass sie nur begrenzt oder gar nicht von anderen Microservices abhängig sind. Um das zu erreichen, haben Microservices lokalen Zugriff auf alle Daten, die sie benötigen, anstatt eines Fernzugriffs auf zentralisierte Daten, auf die auch andere Systeme zugreifen und sie nutzen. Dies führt zu einer Vervielfältigung der Daten, die aber durch die Leistung und Flexibilität von Microservices wieder wettgemacht wird.
SOA im Vergleich zu Microservices
Die Microservices-Architektur ist eine Weiterentwicklung des Architekturstils von SOA. Microservices beheben die Unzulänglichkeiten von SOA und machen die Software besser kompatibel für moderne Cloud-basierte Unternehmensumgebungen. Sie sind feinkörnig und bevorzugen die Vervielfältigung von Daten im Gegensatz zur gemeinsamen Nutzung von Daten. Das macht sie völlig unabhängig mit ihren eigenen Kommunikationsprotokollen, die über leichtgewichtige APIs zugänglich sind. Es ist im Wesentlichen die Aufgabe der Konsumenten, den Microservice über seine API zu nutzen, sodass ein zentralisierter ESB nicht mehr erforderlich ist.
Wie hilft Ihnen AWS bei der Implementierung von Microservices?
AWS ist ein großartiger Ort zum Entwickeln moderner Anwendungen mit modularen Architekturmustern, Serverless-Betriebsmodellen und agilen Entwicklungsprozessen. Es bietet die umfassendste Plattform für den Aufbau hochverfügbarer Microservices, um moderne Anwendungen jeden Umfangs und jeder Größenordnung zu betreiben. Sie können zum Beispiel Folgendes tun:
• Erstellen, isolieren und betreiben Sie sichere Microservices in verwalteten Containern, um den Betrieb zu vereinfachen und den Verwaltungsaufwand zu reduzieren.
• Nutzen Sie AWS Lambda, um Ihre Microservices ohne Bereitstellung und Verwaltung von Servern auszuführen.
• Wählen Sie aus 15 relationalen und nicht-relationalen, speziell entwickelten AWS-Datenbanken zur Unterstützung der Microservices-Architektur.
• Überwachen und steuern Sie Microservices, die auf AWS laufen, ganz einfach mit AWS App Mesh.
• Überwachen und beheben Sie Fehler bei komplexen Microservice-Interaktionen mit AWS X-Ray.
Microservices auf AWS helfen Ihnen, schneller zu innovieren, Risiken zu reduzieren, die Markteinführung zu beschleunigen und die Gesamtbetriebskosten zu senken. Starten Sie noch heute mit SOA und Microservices auf AWS, indem Sie ein AWS-Konto erstellen.
Nächste Schritte auf AWS
Sie erhalten sofort Zugriff auf das kostenlose Kontingent von AWS.
Beginnen Sie mit der Entwicklung mit AWS in der AWS-Managementkonsole.