Verwalten Sie Prozess- und Serviceabhängigkeiten in einer SOA-Umgebung
Hintergrund Wissen Sie, von welchen Diensten ein BPEL-Prozess abhängt? Werden unterschiedliche Versionen eines BPEL-Prozesses verwendet, können die Abhängigkeiten zwischen beiden schnell komplexer werden. Die Komplexität des Abhängigkeitsmanagements nimmt zu, wenn wir die vom BPEL-Prozess aufgerufenen ESB-Dienste (Enterprise Service Bus) berücksichtigen. Die Komplexität macht die Bereitstellung und das Testen zeitaufwändig, schwierig und fehleranfällig.
Am Ende verwenden wir häufig das Microsoft Visio-Modellierungstool, um Abhängigkeiten manuell grafisch darzustellen und nach jeder Änderung im Prozess mit der Aktualisierung der Abhängigkeiten zu kämpfen. Dies stellt ein großes Hindernis für die Agilität von Infrastrukturen mit serviceorientierter Architektur (SOA) dar, die darauf ausgelegt sind, agile Änderungen an Geschäftsprozessen zu ermöglichen.
In diesem technischen Hinweis erfahren Sie, wie Sie Ihren Build-Prozess erfolgreich verbessern und die automatische Generierung von Prozessabhängigkeitsdiagrammen implementieren.
Unsere Herausforderung besteht darin, für einen Kunden ein Oracle SOA Suite-Demonstrationsprojekt zu implementieren, das viele BPEL-Prozesse enthält und viele BPEL-Unterprozesse und ESB-Dienste referenziert. Am Ende nutzten wir ein Dutzend BPEL-Prozesse und ESB-Dienste (die als öffentliche Dienste definiert und im Dienstregister gemeinsam genutzt wurden) sowie andere proprietäre BPEL-Prozesse und ESB-Dienste.
Zunächst haben wir beschlossen, eine Ant-basierte Bereitstellung für alle Dienste des Projekts zu erstellen, die BPEL-Prozesse (einschließlich der Testfälle, die sie ausführen) in verschiedenen Umgebungen (Testen, Integration, Produktion) bereitzustellen und auch die ESB-Dienste bereitzustellen die Ant-basierten dieser Umgebungen. Computer-E-Books kostenlos herunterladen
Anforderungen Nach Abschluss der ersten Projektfreigabe haben wir einige Anforderungen:
,
Wenn sich ein BPEL-Prozess oder ein ESB-Dienst ändert, möchten wir nicht alle Dienste des Projekts bereitstellen. Daher müssen wir von einer projektzentrierten Bereitstellung zu einem auf den öffentlichen Dienst ausgerichteten Bereitstellungsansatz übergehen.
Bei der Bereitstellung eines BPEL-Prozesses werden auch alle abhängigen (proprietären) Unterprozesse und ESB-Dienste automatisch bereitgestellt.
Um das Überschreiben einer bestimmten Version eines Prozesses zu verhindern, stellen Sie diese Version des Prozesses nur bereit, wenn sie nicht bereits auf dem Server bereitgestellt ist. Beim Überschreiben gehen alle Instanzflussinformationen verloren.
Während der Bereitstellung sollte automatisch ein visuelles Diagramm aller Prozess- und Serviceabhängigkeiten erstellt werden, ohne dass diese Informationen separat gepflegt werden müssen. Die Visualisierung sollte so aussehen.
Offene Fragen Als Reaktion auf diese neuen Anforderungen haben wir die folgenden Fragen gestellt und folgende Antworten gegeben:
Frage: Wo werden die Informationen aus Prozess- und Serviceabhängigkeiten gespeichert? Müssen Sie weitere Informationen hinzufügen, um ein vollständiges Abhängigkeitsdiagramm zu erstellen?
Antwort: Alle vom BPEL-Prozess aufgerufenen Dienste werden in der durch partnerLinkBinding gekennzeichneten Datei bpel.xml gespeichert. Der aufgerufene BPEL-Prozess und die Versionsinformationen sind ebenfalls in der URL kodiert. Zum Beispiel: Kostenloser Download von Computer-E-Books
<property name="wsdlRuntimeLocation">
${domain_url}/CustomerAccount_BES/1.3/CustomerAccount_BES?wsdl
</property>
Die aktuelle Version des bereitzustellenden BPEL-Prozesses finden Sie in der Datei build.properties. Zur Versionspflege des BPEL-Prozesses müssen wir lediglich die rev-Eigenschaft in der Datei build.properties ändern.
Um zwischen öffentlichen und privaten BPEL-Prozessen zu unterscheiden, stellt der Partnerlink des Clients in der Datei bpel.xml ein neues Attribut „type“ mit dem Wert „public“ oder „private“ bereit, wie hier gezeigt:
<partnerLinkBinding name="client">
<property name="wsdlLocation">CustomerAccount_BES.wsdl</property>
<property name="type">öffentlich</property>
</partnerLinkBinding>
Frage: Gibt es ein Tool oder Framework, das Abhängigkeitsdiagramme dynamisch generieren kann?
Antwort: Ja, Graphviz ( www.graphviz.org ), ein Open-Source-Tool, kann Diagramme aus Eingabedateien im Textformat generieren.
Frage: Welche Möglichkeiten gibt es, auf andere BPEL-Prozesse zu verweisen?
Antwort: Die Optionen sind:
Referenzieren Sie die Standardversion. Referenzieren Sie eine bestimmte Version. Referenzieren Sie einen UDDI-Dienstschlüssel (mit oder ohne codierte Versionsinformationen).
Frage: Wie können all diese neuen Bereitstellungsanforderungen umgesetzt werden?
Antwort: Diese neuen Bereitstellungsanforderungen lassen sich am besten mit benutzerdefinierten Ant-Aufgaben erfüllen.
Nachdem die Fragen zu den ersten Schritten zufriedenstellend beantwortet wurden, beginnen wir mit der Erstellung einer benutzerdefinierten Ant-Aufgabe. Die Datei bpel.xml wird in der Ant-Task analysiert. Für alle gefundenen partnerLinkBindings-Tags beginnt die rekursive Analyse der entsprechenden bpel.xml-Datei. Zusätzlich zum Parsen wird der aktuelle Wert der Versionseigenschaft („ref“) aus der Datei build.properties jedes gefundenen BPEL-Projekts extrahiert. Eine der Herausforderungen beim rekursiven Parsen besteht darin, zyklische Abhängigkeiten zu überspringen.
Unser neues „type“-Attribut und die rekursive Analyse in der Datei bpel.xml implementieren alle unsere Anforderungen für die Bereitstellung unter Berücksichtigung des Dienstes.
Noch besser: Wir verwenden Graphviz, um das Problem der automatischen Generierung von Abhängigkeitsdiagrammen zu lösen. Um dies zu erreichen, werden wir alle Abhängigkeiten, die aus der rekursiven Analyse von bpel.xml stammen, in einer einzigen XML-Datei zusammenführen, wie unten gezeigt. Computer-E-Books kostenlos herunterladen
<?xml version="1.0"kodierung="UTF-8"?>
<BPELSuitcase>
<BPELProcess id="Resource_BAS_SetForAccount" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BAS_SetForAccount.bpel ">
<partnerLinkBindings>
<partnerLinkBinding name="client">
<property name="wsdlLocation">Resource_BAS_SetForAccount.wsdl</property>
<property name="type">öffentlich</property>
<property name="version">1.2</property>
</partnerLinkBinding>
<partnerLinkBinding name="RemoveFromAccount">
<property name="wsdlLocation">Resource_BAS_RemoveFromAccount.wsdl</property>
<property name="version">1.5</property>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProcess>
<BPELProcess id="Resource_BAS_RemoveFromAccount" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BAS_RemoveFromAccount.bpel ">
<partnerLinkBindings>
<partnerLinkBinding name="client">
<property name="wsdlLocation">Resource_BAS_RemoveFromAccount.wsdl</property>
<property name="type">öffentlich</property>
<property name="version">1.5</property>
</partnerLinkBinding>
<partnerLinkBinding name="CheckAvailability">
<property name="wsdlLocation">Resource_BES_CheckAvailability.wsdl</property>
<property name="version">1.1</property>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProcess>
<BPELProcess id="Resource_BES_CheckAvailability" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BES_CheckAvailability.bpel ">
<partnerLinkBindings>
<partnerLinkBinding name="client">
<property name="wsdlLocation">Resource_BES_CheckAvailability.wsdl</property>
<property name="type">öffentlich</property>
<property name="version">1.1</property>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProcess>
...
</BPELSuitcase>
Verwenden Sie XSLT, um die zusammengeführten XML-Dateien in ein Zielformat (.dot) zu konvertieren, das als Eingabe für den Graphviz-Generator verwendet werden kann, um ein PNG-Bild zu generieren, wie unten gezeigt:
Digraphenstrukturen {
Knoten [shape=record,fontname="Arial",fontsize="10"];
Kante [fontname="Arial",fontsize="8"];
rankdir=LR;
labeljust=l;
„Resource_BAS_SetForAccount_1_2“ [shape=record,label="{Resource_BAS_SetForAccount}|{1.2|public}",
fillcolor=gelbgrün,style=gefüllt];
„Resource_BAS_RemoveFromAccount_1_5“ [shape=record,label="{Resource_BAS_RemoveFromAccount}|{1.5|public}",
fillcolor=gelbgrün,style=gefüllt];
„Resource_BES_CheckAvailability_1_1“ [shape=record,label="{Resource_BES_CheckAvailability}|{1.1|public}",
fillcolor=gelbgrün,style=gefüllt];
„Resource_BAS_SetForAccount_1_2“ -> „Resource_BAS_RemoveFromAccount_1_5“ [decorate=true,label=""];
„Resource_BAS_RemoveFromAccount_1_5“ -> „Resource_BES_CheckAvailability_1_1“ [decorate=true,label=""];
}
Das von der obigen DOT-Datei generierte Abhängigkeitsdiagramm sieht folgendermaßen aus:
Der Dienstname, die Version und der Typ werden im Feld angezeigt. Die Feldfarbe gibt den Servicetyp an. In diesem Diagramm haben wir drei öffentliche (grüne) Dienste. Das Diagramm am Anfang dieses Artikels zeigt auch den ESB-Dienst (weiß) und den BPEL-Dienst (orange).
Nachdem wir das ideale Diagramm für jeden öffentlichen BPEL-Prozess erstellt haben, müssen wir die automatische Bereitstellung der relevanten Prozesse implementieren. Für diese serviceorientierte Bereitstellung haben wir die zuvor generierte Prozessliste verwendet. Für jeden Prozess in der Liste wird das Standardbereitstellungsziel aufgerufen. Um zu verhindern, dass vorhandene Prozessversionen auf dem Server überschrieben werden, wird das Bereitstellungsziel nur aufgerufen, wenn keine aktuelle Version des Prozesses auf dem Server vorhanden ist.
Sie können feststellen, ob eine bestimmte Prozessversion verfügbar ist, indem Sie eine HTTP-Verbindung zur WSDL-URL des Prozesses öffnen und dann den zurückgegebenen Statuscode überprüfen (HTTP-Status 200? Bereitgestellt, HTTP-Status 404? Noch nicht bereitgestellt). Computer-E-Books kostenlos herunterladen
Die Ausgabe unserer benutzerdefinierten Ant-Aufgabe (mit rekursiver Analyse), PNG-Bildgenerierung und servicezentrierter Bereitstellung sieht folgendermaßen aus:
...
[mkdir] Erstelltes Verzeichnis: /MyProject/Resource_BAS_SetForAccount/doc
[bpeltask] ** STARTING DeployWithDependencesTask **
[bpeltask] Resource_BAS_SetForAccount-1.2
[bpeltask] ** PARAMETER **
[bpeltask] dotfilename: doc/bpel-recursiv-all.dot
[bpeltask] dotfilenamepublic: doc/bpel-recursiv-public.dot
[bpeltask] DeployTarget: Deploy
[bpeltask] Bereitstellung: wahr
[bpeltask] Überschreiben: falsch
[bpeltask] stoponalreadydeployed: false
[bpeltask] ** ALLE bpel.xml-DATEIEN REKURSIV AUFLÖSEN **
[bpeltask] [Resource_BAS_SetForAccount-1.2]
[bpeltask] [Resource_BAS_SetForAccount-1.2, Resource_BAS_RemoveFromAccount-1.5]
[bpeltask] [Resource_BAS_SetForAccount-1.2, Resource_BAS_RemoveFromAccount-1.5, Resource_BES_CheckAvailability-1.1]
[bpeltask] ** ZENTRALE bpel.xml-DATEI SCHREIBEN **
[bpeltask] ** DOT-DATEI TRANSFORMIEREN **
[bpeltask] ** SERVICE-BEREITSTELLUNG **
[bpeltask] ============================================= =========================
[bpeltask] DIENST BEREITS BEREITGESTELLT (HTTP/1.1 200 OK) „Resource_BES_CheckAvailability“ in Version „1.1“ http://localhost:8888/orabpel/default/Resource_BES_CheckAvailability/1.1/ Resource_BES_CheckAvailability?wsdl
[bpeltask] ============================================= =========================
[bpeltask] ============================================= =========================
[bpeltask] DIENST BEREITS BEREITGESTELLT (HTTP/1.1 200 OK) „Resource_BAS_RemoveFromAccount“ in Version „1.5“ http://localhost:8888/orabpel/default/Resource_BAS_RemoveFromAccount/1.5/ Resource_BAS_RemoveFromAccount?wsdl
[bpeltask] ============================================= =========================
[bpeltask] ============================================= =========================
[bpeltask] DIENST NOCH NICHT BEREITGESTELLT (HTTP/1.1 404 nicht gefunden) http://localhost:8888/orabpel/default/Resource_BAS_SetForAccount/1.2/ Resource_BAS_SetForAccount?wsdl
[bpeltask] STARTEN DER DIENSTBEREITSTELLUNG von Resource_BAS_SetForAccount in Version 1.2
[bpeltask] ============================================= =========================
...
Fazit: Die serviceorientierte Bereitstellung, die automatisch Abhängigkeitsdiagramme generiert, erfüllt alle unsere Anforderungen an die Transparenz der SOA-Infrastruktur. Da die Bereitstellung vollständig auf Ant basiert, können wir es auch für unsere nächtlichen und produktiven Luntbuild-Build-Jobs (kontinuierliche Build-Umgebung) verwenden.
Um die SOA-Governance unserer Kunden zu unterstützen, stellen wir unseren öffentlichen Prozess und seine Dokumentation zusammen mit dem resultierenden Abhängigkeitsdiagramm im Wiki des Kunden bereit, wie hier gezeigt:
Wiki-Seiten werden dynamisch generiert, wenn eine Suche in der Dienstregistrierung die Version eines aktuell registrierten öffentlichen Dienstes abruft. Die Abbildungen auf der Wiki-Seite enthalten Links zum Quell-Repository (Subversion), das Abbildungen der Dokumentation und registrierten Versionen unserer öffentlichen Dienste in Originalgröße enthält. Klicken Sie auf die Miniaturansicht, um die entsprechende Datei über WebDAV von Subversion abzurufen