Eine serviceorientierte Architektur (SOA) ist ein Architekturmuster im Entwurf von Computersoftware, bei dem Anwendungskomponenten Dienste für andere Komponenten über ein Kommunikationsprotokoll bereitstellen, typischerweise über ein Netzwerk. Die Prinzipien der Serviceorientierung sind unabhängig von Produkten, Anbietern oder Technologien.
SOA erleichtert es Softwarekomponenten über verschiedene Netzwerke hinweg, miteinander zu arbeiten.
Webdienste, die gemäß der SOA-Architektur erstellt wurden, machen den Webdienst tendenziell unabhängiger. Die Webdienste selbst können Daten miteinander austauschen und benötigen aufgrund der zugrunde liegenden Prinzipien, auf denen sie erstellt werden, keinerlei menschliche Interaktion und auch keine Codeänderungen. Es stellt sicher, dass die Webdienste in einem Netzwerk nahtlos miteinander interagieren können.
SOA basiert auf einigen Schlüsselprinzipien, die unten erwähnt werden
- Standardisierter Servicevertrag - Services unterliegen einer Servicebeschreibung. Ein Dienst muss eine Beschreibung haben, die beschreibt, worum es bei dem Dienst geht. Auf diese Weise können Clientanwendungen leichter verstehen, was der Dienst tut.
- Lose Kopplung - Weniger Abhängigkeit voneinander. Dies ist eines der Hauptmerkmale von Webdiensten, das lediglich besagt, dass zwischen den Webdiensten und dem Client, der den Webdienst aufruft, eine möglichst geringe Abhängigkeit bestehen sollte. Wenn sich die Servicefunktionalität zu einem bestimmten Zeitpunkt ändert, sollte die Clientanwendung nicht beschädigt oder nicht mehr funktionieren.
- Dienstabstraktion - Dienste verbergen die Logik, die sie kapseln, vor der Außenwelt. Der Dienst sollte nicht offenlegen, wie er seine Funktionalität ausführt. Es sollte der Client-Anwendung nur mitteilen, was sie tut und nicht, wie sie es tut.
- Wiederverwendbarkeit von Diensten - Die Logik ist in Dienste unterteilt, um die Wiederverwendung zu maximieren. In jedem Entwicklungsunternehmen ist die Wiederverwendbarkeit ein großes Thema, da man offensichtlich nicht immer wieder Zeit und Mühe aufwenden möchte, um denselben Code für mehrere Anwendungen zu erstellen, für die sie erforderlich sind. Sobald der Code für einen Webdienst geschrieben ist, sollte er daher in der Lage sein, mit verschiedenen Anwendungstypen zu arbeiten.
- Dienstautonomie - Dienste sollten die Kontrolle über die von ihnen gekapselte Logik haben. Der Dienst weiß alles über die angebotenen Funktionen und sollte daher auch die vollständige Kontrolle über den darin enthaltenen Code haben.
- Dienstzustandslosigkeit - Im Idealfall sollten Dienste zustandslos sein. Dies bedeutet, dass Dienste keine Informationen von einem Staat zum anderen zurückhalten sollten. Dies müsste entweder über die Client-Anwendung erfolgen. Ein Beispiel kann eine Bestellung sein, die auf einer Einkaufsseite aufgegeben wird. Jetzt können Sie einen Webservice haben, der Ihnen den Preis eines bestimmten Artikels angibt. Wenn die Artikel jedoch einem Warenkorb hinzugefügt werden und die Webseite zu der Seite navigiert, auf der Sie die Zahlung ausführen, sollte der Webservice die Verantwortung für den Preis des Artikels, der auf die Zahlungsseite übertragen werden soll, nicht übernehmen. Stattdessen muss dies von der Webanwendung durchgeführt werden.
- Erkennbarkeit von Diensten - Dienste können erkannt werden (normalerweise in einer Dienstregistrierung). Wir haben dies bereits im Konzept der UDDI gesehen, die eine Registrierung durchführt, die Informationen über den Webdienst enthalten kann.
- Service Composability - Services teilen große Probleme in kleine Probleme auf. Man sollte niemals alle Funktionen einer Anwendung in einen einzigen Dienst einbetten, sondern den Dienst in Module mit jeweils separaten Geschäftsfunktionen aufteilen.
- Dienstinteroperabilität - Dienste sollten Standards verwenden, die es verschiedenen Abonnenten ermöglichen, den Dienst zu nutzen. In Webdiensten werden Standards wie XML und Kommunikation über HTTP verwendet, um sicherzustellen, dass sie diesem Prinzip entsprechen.