Das Kefk Network Wiki befindet sich im Testbetrieb.

Aus Kefk.

Der Begriff Serviceorientierte Architektur (SOA) oder englisch Service Oriented Architecture, auch dienstorientierte Architektur, ist ein Managementkonzept und setzt erst in zweiter Linie ein Systemarchitekturkonzept voraus:

• Das Managementkonzept strebt eine an den gewünschten Geschäftsprozessen ausgerichtete Infrastruktur an, die schnell auf veränderte Anforderungen im Geschäftsumfeld reagieren kann.
• Das Systemarchitekturkonzept sieht die Bereitstellung fachlicher Dienste und Funktionalitäten in Form von Services vor.

Ein Service ist in diesem Kontext als eine Funktionalität definiert, die über eine standardisierte Schnittstelle in Anspruch genommen werden kann. Er ist damit eine spezielle Ausprägung des bekannten Konzepts der Softwarekomponente.

Kurzübersicht

Anwendungssysteme zur durchgängigen Unterstützung von Geschäftsprozessen lassen sich durch Aneinanderreihung von Serviceaufrufen („Komposition von Services“) realisieren. Die Programmlogik ist nicht in einem einzigen Programm zu finden, sondern verteilt über mehrere unabhängige Dienste.

Die SOA sieht eine Menge voneinander unabhängiger, lose gekoppelter Dienste vor. Ein Dienst wird von einem service provider angeboten. Ein service consumer stellt eine Anfrage (service request) an einen Dienst und bekommt daraufhin eine Antwort (service response) vom Anbieter.

Oft werden für SOAs Web Services auf Basis der wenigen bestehenden Standards wie SOAP, WSDL und UDDI eingesetzt, doch kann eine SOA prinzipiell auf jeder dienstbasierten Technologie wie zum Beispiel CORBA, DCOM, Windows Communication Foundation (WCF) oder Enterprise Java Beans (EJB) aufgebaut werden. Da Services in unterschiedlichen Programmiersprachen und auf unterschiedlichen Systemplattformen realisiert werden können, wird eine SOA häufig zur Anwendungsintegration genutzt.

Ein weiteres wesentliches Ziel einer SOA ist die Kapselung von persistenten Daten durch Dienste, die exklusives Lese- und Schreibrecht auf „ihre“ Daten besitzen. Die hierdurch erzielte Modularität führt zu geringen Redundanzen und einer höheren Flexibilität der IT-Systeme, was häufig zu niedrigeren Betriebskosten führt.

Diesen Vorteilen steht allerdings oft ein erheblicher initialer Entwicklungsaufwand gegenüber. In der Regel muss die Geschäftslogik bereits existierender Unternehmensanwendungen durch Entwicklung geeigneter Adapter zu Services umgebaut werden.

Einführung

Die integrierte Betrachtung von Geschäftsprozessanpassungen und daran anschließende alsbaldige IT-Unterstützungsanpassung ist der Grund für die hohe Aufmerksamkeit, die diesem Thema auf Geschäftsführungsebene entgegengebracht wird.

Definition

Im Vergleich zu früheren Ansätzen wie EAI, ist der SOA-Ansatz verbunden mit einem Umdenken. War EAI noch technisch in einem Hub-und-Spoke-System aufgebaut, so ist SOA ein fachlich getriebener, dezentraler, service-getriebener Ansatz.

Eine Anwendung des SOA-Konzeptes hat zunächst einmal eine Identifikation von Services (genauer: service provider und service consumer) im Geschäftsprozess zur Folge, verbunden mit einer fachlichen Klärung des eigenen Geschäftsumfelds (Identifikation von Services). Services sind für Funktionen und Daten eines Dienstes zuständig und kapseln den Zugriff darauf.

Das Domänenmodell – also ein Modell mit den eigentlichen Objekten des Anwendungsbereiches und dessen Beziehungen zueinander – wird häufig unterschätzt oder komplett außen vor gelassen, obwohl doch die Integration einer heterogenen Umgebung mit deren zahlreichen Interdependenzen und Stakeholdern durch eine plattformunabhängige Lösung ein wesentliches Merkmal einer SOA ist.

