Serviceorientierte Architektur


Serviceorientierte Architektur (SOA, englisch service-oriented architecture), auch dienstorientierte Architektur, ist ein Architekturmuster der Informationstechnik aus dem Bereich der verteilten Systeme, um Dienste von IT-Systemen zu strukturieren und zu nutzen. Eine besondere Rolle spielt dabei die Orientierung an Geschäftsprozessen, deren Abstraktionsebenen die Grundlage für konkrete Serviceimplementierungen sind: „Vergib einen Kredit“ ist beispielsweise auf einer hohen Ebene angesiedelt, dahinter verbirgt sich bei einem Bankunternehmen ein Geschäftsprozess mit mehreren beteiligten Personen und informationstechnischen Systemen („Eröffnen der Geschäftsbeziehung“, „Eröffnen eines oder mehrerer Konten“, „Kreditvertrag...“ und so weiter), während „Trage den Kunden ins Kundenverzeichnis ein“ ein Dienst auf einer niedrigeren Ebene ist. Durch Zusammensetzen (Orchestrierung) von Services niedriger Abstraktionsebenen können so recht flexibel und unter Ermöglichung größtmöglicher Wiederverwendbarkeit Services höherer Abstraktionsebenen geschaffen werden.

Inhaltsverzeichnis

Allgemeines


Vereinfacht kann SOA als Methode bzw. Paradigma angesehen werden, die vorhandenen IT-Komponenten wie Datenbanken, Server und Websites in Dienste zu kapseln und dann so zu koordinieren („Orchestrierung“), dass ihre Leistungen zu höheren Diensten zusammengefasst und anderen Organisationsabteilungen oder Kunden zur Verfügung gestellt werden können. Maßgeblich sind also nicht technische Einzelaufgaben wie Datenbankabfragen, Berechnungen und Datenaufbereitungen, sondern die Zusammenführung dieser IT-Leistungen zu „höheren Zwecken“ – wie Ausführen einer Bestellung oder Prüfen der Rentabilität einer Abteilung usw. –, die eine Organisationsabteilung anbietet. Bei SOA handelt es sich somit um eine Struktur, welche die Unternehmensanwendungsintegration ermöglicht, indem die Komplexität der einzelnen Anwendungen („Applications“) hinter den standardisierten Schnittstellen verborgen wird.

Ziele sind hierbei die langfristige Senkung von Kosten in der Softwareentwicklung und eine höhere Flexibilität der Geschäftsprozesse durch Wiederverwendung bestehender Services. Die Kosten der Programmierung der n-ten mit SOA realisierten Anwendung sollen entfallen, da bereits alle nötigen Services vorhanden seien und diese nur noch orchestriert werden müssten. Es verblieben somit nur die Kosten für die Businessanalyse und Softwarekonfiguration.

SOA erfordert eine sehr starke Integration der einzelnen IT-Komponenten, damit deren Orchestrierung kostengünstig gelingen kann. SOA spielt somit bereits bei der Auswahl von IT-Komponenten eine Rolle.

Eine technische Form der Umsetzung von SOA ist das Anbieten dieser Dienste im Internet oder in der Cloud. Die Kommunikation zwischen solchen angebotenen Diensten kann über SOAP, REST, XML-RPC oder ähnliche Protokolle erfolgen. Der Nutzer dieser Dienste weiß nur, dass der Dienst angeboten wird, welche Eingaben er erfordert und welcher Art das Ergebnis ist. Details über die Art und Weise der Ergebnisermittlung müssen nicht bekannt sein.

Welche Dienste nutzbar sind und wie sie angesteuert werden, kann durch einen Verzeichnisdienst wie UDDI in Erfahrung gebracht werden.

Definition


Der Begriff „serviceorientierte Architektur“ wurde 1996 von dem Marktforschungsunternehmen Gartner erstmals genutzt.[1] Gartner gilt daher als Erfinder des Begriffs SOA. Es gibt keine allgemein akzeptierte Definition von SOA. Dennoch wird häufig die Definition der OASIS aus dem Jahr 2006 zitiert:

„a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains“[2]

„SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird.“[3]

Zentrales Thema aller Definitionen sind die Dienste. Im Folgenden werden die idealtypischen Eigenschaften von Diensten in einer SOA aufgeführt. In der Praxis werden nicht alle dieser Anforderungen vollständig eingehalten.[4]

