Orchestrierung von Diensten Was ist Service Oriented Architecture (SOA)?

Eine Service-orientierte Architektur (Service Oriented Architecture, SOA) ist ein anpassbares, flexibles Architekturmuster im Bereich der verteilten Systeme,das helfen soll, Dienste in IT-Systemen modular zu strukturieren und besser zu nutzen.

Anbieter zum Thema

Dell GmbH

Schneider Electric GmbH

Vogel IT-Medien GmbH

Erstmals wurde der IT-Begriff Service Oriented Architecture (SOA) im Jahre 1996 von dem bekannten US- Marktforschungsunternehmen Gartner benutzt. Obwohl Gartner als der „Erfinder“ der SOA gilt, konnte sich bis heute keine allgemein gültige Definition durchsetzen.

Stark vereinfacht ist SOA eine Methode zur Modularisierung von IT-Komponenten, zum Beispiel Datenbanken, Server und Websites in „niedere Services“ wie Kontoeröffnung, Bestands- und Bonitätsprüfung. In der Folge werden diese Leistungen dann zu „höheren Diensten“ zusammengefasst beziehungsweise orchestriert. Im Fokus stehen also demnach keine technischen Prozesse wie Datenbankabfragen oder die Aufbereitung von Daten, sondern die Zusammenführung von IT-Leistungen zu Aufgaben wie zum Beispiel eine Kreditvergabe, Kundenbestellung, Prüfung der Wirtschaftlichkeit eines Projekts oder einer Unternehmung.

Flexible, anpassbare IT-Architektur

Oder anders gewendet: Service Oriented Architecture ist eine bewusst gewählte Struktur zur Integration von Anwendungen, indem die Komplexität der einzelnen Anwendungen hinter den standardisierten Schnittstellen im Hintergrund bleiben.

Durch das Zusammensetzen von einzelnen Services niedriger Abstraktionsebenen können so recht schnell, flexibel und insbesondere unter größtmöglicher Wiederverwendbarkeit IT-Services höherer Abstraktionsebenen erzeugt werden. Die Erfahrung hat gezeigt, dass oftmals Entwickler herkömmliche Anwendungen so entwerfen, dass eine Wiederverwendung selbst innerhalb der eigenen Anwendung problematisch ist.

Die logische Konsequenz: Es werden Applikations-Landschaften mit extrem hohen Redundanzen gebildet. Wartungen und Änderungen sowie Neuentwicklungen gestalten sich häufig sehr aufwendig oder ineffizient.

Eine Möglichkeit der Implementierung von SOA ist das Angebot dieser Dienste im Internet oder in der Cloud. Die Kommunikation untereinander erfolgt über SOAP, REST, XML-RPC oder ähnliche Protokolle.

Praxisbeispiel Bestellprozess

Eine Service Oriented Architecture kann an dem Beispiel einer Kundenbestellung bei einem Versandhändler verdeutlicht werden. In diesem Fall ergeben sich folgende Abläufe: Erfassung der Bestellung, Verfügbarkeitsprüfung, Bonitätsprüfung des Kunden, Auftrag, Kommissionierung, Versand, Faktura, Zahlungseingang. Und für jeden Schritt im Ablauf wird ein Dienst bereitgestellt.

Die Dienste können auch auf unterschiedlichen Systemen oder in verschiedenen Unternehmen implementiert sein. Zum Beispiel kann die Bonitätsprüfung des Kunden auch von einem externen Finanzdienstleister ermittelt werden. Wichtig ist dabei, dass sie immer gleich abläuft, auch wenn sie von unterschiedlichsten Prozessen oder sogar Firmen genutzt wird. Soll die Bonitätsprüfung von einem anderen Dienstleister ausgeführt werden, so muss dieser Dienst nur bei einem anderen Anbieter aufgerufen werden.

Zielsetzungen

Bei einer Service-orientierten Architektur geht es vor allem um die langfristige Kostenreduktion in der Software-Entwicklung sowie um eine optimierte Flexibilität der Prozesse, indem einzelne Dienste wiederverwendbar gemacht werden. Die SOA verlangt nach einer sehr hohen Integration der einzelnen IT-Komponenten beziehungsweise Dienste, damit deren Orchestrierung auch diese gewünschten Kostensenkungen erfüllen kann.

Die Service Oriented Architecture ist ein individuelles Architekturparadigma und kein Webservice. Des Weiteren löst sie auch keine fachlichen Probleme. Da es keine „Standard-SOA“ gibt, muss jedes Unternehmen seine SOA immer auf die eigenen Bedürfnisse anpassen

Kritikpunkte

Mit der Implementierung einer Service-orientierten Architektur entsteht durch die Entkopplung von Diensten mehr Aufwand als herkömmliche monolithische Programmstrukturen. Da die Entwickler über ein großes Know-how verfügen müssen, sind diese auch nicht so leicht ersetzbar und die Abhängigkeit steigt.

SOA wird zumeist mit Diensten umgesetzt, die oftmals per XML miteinander kommunizieren. Doch für XML wird bei der Analyse und Nutzung im Programmablauf derzeit wesentlich mehr Rechenzeit und bei der Übertragung ein höheres Datenvolumen eingefordert. Dies verursacht zusätzliche „Overheads“ und Kosten.

(ID:45398120)