Die eigentliche Technik, die zur Erfüllung eingesetzt wird, sollte standardisiert sein und ist lediglich Mittel zum Zweck. Ein Aspekt bei der Entwicklung serviceorientierter Architekturen ist die Sicherstellung der Authentizität der über offene Schnittstellen angebotenen Services. Services können über Service-Repositories lokalisiert werden. Ein Enterprise Service Bus (ESB) ist der zentrale Kommunikationsweg, der sämtlichen Datenaustausch zwischen Service-Konsument und Service-Produzent übernimmt.

SOA ist ein Systemarchitekturkonzept, das unternehmensweit eingesetzt werden kann und in dem Funktionen in Form von wieder verwendbaren, technisch voneinander unabhängigen und fachlich lose gekoppelten Services implementiert werden. Services können unabhängig von zugrunde liegenden Implementierungen über Schnittstellen aufgerufen werden, deren Spezifikationen öffentlich und damit vertrauenswürdig sein können. Serviceinteraktion findet über eine dafür vorgesehene Kommunikationsinfrastruktur statt. Mit einer serviceorientierten Architektur werden in der Regel die Gestaltungsziele der Geschäftsprozessorientierung, der Wandlungsfähigkeit (Flexibilität), der Wiederverwendbarkeit und der Unterstützung verteilter Softwaresysteme verbunden.

Ziele

Primärziel ist, die historisch gewachsene, heterogene Systemlandschaft effizient an Änderungen im Geschäftsprozess anpassen zu können. Im Einzelnen soll dadurch Software erstellt werden, die

• einfach an neue Bedürfnisse angepasst werden kann (Flexibilität)
• wiederverwendbar ist
• verteilt installiert werden kann
• an Geschäftsprozesse angepasst ist.

Sekundärziele sind:

• Kostenvorteile durch schnelle Optimierung
• schnelle Reaktion auf Herausforderungen möglich
• mittelfristige Einsparungen
• schrittweise Restrukturierung komplexer Anwendungssysteme.

Umfeld

Der Begriff serviceorientierte Architektur ist in das folgende Umfeld einzuordnen:

• Business Service Management (BSM): Die Verbindung zwischen Prozessmanagement und ITSM.
• IT-Service-Management (ITSM): Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen (GP) durch die IT-Organisation zu erreichen. Der hier bekannte de-facto Standard ist die IT Infrastructure Library (ITIL).
• Prozessmanagement (auch Geschäftsprozessmanagement, GPM): Die Definition der Prozesse des Business, die durch die IT unterstützt werden.

Elementarer Grundgedanke

Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Serviceorientierte_Architektur, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.

• Identifikation von Services ('service consumer' und 'service provider')
• Trennung der Zuständigkeiten nach fachlichen Gesichtspunkten
• Datenkapselung (ein Service ist ausschließlich zuständig für „seine Daten“, jeder 'service consumer' muss sein Interesse an den Daten bzw. an dem Service beim 'service provider' anmelden).

Vorgehen

Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Serviceorientierte_Architektur, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.

Das folgende Vorgehen hat sich als günstig erwiesen:^[1]

1. Think BIG, Start small (denke groß, fange klein an)
2. Fachabteilung einbinden
3. Bestandsaufnahme
4. Erste Services einbinden
5. Registry installieren
6. Governance regeln
7. Sicherheit planen
8. Messaging Infrastructure einrichten
9. Service Management einrichten
10. Services orchestrieren

Anwendungsbeispiel

Online-Brokerage – der Abschluss von Wertpapiergeschäften über das Internet – kann in einer SOA auf folgenden Diensten aufsetzen:

• einem Wertpapierdienst, der handelbare Wertpapiere (Aktien, Fonds, …) nennt
• einem Marktdatendienst, der zu einem Wertpapier aktuelle Börsenkurse liefert
• einem Depotdienst, der Zugriff auf das Wertpapierdepot des Anwenders erlaubt
• einem Orderdienst, der Kauf-/Verkaufsaufträge des Anwenders an eine Börse übermittelt
• einem Archivdienst, der alle Daten der Transaktion revisionssicher archiviert