Abschließend ist anzumerken, dass es „die SOA“ nicht gibt; SOA ist vielmehr nur eine Sichtweise, die auf verschiedene Arten interpretiert werden kann.

Abgrenzung


Beispiel


Als Beispiel für einen Geschäftsprozess dient die Bestellung eines Kunden bei einem Versandhändler. Bei diesem gibt es folgende Prozessschritte:

Erfassung – Verfügbarkeitsprüfung – Bonitätsprüfung – Bestellung – Kommissionierung – Versand – Rechnungsstellung – Zahlungseingang

Für jeden Geschäftsprozessschritt gibt es einen Dienst. Die Implementierung – Programmiersprache, Systemvoraussetzungen usw. – kann unterschiedlich sein. Auch können die Dienste auf unterschiedlichen Systemen, sogar in unterschiedlichen Unternehmen implementiert sein. So könnte die Zahlungsfähigkeit des Kunden von einem Finanzdienstleister ermittelt werden, oder die diversen Logistikdienste werden von einem Logistikdienstleister erbracht. Schlüsselinformationen wie Kundennummer oder Artikelnummer werden den Diensten von der Infrastruktur zur Verfügung gestellt, so weit diese jeweils gebraucht werden.

Die Abfolge muss nicht so sequentiell erfolgen wie dargestellt. Im Gegenteil, die meisten Geschäftsprozessschritte können scheitern. Mangelnder Bestand, fehlende Bonität und ausbleibender Zahlungseingang führen zu Verzweigungen, die entsprechend abweichende Vorgehensweisen erfordern. Auch die gleichzeitige Verarbeitung mehrerer Geschäftsprozessschritte – beispielsweise Versand und Rechnungsstellung – ist möglich.

Wichtig ist jedoch, dass beispielsweise die Bonitätsprüfung immer dieselbe ist, auch wenn sie von unterschiedlichsten Prozessen oder sogar Firmen genutzt wird. Damit werden wichtige Ziele von SOA, wie zum Beispiel leichtere Pflegbarkeit, bessere Durchgängigkeit und mehr Einheitlichkeit, erreicht: Ein einmal implementierter Dienst kann auf Dauer erhalten bleiben, er muss nicht immer wieder angefasst werden, wenn sich Geschäftsprozesse ändern, wodurch Aufwand gespart und Fehler vermieden werden.

Entscheidet sich das Unternehmen, die Bonitätsprüfung in andere Hände zu legen, so muss die Infrastruktur diesen Dienst nur bei einem anderen Anbieter aufrufen. Sonst ändert sich nichts weiter.

Implementierung einer SOA


Eine Implementierung einer SOA basiert wesentlich auf Entscheidungen über die Kommunikation und Integration zwischen Dienstgebern (auch Dienstanbieter) und Dienstnehmern (auch Dienstnutzer, Dienstkonsument) sowie der Abbildung von Geschäftsprozessen.

Für die Kommunikation zwischen Dienstnutzer und -anbieter können beliebige Netzwerkprotokolle genutzt werden, da diese lediglich als Transportvehikel für die eigentliche Nachricht der Anwendung dienen. Verbreitet sind Protokolle wie IIOP, DCOM, DCE oder SNA, CORBA, SAP RFC (Remote Function Call) und auch das Web-Übertragungsprotokoll HTTP, das trotz einiger Nachteile im Bereich Sicherheit und Zuverlässigkeit durch das Internet besondere Popularität erlangte. Auch wenn Webservice kein normierter Begriff ist, wird im gängigen Sprachgebrauch damit die Übertragung von Nachrichten zwischen Anwendungen unter Verwendung des HTTP-Transportprotokolls bezeichnet. Alternativ zu HTTP werden auch hin und wieder die asynchronen Protokolle SMTP und FTP eingesetzt.

Da HTTP ein Transportprotokoll zur Sicherstellung der vollständigen und fehlerfreien Übertragung von beliebigen Nachrichten ist, sagt es über Struktur und Inhalt der übertragenen Nachricht nichts aus. Die eigentliche Nachricht wird deshalb nochmals in ein Webservice-Protokoll eingepackt. Denkbar sind dabei REST, JSON oder JMS basierte Übertragung oder SOAP-basierte Nachrichten, die über die WSDL beschrieben werden und beide per XML formuliert werden. AMQP ist hierzu eine Alternative, da es als ein binäres offenes Format für eine Message Oriented Middleware (MOM) nicht über HTTP, sondern direkt über TCP Daten austauscht.

