Der lange Weg zu SOA, Teil 3 - JAXenter

Der lange Weg zu SOA, Teil 3

… Eine Methode für die Entwicklung von
Composite Applications besteht im Implementieren
der Geschäftsprozessaktivitäten
durch Web Services, wobei sich bereits
vorhandene monolithische Anwendungen
nach außen oft durch einen Web Service
Wrapper als Web Service darstellen. Diese
Web Services rufen sich entsprechend den
Geschäftsregeln direkt auf. Dabei müssen in
den einzelnen Web Services sowohl die Geschäftslogik,
die partielle Ablauflogik (Web
Service Routing-Logik) des Geschäftsprozesses
als auch die Datentransformationen
kodiert werden (Abbildung 3). Leider
entwickeln Organisationen Anwendungen
oft in ähnlicher Weise und in dem Glauben,
dass sie damit serviceorientiert entwickeln,
da Web Services im Spiel sind. Web Services
sind wichtige Bausteine für die Serviceorientierung
auf Grund der Bereitstellung
von standardisierten Schnittstellen und
anderen Faktoren, ihre Verwendung allein
macht jedoch aus einer Anwendung noch
lange keine serviceorientierte Anwendung.

Abb. 3: Implementierung einer Composite Application durch direkte Web Service-Aufrufe

Diese Art der Entwicklung bringt tiefgreifende
Probleme mit sich. Zuerst ist es
wichtig zu erkennen, dass die Web Services
Submit Delta und Submit United externe
Web Services sind, die als Service Provider
nur die Informationen entsprechend ihrer
WSDL an den Service Consumer liefern
und keine Beziehung zum Ablauf der Composite
Application haben. Deshalb können
diese Services keine Datentransformationen
oder Service-Aufrufe innerhalb der
Composite Application veranlassen. Wenn
der Web Service Get Role völlig losgelöst
von den anderen Web Services betrachtet
wird, benötigt er entsprechend des in Abbildung
1 dargestellten Geschäftsprozesses
nur das Datenelement EmployeeID
als Input Interface und das Datenelement
Role als Output Interface, um seine Arbeit
zu verrichten. In dieser Anwendung muss
er so erweitert werden, dass er einen der
Web Services Check Budget (R1), Submit
Delta
(R2), Submit United (R3) oder Send
Notification
(R6 AND R2 OR R3) aufruft
und dabei die entsprechenden Datentransformationen
auf Basis der dargestellten
Schemas durchführt. Das heißt, damit alle
möglichen Folge-Web Services ihre Informationen
bekommen, die sie für ihre Arbeit
benötigen, müssen sein Input-Schema
nicht nur das Datenelement EmployeeID
und sein Output-Schema das Datenelement
Role beinhalten, sondern der Web
Service muss alle Datenelemente erhalten
und weiterreichen, die die Folge-Web Services
benötigen. Das Geschilderte trifft in
ähnlicher Weise für den Web Service Check
Budget
zu. Es wird dargestellt, dass diese
Art der Entwicklung überhaupt nichts zur
Flexibilität einer Anwendung beiträgt, da
die fundamentalen Eigenschaften der Serviceorientierung
– lose Kopplung, Wiederverwendung
und optimale Granularität –
nicht vorhanden sind.

Die lose Kopplung

Da die Anwendung auf Basis direkter Service
zu Service-Aufrufe entwickelt wurde,
muss jeder Web Service Referenzen zu all
den Web Services beinhalten, mit denen er
kommunizieren soll. Um Web Service-Referenzen
zu definieren, müssen innerhalb
des Web Services alle Adressen der aufzurufenden
Web Services bekannt sein. Dies
verletzt die erste Ebene der losen Kopplung
– die Ortsunabhängigkeit. Wird die Adresse
eines Web Services geändert, müssen alle
Web Services, die eine Referenz auf diesen
haben, geändert und neu kompiliert werden.
Jeder Web Service, der einen anderen
aufruft, muss die Schnittstelle des aufrufenden
Web Services kennen, damit die im Web
Service kodierte Datentransformation
die entsprechenden Datenobjekte an den
aufzurufenden Web Service sendet. Dies
verletzt die zweite Ebene der losen Kopplung
– die Datenunabhängigkeit. Wird die
Schnittstelle eines Web Services geändert,
müssen alle Web Services, die eine Referenz
auf diesen Web Service haben, gefunden
werden, die Datentransformationen neu
kodiert und die Web Services neu kompiliert
werden. Da es keine zentrale Orchestrierung
des Service-Ablaufs gibt, muss in
jedem Web Service ein Teil des gesamten
Geschäftsprozesses kodiert sein. Sollte sich
dieser ändern, müssen in den entsprechenden
Web Services die partiellen Abläufe
entsprechend neu kodiert werden. Dies
verletzt die dritte Ebene der losen Kopplung
– die Prozess-Unabhängigkeit. Wird
der Geschäftsprozess geändert, müssen alle
Web Services, in welchen ein partieller Geschäftsprozess
kodiert wurde, und die von
der Änderung betroffen sind, gefunden, neu
kodiert und kompiliert werden.

Reusability (Wiederverwendbarkeit)

Wie oben aufgeführt, sind in Web Services,
welche andere Web Services aufrufen, ein
Teilablauf des Geschäftsprozesses sowie
die Datentransformationslogik kodiert.
Damit ist ein solcher Web Service nicht
mehr nur ein atomarer Software-Baustein,
der mit einem XML-Dokument entsprechend
seines Input-Schemas aufgerufen
wird, seine Geschäftsfunktion ausführt
und entsprechend seines Output-Schemas
ein XML-Dokument als Antwort liefert,
er ist vielmehr für eine bestimmte Umwelt
programmiert. Um ihn in einem anderen
Prozess mit anderen aufzurufenden Web
Services wieder zu verwenden, bedarf es
normalerweise größte Anstrengungen.

Die WF kommt ins Spiel

Da Web Services andere Web Services entsprechend
definierter Prozessregeln direkt
aufrufen (Abbildung 2), muss der referenzierende
Web Service die Datenobjekte
des referenzierten Web Services mit Daten
füllen. Das wird nicht auf einem höheren
XML-Dokumentenlevel, sondern auf
einem niedrigen, fein granulierten Datenobjekt-
Level programmatisch durchgeführt.
Obwohl die Kommunikation
zwischen Web Services auf einer hohen granularen
Ebene mittels XML-Dokumenten
abläuft, werden Business Logik und Datentransformationslogik
auf niedriger
granularer Objektebene durchgeführt.

Eine Composite Application, die mittels
direkt kommunizierender Web Services
entwickelt wurde, erfüllt nicht die
Ansprüche der Serviceorientierung nach
loser Kopplung, Wiederverwendbarkeit
von Software Assets und optimaler Granularität.
Was benötigt wird, ist ein Weg,
um den Prozesscode innerhalb der Web
Services zu entfernen und die Web Services
zu entkoppeln, damit außerdem kein
Transformationscode innerhalb der Web
Services entwickelt werden muss. Der erste
Schritt dorthin wird erreicht, indem die
Prozesslogik völlig aus den Web Services
herausgenommen wird und die Workflow
Engine der Windows Workflow Foundation
(WF) den Ablauf der Web Service-Aufrufe orchestriert. …

Kommentare

Schreibe einen Kommentar

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