Der lange Weg zu SOA, Teil 3

… physikalischen Web Service definiert.
Da die Input-Property des SendActivity-Objektes durch die WSDL des Services definiert
wurde, enthält sie andere Namen für
ihre Datenobjekte als das Interface der Orchestrierung.
Deshalb wird Code benötigt,
der die GetRole_Input-Property mit Daten
aus der TravelRequest-Property füllt:

this.GetRole_Input.Emp_ID = this.FlightRequestProperty.
EmployeeObject.EmployeeNumber;

Mit dem WF-Designer werden Prozessflussbedingungen
für die Zweige eines
If Else-Konstrukts kodiert. Diese Bedingungen
werden mithilfe der internen
Properties der Orchestrierung definiert.
Z.B. enthält die Flight Request HandlingOrchestrierung einen Order RequiredZweig, welcher kodiert wird, um zu prüfen,
ob die Rolle des Mitarbeiters (aus dem
Get Role-Service) Manager oder der Budget
Score (aus dem Check Budget-Service)
größer gleich 5 ist. Die folgende deklarative
Anweisung muss in dem If Else-Zweig
kodiert werden, der zu den Order-Web
Services führt:

this.GetRole_Output.Emp_Role == Manager ||
this.BC_Output.EmployeeDepartmentBudgetScore >= 5

Es fällt auf, dass die Bedingung die Datenelemente
von zwei verschiedenen Quellen
benutzt: Ein Datenelement (Employee
Role
) kommt von der GetRole_Ouput-Property, welche aus dem WSDL des physischen
Get Role Services erstellt wurde, ein
anderes (Budget Score) von der BC_OutputProperty, welche aus dem WSDL des
physischen Check Budget-Services erstellt
wurde. Wenn einer dieser Services geändert
wird, müssen alle Bedingungen, die dessen
Daten nutzen, neu kodiert werden. Eines
der Hauptprobleme des WF-Desginers ist,
dass Datenobjekte und Datenelemente innerhalb
der Orchestrierung von den Schemata
der physischen Web Services der Orchestrierung
kommen. Das führt zu einem
Problem, das schon bei der Beschreibung
von Composite Applications mit Service
zu Service-Aufrufen beschrieben wurde.
Anstatt den Code zur Transformation der
Daten in den Web Service auszulagern,
geschieht die Umwandlung der Daten im
Code der Orchestrierung. Das führt dazu,
dass das Orchestrierungsprojekt viele Datenobjekte
und Elemente enthält, die unterschiedliche
Namen haben, sich aber auf
dieselben Daten beziehen. Dies ist in Tabelle
1 dargestellt, indem die Datenelemente
zusammengestellt werden, die sich auf den
Nachnamen des Mitarbeiters beziehen,
der die Fluganforderung gestellt hat.

Tabelle 1: Die Elemente der Orchestrierung

Es fällt auf, dass FlightRequestProperty
ein Datenobjekt EmployeeObject
mit dem Datenelement LastName besitzt.
Die Delta_Input-Property enthält ein Datenobjekt
CustomerInformation mit dem
Datenelement Customer_LName. Die
United_Input-Property enthält ein Datenobjekt
PassengerData mit dem Datenelement
Passenger_LastName. Letztlich enthält
die Notification_Input-Property ein
TravelInformation-Datenobjekt, welches
ein EmpData-Objekt enthält, worin sich
ein Emp_LastName-Datenelement befindet.
Innerhalb des Orchestrierungsprojektes
existieren vier Datenobjekte mit vier
unterschiedlichen Datenelementen, die
alle dieselben Daten enthalten. Das liegt
daran, dass die Namen Datenobjekte und
Datenelemente durch die physikalischen
Web Services generiert werden. Man stelle
sich vor, ein Service wird mit einem anderen
ausgetauscht. Die Properties, die von dem
alten Service generiert wurden, werden unbrauchbar
und die neuen müssen mithilfe
des neuen Services generiert werden. Der
Code, der sich auf die alten Properties bezieht,
muss neu kodiert werden, damit er
sich auf die neuen Properties und deren
neue Datenobjekte und Datenelemente bezieht.
Es bestehen also klare Vorteile gegenüber
den Service zu Service-Aufrufen, wenn
man Composite Web Services mit dem
WF-Desginer erstellt. Trotzdem existieren
weiterhin Probleme im Bezug auf die
SOA-Prinzipien der losen Kopplung, Wiederverwendbarkeit
und Granularität.

WF-Designer und lose Kopplung

Mit dem WF-Desginer können Orchestrierungen
nicht auf einem logischen Level
definiert werden. Das führt zu einer engen
Kopplung zwischen den Composite Web
Services und den verwendeten Web Services.
Eine Service Reference muss für jeden
Service in der Orchestrierung erstellt werden.
Um eine Service-Referenz zu erstellen,
muss die Adresse des referenzierten
Services eingegeben werden. Das führt zur
ersten Stufe der engen Kopplung zwischen
den Composite Web Services und den Web
Services, die sie verwenden. Wenn sich ein
Web Service ändert, sei es nur die Adresse,
muss die Service Referenz im Visual Studio
aktualisiert und der Composite Web Service
neu kompiliert und erstellt werden. …

Kommentare

Schreibe einen Kommentar

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