Acht Grundprinzipien von SOA: Serviceabstraktion und Wiederverwendbarkeit

In dieser dritten Folge unserer sechsteiligen SOA-Artikelserie widmen wir uns den gemeinsamen Prinzipien der serviceorientierten Architektur.

Ein wichtiger Aspekt der Serviceorientierung hat direkt mit unserer bisherigen Diskussion von Serviceverträgen und der losen Kopplung zu tun: Dies ist das Thema Abstraktion. Mit Hilfe der Abstraktion können wir steuern, welche Teile der darunterliegenden Servicelogik für die Außenwelt sichtbar sind. Da diese Teile möglichst generisch ausgelegt werden sollen, so dass mehrere potenzielle Serviceanforderer sie nutzen können, stellen wir den Dienst als wiederverwendbares IT-Asset bereit. In diesem Artikel werden wir verschiedene Abstraktionsebenen vorstellen und anschließend diskutieren, wie die Wiederverwendbarkeit die strategischen Gesamtziele unterstützt, mit der eine serviceorientierte Architektur (SOA) untrennbar verbunden ist.

Abstrahieren von Funktionalität und Technologie

Die sogenannte Service Interface Level Abstraktion – das Verstecken der darunter liegenden Details vor potentiellen Servicenutzern – ist die Grundlage, auf der wir Services als Black Boxes einrichten. Abstraktion wird durch die disziplinierte Nutzung von Serviceverträgen erreicht. Da wir das, was von einem Service öffentlich gemacht wird, auf das beschränken, was im Servicevertrag dokumentiert ist, kann ein hoher Grad der Trennung erreicht werden zwischen dem, was privat (verdeckt) und öffentlich (konsumierbar) ist. Dies ist wünschenswert, da es die lose gekoppelten Beziehung, die wir in Teil 2 die Artikelserie beschrieben haben, unterstützt.

Es gibt keine Begrenzung für den Umfang an Logik, den ein Service darstellen kann. So kann ein Service beispielsweise nur für die Ausführung einfacher Aufgaben ausgelegt sein, er kann aber auch als ein Gateway für eine ganze Automatisierungslösung fungieren. Es gibt auch keine Beschränkung hinsichtlich der Quelle der Automatisierungslogik, auf die sich ein Service stützen kann.

Zum Beispiel kann ein einzelner Service seine Logik aus mehreren unterschiedlichen Grundsystemen beziehen. In Umgebungen mit zahlreichen Legacy-Lösungen wird ein Service im Allgemeinen Funktionen bereitstellen, die auf einer Vielzahl von unterschiedlichen Systemen beruhen.

Die Service Interface Level Abstraktion ist eine der inhärenten Qualitäten, die von verteilten Plattformen – wie komponenten- und webservicebasierten Architekturen – zur Verfügung gestellt wird. Besonders synergetisch ist der Einsatz von Webservices, da sie das Niveau der erreichbaren Abstraktion über die reine Funktionalität hinaus anheben. Webservices abstrahieren von den proprietären Implementierungsdetails der zugrundeliegenden Automatisierungslogik. Das befreit potentielle Konsumenten des Services, sich mit bestimmten Anbietertechnologien koppeln zu müssen.

Auch wenn wir uns auf die Abstraktion als ein Charakteristikum für einen Dienst beziehen, sind es tatsächlich die individuellen Operationen, die kollektiv von der zugrundeliegenden Logik abstrahieren. Die Services agieren einfach als Container für diese Operationen. Die Abstraktionsniveau irgendeines beliebigen Service wird daher zum großen Teil von den kollektiven Abstraktionsebenen jeder ihrer Serviceoperationen bestimmt.

Damit wird die Gestaltung des Servicevertrags wichtig. Je mehr Details im Servicevertrags expliziert werden, desto weniger Details müssen wir am Ende abstrahieren. Je allgemeiner wir den Servicevertrag gestalten, um so weniger prozess- oder verbraucherspezifisch wird der Service. Dies bestimmt wiederum das Potenzial für die Wiederverwendbarkeit des Service.

Agilität durch Wiederverwendbarkeit fördern

Serviceorientierung fördert die Wiederverwendbarkeit in allen Services, unabhängig davon, ob aktuelle Anforderungen für die Wiederverwendbarkeit existieren. Dieses Grundprinzip zwingt uns dazu, mehr Aufmerksamkeit auf den Service zu richten.

