Acht Grundprinzipien von SOA: Wechselbeziehungen und Service-Layer

Dies ist der letzte Beitrag unserer sechsteiligen SOA-Artikelserie, in der es um die gemeinsamen Prinzipien serviceorientierter Architekturen geht.

In den früheren Artikeln haben wir allgemeine Grundsätze der Serviceorientierung vorgestellt. In diesem letzten Beitrag beschäftigen wir uns abschließend mit Anwendungsaspekten. Wir diskutieren, wie sich die vorgestellten Prinzipien aufeinander beziehen und sich gegenseitig beeinflussen können. Diese Wechselbeziehungen sind sehr spezifisch und schaffen eine Dynamik, die einzigartig für das Paradigma der serviceorientierten Architektur (SOA) ist. Wir schließen die Serie mit einem kurzen Blick darauf, wie bestimmte Prinzipien jenseits des Service-Levels durch den Einsatz von Abstraktionsschichten angewendet werden können.

Wie die Prinzipien zusammenhängen

Um ein tieferes Verständnis von Serviceorientierung zu erreichen, ist es wichtig, Ursache und Wirkung zu kennen, wenn man jedes der gemeinsamen Prinzipien anwendet. Wenn wir die Wechselbeziehungen zwischen den Prinzipien erkunden, erkennen wir nicht nur, wie jeder Service andere Services unterstützt oder von anderen unterstützt wird. Wir verstehen auch, was Serviceorientierung von anderen Designparadigmen unterscheidet.

Wiederverwendbarkeit des Services
Abbildung 1: Wiederverwendbarkeit des Services.

Nehmen wir das grundlegende Prinzip der Wiederverwendbarkeit (Reusability) von Services als Beispiel. In Abbildung 1 finden Sie die SOA-Prinzipien, die durch ovale Symbole dargestellt werden. Die Beziehungen zwischen den Prinzipien sind durch Pfeile repräsentiert. Die Wiederverwendbarkeit der Services ist in der Mitte angeordnet, da uns dessen Beziehungen interessieren. Die Pfeile, die auf dieses Prinzip zeigen, stellen den Einfluss von anderen Prinzipien dar. Der eine Pfeil unten, der von dem Symbol weg zeigt, soll andeuten, wie die Implementierung einer wiederverwendbaren Automatisierungslogik die Realisierung eines anderen Prinzips beeinflussen kann.

In dieser Darstellung können Sie erkennen, dass sehr viele andere Prinzipien das Ausmaß an Wiederverwendbarkeit gestalten und unterstützen. Die Realisierung von Wiederverwendbarkeit nicht nur im Design, sondern auch in der realen Implementierung ist ein Kernziel der Serviceorientierung und der Schlüssel, um die vielen bedeutenden Vorteile von SOA umzusetzen. Einige der anderen Prinzipien entstanden daher zur Unterstützung dieses Ziels.

Werfen wir einen genaueren Blick auf jede dieser Beziehungen:

  • Die Serviceautonomie schafft eine Ausführungsumgebung, die die Wiederverwendung eines Services erleichtert, da dieser größere Unabhängigkeit und Selbstverwaltung erreicht. Je weniger Abhängigkeiten ein Service aufweist, desto größer sind seine Wiederverwendungsmöglichkeiten.
  • Der Service Zustandslosigkeit unterstützt die Wiederverwendung, da er die Verfügbarkeit eines Services maximiert und in der Regel ein allgemeines Servicedesign fördert, welche das Zustands-Management und die tätigkeitsspezifische Verarbeitung außerhalb der Servicegrenzen verschiebt.
  • Die Serviceabstraktion fördert die Wiederverwendung, da sie das Black-Box-Konzept umsetzt. Proprietäre Verarbeitungsdetails werden versteckt und potentiellen Konsumenten werden Access Points nur über eine generische Schnittstelle bekannt gegeben.
  • Der Service Auffindbarkeit (Discoverability) fördert die Wiederverwendung da es denjenigen, die Services erstellen, beim Suchen, Entdecken und Bewerten von Services wiederverwendbare Funktionalität bietet.
  • Der Service lose Kopplung sorgt für eine inhärente Unabhängigkeit, die einen Service von unmittelbaren Verbindungen zu anderen befreit. Dies macht es sehr viel einfacher, die Wiederverwendung zu realisieren.
  • Der Service Kompositionsfähigkeit ist in erster Linie wegen der Wiederverwendung möglich. Damit sind neue Automatisierungsanforderungen durch die Zusammensetzung bestehender Dienstleistungen umsetzbar, wenn diese zusammengesetzten Services zur Wiederverwendung gebaut wurden. Es ist technisch möglich, einen Service zu bauen, dessen einziger Zweck es ist, aus anderen Services zusammengesetzt zu sein, aber die Wiederverwendung wird generell betont.

Das Studium der wechselseitigen Beziehungen kann recht komplex sein. Denn es geht nicht nur darum, ob ein Prinzip angewendet wird, sondern es geht auch um das Ausmaß, mit dem es angewendet wird.

Wie wir in den vorangegangenen Artikeln dieser Serie gesehen haben, kann jedes Prinzip bis zu einem gewissen Grad implementiert werden. Dies kann es schwierig machen, das tatsächliche Level der Realisierung eines Prinzips zu messen und den Umfang, in dem es andere beeinflusst. Aber ich kann Ihnen aus erster Erfahrung sagen, dass das wiederholte Ausführen von serviceorientierter Analyse und von Designprozessen eine starke Vertrautheit mit Serviceorientierung aufbaut. Und schließlich fördert es auch ein gesundes Urteilsvermögen bezüglich der wechselseitigen Beziehungen der Prinzipien.