Die Integration einzelner Dienste kann in einer SOA über Punkt-zu-Punkt-Verbindungen realisiert werden. Bei Punkt-zu-Punkt-Verbindungen wird eine Verbindung zwischen Dienstgeber und -nutzern individuell entworfen, entwickelt und administriert. Bei einer großen Anzahl von Kommunikationswegen empfiehlt es sich allerdings die Nachrichten grundsätzlich über einen zwischengeschalteten Vermittler, einer Middleware oder auch Message-Broker genannt, zu senden. Diese Middleware übernimmt wiederkehrende Arbeiten wie die Wandlung von Protokollen, Filtern und Umleiten (Routing) von Nachrichten und garantiert deren sichere Zustellung und Ereignisbearbeitung. Wenn diese Middleware beliebig erweiterbar und protokollunabhängig aufgebaut ist, spricht man von einem Enterprise Service Bus (ESB). Von Ausnahmen abgesehen, reduziert eine Message Oriented Middleware die Gesamtkomplexität einer Rechnerlandschaft bereits bei sehr wenigen miteinander kommunizierenden Rechnern.

Die Abbildung von Geschäftsprozessen kann speziell entwickelt werden oder einen Standard wie BPEL nutzen. In BPEL beschriebene Prozesse sind auf geeigneten Plattformen direkt ausführbar. Die BPEL eignet sich damit zur technischen Implementierung von Geschäftsprozessen bzw. zur Definition der Orchestrierung von Diensten. Im Jahr 2007 bildeten viele SOA-Implementierungen die Geschäftsprozesse durch speziell dafür entwickelte Anwendungen ab. Langfristig wird erwartet, dass sich BPEL für die Abbildung der Geschäftsprozesse durchsetzt.[4]

Bei der Implementierung wird das SOA-Paradigma in der Regel ab einem bestimmten Punkt durchbrochen; die einzelnen Dienste der SOA werden dann durch reine Clients wie beispielsweise Webbrowser angesprochen, die an sich nicht mehr Teil der SOA sind.

Die Aktivitäten, Entscheidungen, Rollen und Verantwortlichkeiten zur Regulierung und Kontrolle einer serviceorientierten Architektur werden als SOA-Governance bezeichnet. Innerhalb der SOA-Governance werden die Regeln einer SOA erarbeitet und überwacht.

Modellierung einer SOA


Es gibt diverse Möglichkeiten, SOA mit einer Modellierungssprache zu beschreiben. Von der OMG gibt es die Open-Source-Spezifikation SoaML, mit der man SOA-Dienste mittels eines erweiterten UML-Profils durch Verwendung eigener Stereotype darstellen kann.

Technische Realisierung zur Laufzeit


Die Interaktion zwischen Dienstanbieter und Dienstnehmer läuft nach dem Paradigma von (publish or register), find, bind, execute, zu deutsch: (veröffentlichen oder registrieren), finden, binden, ausführen, ab.[6]

Publish or register
Der Diensteanbieter veröffentlicht oder registriert seinen Dienst in einem Verzeichnis.
Find
Die Softwarekomponente, die einen Dienst benutzen möchte, sucht ihn in einem Verzeichnis. Wird ein passender Dienst gefunden, kann zum nächsten Schritt übergegangen werden.
Bind
Die benutzende Komponente erhält vom Verzeichnis eine Referenz (Adresse), unter der sie auf den Dienst zugreifen kann. Der Funktionsaufruf wird an diese Adresse gebunden.
Execute
Der Dienst wird aufgerufen. Eingabeparameter werden an den Dienst übermittelt und Ausgabeparameter als Antwort auf den Aufruf zurückgeliefert.

Umfeld


Der Begriff serviceorientierte Architektur ist in das folgende Umfeld einzuordnen:

Risiken der SOA-Einführung


Durch das Ausmaß an Beeinflussung bestehender Organisationsstrukturen und Geschäftsprozesse hängt die Einführung einer serviceorientierten Architektur maßgeblich von der Unterstützung und Mitarbeit der Belegschaft und vor allem des Managements ab. Durch seine größere Komplexität gegenüber monolithischen Programmstrukturen erfordert die Entwicklung einer SOA einen höheren Initialaufwand und spielt ihre Einsparungen erst dann aus, wenn grundlegende Services bereits existieren und in breiteren Anwendungsgebieten eines Unternehmens genutzt werden können. Die Einführung für ein einzelnes Projekt in der Hoffnung, dieses zu verbessern, ist durch die höhere Komplexität in der Regel zum Scheitern verurteilt und auch sinnlos, solange nicht die Anforderungen anderer potenzieller Anwendungsbereiche geklärt sind. Außerdem erfordern Design, Implementation und Wartung einer SOA ein hohes Maß an Methodenunterstützung.