Diese Dienste werden aus einer Webanwendung heraus aufgerufen.

Technische Realisierung zur Laufzeit

Die Interaktion zwischen Serviceanbieter und Servicekonsument läuft nach dem (publish/register), find, bind, execute-Paradigma ab (dt. (veröffentlichen/registrieren), finden, binden, ausführen).^[2]

publish / register

Der Serviceanbieter veröffentlicht bzw. registriert seinen Dienst bei einem Verzeichnis

find

Die Softwarekomponente, die einen Service benutzen möchte, sucht ihn bei einem Verzeichnis. Wird ein passender Service gefunden, kann zum nächsten Schritt übergegangen werden.

bind

Die benutzende Komponente erhält vom Verzeichnis eine Referenz (Adresse) unter der sie auf den Service zugreifen kann. Der Funktionsaufruf wird an diese Adresse gebunden.

execute

Der Serviceaufruf wird durchgeführt. Eingabeparameter werden an den Service übermittelt und Ausgabeparameter als Antwort auf den Aufruf zurückgeliefert.

Literatur

• Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah: Service-Oriented Architecture Compass. Business Value, Planning and Enterprise Roadmap. Pearson, Upper Saddle River 2006, ISBN 0-13-187002-5
• Kai J. Oey, Holger Wagner, Simon Rehbach, Andrea Bachmann: Mehr als alter Wein in neuen Schläuchen. Eine einführende Darstellung des Konzepts der serviceorientierten Architekturen. In: Stephan Aier, Marten Schönherr (Hrsg.): Unternehmensarchitekturen und Systemintegration. 2. Auflage, Gito, Berlin 2006 (Enterprise Architecture, Band 3), S. 197ff., ISBN 3-936771-75-8
• Stephan Aier, Marten Schönherr (Hrsg.): Enterprise Application Integration. Serviceorientierung und nachhaltige Architekturen. 2. Auflage, Gito, Berlin 2006 (Enterprise Architecture, Band 2), ISBN 3-936771-74-x
• Douglas K. Barry: Web Services and Service-Oriented Architectures. The savvy manager's guide. Your road map to emerging IT. Morgan Kaufmann, Amsterdam u.a. 2004, ISBN 1-55860-906-7
• Thomas Erl: Service-Oriented Architecture. A field guide to integrating XML and Web services. Prentice Hall PTR, Upper Saddle River 2004, ISBN 0-13-142898-5
• Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA. Prentice Hall PTR, Upper Saddle River 2005, ISBN 0-13-146575-9
• Wolfgang Dostal, Mario Jeckle, Ingo Melzer, Barbara Zengler: Service-orientierte Architekturen mit Web Services. Spektrum Verlag, September 2005, ISBN 3-8274-1457-1 (Website zum Buch)
• OSGi Service Platform, Release 3, IOS Press (2003), englisch, ISBN 1-58603-311-5
• IBM Systems Journal edition on SOA: Service-Oriented Architecture 12 wissenschaftliche Papers zum Thema SOA

Siehe auch

• Enterprise Application Integration
• Enterprise Architecture Management
• Enterprise Services Architecture
• Enterprise Service Bus
• Workflow Management
• Enterprise Content Management
• Modul (Software)
• Verteiltes System
• Business Activity Monitoring
• Business Process Management
• Business Process Monitoring
• Business Rule Management System
• Complex Event Processing
• BPEL

Weblinks

• What Is Service-Oriented Architecture? – Ausführliche Umschreibung einer Serviceorientierten Architektur (englisch)

Quellen

1. ↑ Wolfgang Herrmann: In zehn Schritten zur SOA.. In: Computerwoche. 07.12.2005. [21.03.2006]
2. ↑ Haibin Zhu, "Challenges to Reusable Services," scc, pp. 243-244, 2005 IEEE International Conference on Services Computing (SCC'05) Vol-2, 2005.

Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Serviceorientierte_Architektur, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.