Abstraktion, lose Kopplung und Serviceschichten

Beim Studium dieser Beziehungen müssen wir Überlegungen berücksichtigen, die über die Anwendung einzelner Prinzipien für einen bestimmten Service hinaus gehen. Um Serviceorientierung erfolgreich im gesamten Unternehmen anzuwenden, müssen bestimmte Prinzipien noch weiter erkundet werden - über die eigentliche Servicegrenzen hinaus.

Servicemodelle wurden im zweiten Teil dieser SOA-Serie eingeführt. Auf den Punkt gebracht: Servicemodelle schaffen für gängige Arten von Services Vorlagen (Templates) mit vordefinierten Designmerkmalen. Dabei haben wir uns auf Servicemodelle in einem Business-Kontext konzentriert. Diese enthalten:

•         Entity Centric Business Service;

•         Task Centric Business Service;

•         Prozessservice.

Ein weiteres Modell, das wir kurz vorstellen, ist ein nicht geschäftsorientiertes Modell. Wir bezeichnen dies als Anwendungs- oder Infrastrukturservice. Dieses Modell repräsentiert im Allgemeinen die Verarbeitungslogik für Dienstprogramme. Typische Beispiele sind Benachrichtigung, Ereignisprotokollierung, Ausnahmebehandlung und die Konvertierung von Datenformaten.

Serviceebenen.
Abbildung 2: Drei Serviceebenen.

Abbildung 2 zeigt ein Szenario mit drei Serviceebenen, von denen die unteren sich auf das zuvor beschriebenen Servicemodell beziehen.

Die Nutzung von Servicemodellen ermöglicht es uns, das Konzept der funktionalen Abstraktion in einem großem Maßstab zu realisieren. Eine Gruppe von Services, die auf dem gleichen Modell basiert, teilt gemeinsame Eigenschaften und kann daher gemeinsam eine Domäne innerhalb eines Unternehmens abstrahieren. Dies schafft im Endeffekt eine Serviceabstraktionsschicht.

Diese Schichten (Layer) müssen nicht zwangsläufig auf die Servicemodelle beschränkt sein, die wir zuvor aufgelistet haben. Eine Organisation kann ihre eigenen Servicemodelle definieren, die die logischen Unternehmensdomänen jeweils spezifisch aufteilen können. Zum Beispiel kann ein Business-Servicemodell speziell für bestimmte Abteilungen eines Unternehmen (wie Personalabteilung oder Marketing) erstellt werden. Services auf Grundlage dieses Modells würden funktionale Grenzen haben und auf den jeweiligen Teil der Organisation beschränkt sein. Sie würden gemeinsam eine Domain einkapseln, die dieser Abteilung entspricht. All dies führt den Grundsatz der Serviceabstraktion auf eine neue Ebene. Da wir die Abstraktion jenseits einer einzelnen Servicegrenze auf ganze Mengen von Services anwenden, bezeichnen wir dies als Domain-Level-Abstraktion.

Alle anderen Artikel der SOA-Artikelserie

Acht Grundprinzipien von SOA: Serviceautonomie und Zustandslosigkeit.

Acht Grundprinzipien von SOA: Service Discoverability und Servicekomposition.

Acht Grundprinzipien von SOA: Serviceabstraktion und Wiederverwendbarkeit.

Acht Grundprinzipien von SOA: Serviceverträge und lose Kopplung.

Acht Grundprinzipien von serviceorientierter Architektur (SOA).

Die Verwendung von Domain-Level-Abstraktion ermöglicht es uns, die lose Kopplung über Servicegrenzen hinweg anzuwenden. Service-Layer, die Domains kapseln, stellen die logische Entsprechung von Funktionalitäten innerhalb des Unternehmens dar. Sie müssen mit anderen Services interagieren, um gemeinsame Geschäftsprozesse und –aufgaben zu automatisieren.

Wie wir wissen, profitiert die lose Kopplung einer SOA, indem Services relativ unabhängig voneinander entwickelt werden können. Einmal auf Unternehmensebene angewendet, etablieren Serviceabstraktionsschichten eine lose Kopplung zwischen ganzen Segmenten einer Organisation. Dadurch können Domänen mit mehr Unabhängigkeit entwickelt werden, während sie gleichzeitig eine domänenübergreifende Interaktion ermöglichen.

Fazit

Bei den Vieldeutigkeiten, die den Begriff SOA in der aktuellen Marktsituation umgeben, ist es wichtiger denn je, ein Verständnis dafür zu erlangen, was es wirklich bedeutet, dass etwas serviceorientiert ist. Ein fundiertes Wissen über das Designparadigma der Serviceorientierung und seiner Prinzipien wird Ihnen dieses Verständnis liefern. Es wird ihnen klarer werden, was serviceorientierte Produkte und Plattformen sind und wie Sie serviceorientiertes Computing zur Unterstützung Ihrer strategischen Ziele einsetzen können.

Für mehr Details zu den Serviceprinzipien, möchte ich Ihnen abschließend noch die Website www.serviceorientation.com empfehlen.

Ü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. Er hat mit Studien zur Serviceorientierung und der Entwicklung einer Mainstream SOA-Methodik wesentliche Beiträge für die SOA-Industrie geleistet. Zudem ist der SOA-Experte an einer Reihe von Fachausschüssen und Forschungsprojekten beteiligt und übernimmt Vorträge, Schulungen und Beratungsaufträge. Um mehr zu erfahren, besuchen Sie www.thomaserl.com.

 

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

Erfahren Sie mehr über Softwareentwicklung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close