Dehydrierungsverhalten von Prozessinstanzen in Oracle SOA Suite

Im Lebenszyklus eines BPEL-Prozesses werden dessen Prozessinstanzen mit Statusinformationen im Repository der Oracle SOA Suite gespeichert. Diesen Speichervorgang nennt man im BPEL-Umfeld auch Dehydration und die dazugehörige Datenbank ist der Dehydration Store. Sobald eine laufende Instanz (an bestimmten Aktivitäten im Prozess) dehydriert wurde, entfernt der BPEL Server diese aus dem Memory. Wenn daraufhin etwa ein Callback eines asynchronen Service-Aufrufes eintrifft oder ein abgelaufender Timer „feuert“, holt sich der BPEL Server die passende Instanz aus dem Dehydration Store zurück in den Memory und fährt mit der Ausführung fort. Einerseits sichert dieser Vorgang die Ausfallsicherheit, da laufende Instanzen nach einem Neustart des BPEL Servers oder nach einem fehlerhaften Aufruf automatisch am letzten Dehydrierungspunkt fortgesetzt werden können. Andererseits kann die Dehydrierung in einem Umfeld mit High-Performance-Anforderungen und einer enormen Anzahl an Prozessinstanzen kritisch sein.

Wann und wie die Dehydration ausgeführt wird, hängt vom gewählten Prozesstyp ab. Die Oracle BPEL Engine unterscheidet hierbei zwischen „transient“ und „durable“. Transiente Prozesse verursachen keine Dehydration während der Ausführung der Instanz. In Summe werden transiente Prozesse nur einmal am Ende des Prozesses dehydriert. Beispiele hierfür sind kurzlaufende synchrone Request-Response-Szenarios. Prozesse vom Typ „durable“ werden mehr als einmal „“ jeweils an bestimmten Aktivitäten (z. B. Receive, OnMessage, Wait) „“ dehydriert.

Prozesse, für die im Betrieb sehr viele Instanzen zu erwarten sind, sollten daher als transienter Prozesstyp umgesetzt werden. Im Allgemeinen sind hierfür die folgenden Anforderungen zu erfüllen:

• Keine Receive-Aktivitäten innerhalb des Prozessflusses
• Keine Wait-Aktivitäten
• Keine OnMessage-Aktivitäten
• Eine synchrone Schnittstellenbeschreibung

Sind diese Voraussetzungen erfüllt, müssen auf Composite- Ebene weitere Attribute gesetzt werden, um eine vollständige Ausführung des Prozesses im Memory zu gewährleisten. Diese werden nachfolgend aufgelistet und kurz beschrieben.

inMemoryOptimization=true

Der Standardwert dieses Parameters ist „false“. Die Eigenschaft kann nur gesetzt werden, wenn keine der o. g. Aktivitäten im Prozess enthalten ist. Steht der Wert auf „true“, wird für Instanzen dieses Prozesses eine Speicheroptimierung bei Wertzuweisungen vorgenommen.

completionPersistPolicy=faulted

Diese Property definiert, welche Prozessinstanzen gespeichert werden. Mit dem Setzen des Wertes auf „faulted“ werden nur fehlgeschlagene Instanzen gespeichert.

oneWayDeliveryPolicy=sync

Der Parameter setzt die Persistenz-Eigenschaften des Prozesses im Delivery Layer. Mit der Zuweisung des Wertes „sync“ wird erreicht, das die instanzerzeugende Nachricht nicht temporär im Delivery Layer gespeichert wird. Die Engine benutzt den Speicher für das Erzeugen der Nachricht.

Das Setzen der Werte führt bei synchronen Prozessen zur Steigerung der Performance und zur Reduktion der Laufzeitdaten, die in das Repository geschrieben werden. Gemäß den Erfahrungen aus unterschiedlichen Projekten konnte damit ein messbarer Geschwindigkeitsvorteil realisiert werden.