Daher hat sich die Möglichkeit einer Wiederverwendung oder gemeinsamen Nutzung von Services oder Servicemodulen durch andere Prozesse, Abteilungen usw. nicht im erhofften Umfang realisieren lassen; ihre Wahrscheinlichkeit wird selbst von Gartner Research – den Urhebern des Konzepts – auf nur 20 Prozent geschätzt.[7] Zudem konfligiert das Ziel der Wiederverwendbarkeit mit dem der Flexibilität. Daher sind viele SOA-Projekte gescheitert. Während laut AMR Research im Jahr 2007 22 Milliarden, nach IDC 6 Milliarden US-Dollar für SOA-Projekte ausgegeben wurden, ist der Hype (und damit auch der Umfang der neu veröffentlichten Literatur zum Thema SOA) seit der Finanzkrise 2008 deutlich zurückgegangen. Relevant bleiben werden nach Experteneinschätzungen jedoch andere serviceorientierte Architekturansätze wie Software as a Service (SaaS) und Cloud Computing.[8]

Kritik


Siehe auch


Literatur


Hauptquellen


Weblinks


Einzelnachweise


  1. Research Note SPA-401-068, 12. April 1996, "'Service Oriented' Architectures, Part 1" und SSA Research Note SPA-401-069, 12. April 1996, "'Service Oriented' Architectures, Part 2"
  2. Reference Architecture Foundation for Service Oriented Architecture Version 1.0, 04. December 2012 online
  3. Reference Model for Service Oriented Architecture 1.0,Committee Specification 1, 2. August 2006 oasis-open.org
  4. a b Bianco Phil, Kotermanski Rick, Merson Paulo: Evaluating a Service-Oriented Architecture. Software Engineering Institute der Carnegie Mellon University, September 2007 http://www.sei.cmu.edu/publications/documents/07.reports/07tr015.html
  5. SOA in der Praxis, Nicolai Josuttis, 2008
  6. Haibin Zhu: Challenges to Reusable Services, scc, 2005, IEEE International Conference on Services Computing (SCC'05) Vol-2, 2005, S. 243–244.
  7. Siehe schon im Jahr 2006 kritisch: David Chappell: SOA and the Reality of Reuse. August 2006. Online: davidchappell.com , abgerufen am 16. Mai 2015.
  8. Wolfgang Herrmann: Die Rezession hat SOA das Genick gebrochen. In: Computerwoche. 16. Oktober 2008. online: computerwoche.de .









Kategorien: IT-Architektur | Middleware | Webservice




Stand der Informationen: 27.04.2021 02:01:05 CEST

Quelle: Wikipedia (Autoren [Versionsgeschichte])    Lizenz: CC-BY-SA-3.0

Veränderungen: Alle Bilder und die meisten Designelemente, die mit ihnen in Verbindung stehen, wurden entfernt. Icons wurden teilweise durch FontAwesome-Icons ersetzt. Einige Vorlagen wurden entfernt (wie „Lesenswerter Artikel“, „Exzellenter Artikel“) oder umgeschrieben. CSS-Klassen wurden zum Großteil entfernt oder vereinheitlicht.
Wikipedia spezifische Links, die nicht zu Artikeln oder Kategorien führen (wie „Redlink“, „Bearbeiten-Links“, „Portal-Links“) wurden entfernt. Alle externen Links haben ein zusätzliches FontAwesome Icon erhalten. Neben weiteren kleinen Designanpassungen wurden Media-Container, Karten, Navigationsboxen, gesprochene Versionen & Geo-Mikroformate entfernt.

Wichtiger Hinweis Da die gegebenen Inhalte zum angegebenen Zeitpunkt maschinell von Wikipedia übernommen wurden, war und ist eine manuelle Überprüfung nicht möglich. Somit garantiert LinkFang.org nicht die Richtigkeit und Aktualität der übernommenen Inhalte. Sollten die Informationen mittlerweile fehlerhaft sein oder Fehler in der Darstellung vorliegen, bitten wir Sie darum uns per zu kontaktieren: E-Mail.
Beachten Sie auch : Impressum & Datenschutzerklärung.