Das primäre strategische Ziel, das mit der Wiederverwendbarkeit verbunden ist, ist jeden Service als IT-Asset mit wiederholbarem Wert zu positionieren. Während sich die Menge solcher Assets ansammelt, erhöhen sich die Chancen, neue Anforderungen an die Geschäftsautomatisierung durch den Bau immer weniger Teile zu erfüllen – und mehr von dem verwenden zu können, was bereits vorhanden ist.

Damit kann man erwarten, dass man die Zeit für den Aufbau der Automatisierungslogik reduzieren kann, wodurch sich die Gesamtreaktionsfähigkeit eines Unternehmens auf wechselnde Anforderungen verbessert. Durch die Reduzierung der damit verbundenen Anstrengungen wird die Erfüllung der Automatisierungsanforderungen auch kostengünstiger, was schlankere IT-Entwicklungsumgebungen zur Folge hat. Das mag nach einer großen Aufgabe klingen, aber viele Unternehmen investieren intensiv in die Generierung eines hochgradig wiederverwendbaren Serviceinventars, um diese Vorteile für sich zu nutzen.

Dieses Prinzip ermöglicht alle Formen der Wiederverwendbarkeit, einschließlich anwendungsübergreifender Interoperabilität, Komposition und der Erstellung von übergreifenden Services. Wie wir bereits festgestellt haben, ist ein Service nichts weiter als eine Sammlung von aufeinander abgestimmten Operationen. Es ist daher die Logik, die von einzelnen Operationen eingekapselt ist, die als wiederverwendbar betrachtet werden muss und Wiederverwendbarkeit garantiert.

Die Betonung der weitreichenden Wiederverwendbarkeit unterstreicht auch die Eignung von Webservices als eine mögliche Implementierungsoption. Indem jeder Service über ein Industriestandard-Kommunikations-Framework bereitgestellt wird, erweitert sich das Potenzial für die Wiederverwendbarkeit drastisch, da die von einem Service gekapselte Logik jetzt für Serviceanforder zugänglich wird, die an ihrer Basis völlig unterschiedliche Technologien einsetzen.

Alles hängt am Servicevertrag

Beide Prinzipien bringen uns wieder zurück zur Nutzung des Servicevertrags. Der Inhalt dieses Vertrages legt fest, was abstrahiert und was nicht abstrahiert wird. Durch die Gestaltung des Vertragsinhalts können wir bestimmen, wie allgemein und wiederverwendbar die nicht abstrahierten Teile tatsächlich sind. Damit ergibt sich die Notwendigkeit, das Design eines Services als eine echte Investition zu betrachten. Der Aufbau einer serviceorientierten Lösungslogik ist fast immer teuer und zeitaufwendig, da Überlegungen berücksichtigt werden müssen, die über aktuelle strategische Anforderungen hinaus gehen. Eine Bewertung dessen, was mit Serviceorientierung erreicht werden soll, ist deshalb nützlich bei der Rechtfertigung dieser Investition.

Wie geht es weiter?

Wir sind auf halbem Weg und haben bereits etwas Licht geworfen auf die einzigartigen Eigenschaften, Anforderungen und potenziellen Vorteile des Paradigmas der serviceorientierten Architektur. In Teil 4 dieser Artikelserie diskutieren wir die Notwendigkeit des Erkennens von Serivces, unabhängig davon, ob ein Service Registry in einer Umgebung tatsächlich vorhanden ist oder nicht. Außerdem werfen wir einen genaueren Blick auf das sehr wichtige und oft missverstandene Merkmal der Komponierbarkeit von Services.

Dieser Artikel enthält Auszüge aus „Service-Oriented Architecture: Concepts, Technology, and Design“ von Thomas Erl (ISBN 0131858580, Prentice Hall/Pearson PTR).

Über den Autor: 
Thomas Erl ist SOA-Autor und Herausgeber der Reihe „Prentice Hall Service-Oriented Computing Series von Thomas Erl“ (www.soabooks.com). Seine SOA-Bücher gelten weltweit als Top-Seller. Erl ist Gründer von SOA Systems, einer Firma, die auf die strategische SOA-Beratung, -Planung, -Ausbildung sowie auf SOA-Dienstleistungen spezialisiert ist (www.soatraining.com). Er hat mit Studien zur Serviceorientierung und der Entwicklung einer Mainstream SOA-Methodik wesentliche Beiträge für die SOA-Industrie geleistet. Erl ist zudem an einer Reihe von Fachausschüssen und Forschungsprojekten beteiligt und übernimmt häufig Vorträge, Schulungen und Beratungsaufträge.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Juli 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über SOA

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close