Der lange Weg zu SOA - JAXenter

Der lange Weg zu SOA

… Jeder Web Service teilt der Middleware seine Adresse sowie seine Dokumentenschemas für Input und Output mit und abonniert an die Middleware gesendete Dokumente. Im Bild haben sich z.B. die Web Services Get Authorization und Check Availability auf das an die Middleware gesendete Dokument Travel Request (TR) abonniert. Wird nun ein Travel Request Dokument an die Middleware geschickt schaut die Middleware nach, welche Web Services sich auf dieses Dokument abonniert haben und übernimmt die Datentransformation (sie kennt die Schemas).

Danach sendet die Middleware das nun für die Services übersetzte und verständliche Dokument. Bezüglich der Servicekommunikation haben wir es mit einer völlig losen Kopplung zu tun. Kein Service kennt weder die Adresse noch das Datenformat (Schema) des Anderen. Sind wir nun fertig? Nein, der Ablauf zur Implementierung eines Geschäftsprozesses fehlt- in unserem Beispiel erhalten beide Services das für sie transformierte „Travel Request“ Dokument zur gleichen Zeit, sicher kein sinnvoller Ablauf! Die Einbringung einer Service Orchestration Engine (SOE), Software die den Ablauf steuert, löst das Problem! Wie im Bild gezeigt, arbeiten nun Middleware und Service Orchestration wie folgt im Tandem zusammen. Wird ein Dokument an die Middleware gesendet, reicht sie dieses zuerst an die SOE und diese untersucht das Dokument nach Elementen und ihren Werten, um zu entscheiden welche Folgeaktivität(en), entsprechend dem im Prozess-(Orchestrierungs-)Modell definierten Ablauf, ausgeführt werden sollen. Diese Information liefert die SOE der Middleware. Damit kommuniziert die Middleware nur mit dem durch die SOE definierten Service. Operation gelungen. Doch Moment: Ein Problem gilt es noch zu lösen.

Kanonische Dokumente

Web Services haben sich auf die Output Dokumente der Web Services abonniert. Auch die SOE erhält diese „nativen“ Dokumente. Wir wollen eine flexible IT, aber wenn sich ein Interface eines Web Service ändern muss oder ein anderer Web Service mit einem anderen Schema eingesetzt werden soll, müssen die Übersetzungen der Middleware für alle Web Services, die sich auf das alte Output Dokument abonniert haben, geändert werden. Noch schlimmer, die SOE wird Dokumente mit neuen Dokumentschemas nicht verstehen.

Dieses Problem wird mit der Einführung sogenannter „kanonischer Dokumente“ gelöst. Ein kanonisches Dokument ist ein internes standardisiertes Dokument. Die Middleware und die SOE kommunizieren nur mittels kanonischer Dokumente. Die folgende Abbildung zeigt, wie native Dokumente immer in kanonische Dokumente übersetzt werden und wie kanonische Dokumente immer in native Dokumente übersetzt werden, bevor sie an einen Web Service gesendet werden:

Abb. 9: Die Geschäftsregeln werden über eine Rule Engine implementiert

Die Änderung eines Web Service Interfaces (Schemas) benötigt nur eine lokale Änderung der Übersetzungskomponente, damit das konstant gebliebene kanonische Dokument durch geänderte Transformationen dem neuen Schema entspricht. Die SOE arbeitet weiter, die kanonischen Dokumente haben sich nicht geändert! Um den Prozess nicht ändern zu müssen, wenn sich Geschäftsregeln ändern, ist es sinnvoll das Auswerten der Geschäftsregeln einer speziellen Rule Engine zu überlassen, denn bei Regeländerungen müssen nur die Regeln deklarativ geändert werden.

Ausblick

In der nächsten Folge dieser Serie werden wir die Komponenten einer SOA beschreiben und zeigen, wie .NET 3.0 mit der Windows Workflow Foundation (WF) und Windows Communication Foundation (WCF) eine technologische Plattform für Serviceorientierung liefert.

Dr. Peter Eichhorst ist CEO der SOCON Inc. in San Diego und Dresden (www.soconinc.com) und bekannt als „Vater“ von OPEN ACCESS und ENFIN, der ersten objektorientierten Enterprise Entwicklungsumgebung. Er leitet die Entwicklung des serviceorientierten Tools SC SOBA Studi. Sie erreichen ihn unter peichhorst@soconinc.com.

Kommentare

Schreibe einen Kommentar

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