Softwaretechnik > Architekturmuster

Serviceorientierte Architektur (SOA)

Serviceorientierte Architektur (SOA) (service-orientied architecture) ist ein Architekturmuster (Architekturstil / Architekturparadigma) aus dem Bereich der Softwareentwicklung > verteilte Systeme.

Es gibt keine allgemeingültige Definition einer SOA - aber die grundsätzliche Idee besteht in der Implementierung von Geschäftsprozessen des Unternehmens und Bereitstellung in Form von Diensten innerhalb des Netzwerks.

Diese Dienste können dann zu Anwendungen / Applikationen oder zu höheren Diensten innerhalb des Unternehmens zusammengesetzt werden (Orchestrierung). Eine SOA bezieht sich somit nicht auf eine einzelne Anwendung alleine bzw. macht erst Sinn, wenn mehrere Anwendungen eines Unternehmens die zur Verfügung gestellten Dienste konsumieren (orchestrieren).

Der primäre Vorteil einer SOA ist die Wiederverwendbarkeit der Dienste innerhalb verschiedener Applikationen des Unternehmens.

SOA in der Praxis

Die Wiederverwendbarkeit und die damit verbundenen langfristig sinkende Kosten für die Entwicklung von Anwendungen sind oft die entscheidenden Argumente für den Einsatz einer SOA.

Leider wird dabei häufig übersehen, dass es überhaupt erst verschiedene Dienstkonsumenten innerhalb eines Unternehmens geben muss, bevor ein Dienst mehrfach wiederverwendet werden kann (sieht man von der Wiederverwendbarkeit eines Dienstes in einer evtl. weit in der Zukunft neu zu entwickelnden Applikation ab): Besitzt das Unternehmen primär eine einzelne Applikation (z. B. die Kundenstammdaten mit Bestellwesen) ist eine entsprechende Kapselung der Geschäftslogik (mit nativen Komponenten) einfacher zu realisieren (als über die Bereitstellung und dem Konsumieren von Diensten im Netzwerk innerhalb einer SOA).

Zusätzlich ist gerade in der heutigen Zeit mit schnellen Änderungen eine SOA besonders anfällig, weil sich die Schnittstellen evtl. sehr häufig ändern und es dann Kompatibilitätsprobleme gibt (mehrere Konsumenten verlassen sich auf die definierte Schnittstelle (als Vertrag) - in diesem Fall kann es zu einem Dienst-Versions-Chaos kommen (z. B. mehrere Dienste in der Form "Suche nach Kunde 1.0" / "Suche nach Kunde 1.1" inklusive der damit verbundenen Pflege auch älterer Schnittstellen und der notwendigen Dokumentation "Welche Applikation verwendet aktuell welchen Dienst") etc.).

Die Leistungsfähigkeit einer SOA hängt also indirekt von der Langlebigkeit der einzelnen Schnittstellen und der dahinter verborgenen Geschäftsprozesse ab.

In größeren Unternehmen erscheint der Aufbau einer SOA als sinnvoll, weil es viele Applikationen mit ähnlichen Anforderungen (z. B. "Kundenstammdaten ermitteln") gibt. Tatsächlich gibt es aber auch viele Geschäftsprozesse die eben gerade nicht geteilt werden (z. B. "Vergebe Kredit"), weil nur genau eine Applikation genau diesen Geschäftsprozess benötigt und eine Bereitstellung als Dienst dann unnötige Kosten verursacht. Oder es gibt zwar ähnlich Anforderungen, aber mit unterschiedlichen Ausprägungen (z. B. Applikation A und B benötigen den Geschäftsprozess "Kunde suchen", aber Applikation A sucht ausschließlich über die Kundennummer während Applikation B nur über den Namen sucht) - also müssen für jede Applikation unterschiedliche Dienste bereitgestellt werden, die dann doch einzeln betrachtet nicht in unterschiedlichen Applikationen wiederverwendet werden.

Tatsächlich begegnet man hier neben den rein technischen / geschäftslogischen Herausforderungen gerade in großen Unternehmen auch auf schwierige, politische Herausforderungen:

• Große Unternehmen sind oft in vgl. unabhängige Geschäftseinheiten / Abteilungen unterteilt, mit unterschiedlichem Management und eigenem Budget - eine SOA ist aber abteilungsübergreifend ausgelegt (Probleme: Wer bezahlt? Wer ist verantwortlich? Wer koordiniert? Wer wartet das System? Wie werden unabhängige abteilungspezifische Anforderungen umgesetzt?)
• Große Unternehmen haben in der Regel bereits Applikationen, die die Geschäftsprozesse abbilden - es ist ein vgl. langwieriger Prozess diese (oft) monolithischen Strukturen in ein verteiltes System (z. B. SOA) umzuwandeln
• Nicht jeder Mitarbeiter darf alle Daten (schon aus datenschutzrechtlichen Gründen) einsehen und damit darf u. U. nicht jede Abteilung jeden (unternehmensweit verfügbaren) Dienst einsetzen - bzw. eine SOA muss auch die Authentifizierung und Autorisierung der Applikation (genauer: des Benutzers) zur Verfügung stellen (was die Komplexität in der Erstellung der Dienste deutlich erhöht und / oder zusätzliche Dienste (und Wartung / Administration) für die Authentifizierung / Autorisierung notwendig macht)

Vorteile einer SOA

• Langfristig geringere Kosten durch die Wiederverwendbarkeit der Dienste

• Kapselung in unabhängige Dienste mit einer wohldefinierten und öffentlichen Schnittstelle
• Plattformunabhängigkeit

Nachteile einer SOA

• Hohe initiale Kosten bei der Analyse, Konzeption und Implementierung der SOA
• Wiederverwendbarkeit ist oft nur eingeschränkt und nur auf sehr lange Zeit gesehen möglich, was eine genauere Planung und Analyse der Einsetzbarkeit einer SOA im Unternehmen erforderlich macht
• Schnittstellenänderungen führen oft zu Kompatitibilitätsproblemen ("Versionschaos") und erhöhen damit die Komplexität
• In der Regel schlechtere Performance (z. B. Transformation von / in XML) und höheres Datenvolumen (z. B. XML), da die Dienstkommunikation einen zusätzlichen Aufwand verursacht oder die Dienstkommunikation in zusätzlichen nativen Komponenten gekapselt wird
• Die Kosten für die Bereitstellung und die Konfiguration der Bindung zwischen Dienstnutzer und Dienstanbieter ist häufig komplex und wird durch zusätzliche Fragestellungen (wie Authentifizierung / Autorisierung) erschwert
• Die Konzeption und Bereitstellung der Dienste als auch die Bindung der Dienste setzt ein höheres Know-How der Entwickler voraus, wodurch diese schwieriger zu ersetzen sind
• Die Budgetierung der Entwicklung / Wartung und Administration der zentralen (abteilungsübergreifenden) SOA gestaltet sich als politisch schwierige Herausforderung und muss von den Mitarbeitern und Managern unterstützt werden (höherer Kommunikationsaufwand erforderlich)