Der lange Weg zu SOA, Teil 3 - JAXenter

Der lange Weg zu SOA, Teil 3

… Interne Properties des Orchestrierungsprojekts
werden von den Datenobjekten
und -elementen der verwendeten
Web Services definiert. Jedes Mal, wenn
ein SendActivity-Objekt benutzt wird, um
einen Web Service aufzurufen, muss eine
neue interne Property erstellt werden, um
die Input/Ouput Datenobjekte/-elemente
des verwendeten Web Services zu halten.
Das führt dazu, dass Properties, die dieselben
Daten mit unterschiedlichen Namen
enthalten, auch mehrmals erstellt werden.
Deshalb wird ein Codeobjekt benötigt,
um die Datenobjekte/Elemente von einer
Property in eine andere zu übertragen.
Das führt zu einer weiteren Stufe der engen
Kopplung zwischen dem Composite Web
Service und den genutzten Web Services.
Nicht nur, dass der Composite Web Service
die Adresse der genutzten Web Services
kennen muss, er muss auch Code enthalten,
der sich auf die exakten Namen der
Datenobjekte und Elemente der verwendeten
Web Services bezieht. Jedes Mal, wenn
ein Web Service geändert wird, müssen die
internen Properties neu erstellt und der
Tranformationscode neu kodiert werden.

Die Prozessflussbedingungen werden
mithilfe der Properties definiert, welche
von den Datenobjekten/Elementen der
genutzten Web Services generiert werden.
Dies führt zu einer weiteren engen Kopplung
zwischen den Flussbedingungen der
Orchestrierung und den genutzten Services.
Wenn sich einer der Web Services
ändert, müssen neue interne Properties erstellt
werden und alle Prozessflussbedingungen,
die die alten Variablen benutzen,
müssen neu kodiert werden.

Composite Web Services werden im
Visual Studio erstellt, ohne dabei ein zentralisiertes
Repository zu verwenden. Jedes
Mal, wenn ein neuer Composite Web
Service erstellt wird, muss ein neues Projekt
in Visual Studio angelegt werden, und
alle Elemente müssen von Grund auf neu
erstellt werden. Ohne ein zentralisiertes
Repository kann keines dieser Elemente
einfach in anderen Orchestrierungen wiederverwendet
werden. Wenn eines dieser
Elemente geändert wird, müssen in allen
Composite Web Service-Projekte dieselben
Änderungen an den Composite Web Services
gemacht werden. Interne Properties im
Orchestrierungsprojekt werden von den
Datenobjekten/-elementen der verwendeten
Web Services definiert. Deshalb müssen
Codeobjekte und langatmiger Code
(ca. 200 Zeilen in diesem Beispiel) erstellt
werden, um die Werte der Datenobjekte/
Elemente von einer Property zu einer anderen
zu übertragen. Die Transformation der
Daten geschieht auf einem niedrigen Datenobjekt/
Elementlevel der Granularität,
anstatt auf einem XML-Dokumentlevel.

Zusammenfassung und Ausblick

Wie geschildert, sind die Anforderungen
einer losen Kopplung, die Wiederverwendbarkeit
von und eine optimale Granularität
der Services sehr schwierig zu erhalten
und selbst der Einsatz von WF und WCF
erfüllt die Anforderungen einer SOA-Infrastruktur
für die Entwicklung serviceorientierter
Composite Applications nicht.
Ein Grund liegt in der direkten Kopplung
von Web Services und der Orchestration
Engine. Um eine Composite Application
zu entwickeln, die den Anforderungen der
Serviceorientierung genügt, bedarf es einer
höheren Abstraktionsebene. Auf dieser
wird zunächst ein logisches Prozess- und
Kommunikationsmodell der Composite
Application erstellt. Dieses Modell ist die
Composite Application auf logischer oder
fachlicher Ebene. Anstelle physischer Web
Services werden Capabilities definiert. Dabei
sind Capabilities logische Abstraktionen
von Services, die beschreiben, was ein
Service innerhalb eines Prozesses tun soll
und nicht wie er implementiert wird. Sie
besitzen Input- und Output-Objekte und
Key Performance Indicators (KPIs). Das
Modell orchestriert die Capabilities. Damit
eine lose gekoppelte Kommunikation
ermöglicht wird, abbonieren Capabilities
auf Output-Objekte (Schemas) anderer
Capabilities, die ihre Output Objekte publizieren.
Dazu bedarf es einer Infrastruktur
und eine Fülle von Tools. Dies wird in den
nächsten Artikeln beschrieben.

Dr. Peter Eichhorst ist Gründer und Geschäftsführer
der Firma Socon Unternehmensberatung
mit Sitz in Dresden, die sich auf Themen rund um
Service Oriented Computing spezialisiert hat.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.