3-7 CD, Edi, Inhalt.indd

jBPM
JBoss jBPM: Graphentheorie für Geschäftsprozesse
Der Boss im Orchester
von adam bien
Speaker
@
Der Begriff Geschäftsprozess taucht immer wieder in der Analysephase der Anwendung auf. Je konkreter es wird, desto weniger beschäftigt man sich mit den wichtigen Abläufen innerhalb eines Unternehmens. Manchmal bleibt es sogar lediglich bei Worthülsen, welche zwar oft verwendet werden, aber
nur wenige Auswirkungen auf die Softwareentwicklung letztendlich haben. Workflow Engines sollten
dies ändern und dafür sorgen, dass die Fachlichkeit durchgängig und flexibel realisiert wird. Das JBossProjekt jBPM ist eine Open-Source-Realisierung einer Workflow Engine, welche aber auch außerhalb
eines Java EE-Containers ausgeführt werden kann.
Worflow Engines werden insbesondere
aufgrund der gewünschten Flexibilität und
Anpassbarkeit eingesetzt. Die Hoffnung
liegt in der flexiblen Zusammenstellung der
einzelnen Aktivitäten und somit in der Mi­
nimierung derWartung undÄnderungskos­
ten nach der Produktionseinführung des
Systems. Insb. in den heutigen SOA-Zeiten
erlebt man das Revival von konfigurativer
Nacheinanderschaltung von Aktivitäten
eines Services. Dabei benutzt man nur sel­
ten den etwas angestaubten Begriff Work­
flow Engine und spricht eher von Orches­
trierung der Services.
In der Praxis wird der Einsatz von
Workflow Engines meistens von strate­
gischen „Beratern“, getrieben, die mit
auf­wendigen Untersuchungen heraus­
finden, dass der Einsatz von Workflow
Engines Kosten sparen könnte. Diese eher
PowerPoint-getriebene Vorgehenswei­
se (kurz PPGV :-)), führt nur selten zum
gewünschten Ergebnis, da viele Anwen­
dungen bereits existieren und die flexible
Orchestrierung technisch schwer reali­
sierbar oder oft gar nicht möglich ist.Allein
die serielle Ausführung von unabhängigen
Services innerhalb einer Transaktions­
klammer ist sportlicher, als man denkt
– spätestens jetzt werden „Two phase com­
mit“-Protokolle wie z.B. XA benötigt.
Andererseits gibt es auch Anwen­
dungsfälle, die sich mit Java EE nur schwer
www.javamagazin.de
realisieren lassen. Asynchrone Vorgänge
lassen sich noch relativ einfach abbilden.
Dafür steht ja JMS zur Verfügung. Das
Warten auf externe Ereignisse ist deutlich
schwieriger durchführbar. Die Realisie­
rung von Thread-Sychronisierung und
Blockierung im EJB-Container ist gar
nicht erst erlaubt. Der Servlet-Container
erlaubt zwar dies, aber wahrscheinlich
nur, weil man es vergessen hat zu verbie­
ten – sowohl der Web-Container als auch
der EJB-Container laufen ja meistens in
einer JVM-Instanz ab. Neben dem be­
wussten Warten auf ein bestimmtes Ereig­
nis gibt es auch noch Fälle, die ungewollt
den Ablauf blockieren. Dies schlägt sich
nicht nur in der Zufriedenheit des Benut­
zers negativ nieder, sondern kann auch
ungewollte Seiteneffekte wie z.B. Dead­
locks, leere Thread-Pools und Transak­
tions-Time-outs verursachen. Potenziell
sind alle Vorgänge bzw. Methoden, die
länger als zwei bis zehn Sekunden dauern,
zunächst verdächtig und sollten auf je­
den Fall auf einer „Blacklist“ landen. Ein
späteres Review solcher Methoden kann
auch Auswirkungen auf die Fachlichkeit
der Anwendung haben. Solche Methoden
sind meistens für die Koordination von
feineren, transaktionalen Aktivitäten zu­
ständig und gehören somit oft einer Faca­
de an. Der Einsatz einer Workflow Engine
könnte das Problem beheben. Diese liefert
bereits Lösungen für das „Warten“ auf ex­
terne Ereignisse und kann auch potenziell
die Zuständigkeiten einer hart verdrahte­
ten Fassade übernehmen. Im Gegensatz
zu Java wurden Worflow Engines für das
„Warten“ entwickelt. Im Gegensatz zu
PPGV bringt in diesem Fall eine Worflow
Engine wie z.B. jBPM echte Vorteile mit
sich. Der Umgang mit Wait-States, Verar­
beitung von externen Ereignissen, Persis­
tenz, Auditing, Zuweisung von Aufgaben
zu Akteuren wird bereits out of the box
unterstützt.
Die Vision
Die Idee des jBPM-Projekts ist die Tren­
nung der Prozessdefinition von der tat­
sächlichen Realisierung der einzelnen
Aktivitäten. Das erlaubt die Trennung
der Zuständigkeiten des Prozess-Desi­
gners und Entwicklers. Obwohl in der
Praxis sich dabei oft um eine Person han­
deln wird, erhöht die Trennung der Fach­
lichkeit von der Technik auf jeden Fall
die Wartbarkeit des Codes. Der Prozess
wird mithilfe eines Aktivitätsdiagramms
modelliert. Dieser besteht ja aus Kno­
ten und den Übergängen zwischen den
Knoten. Man kann sich also die jBPM
En­gine als eine VM für die Ausführung
von Aktivitätsdiagrammen vorstellen.
Ein Aktivitätsdiagramm entspricht einer
Prozessdefinition. Bei der Ausführung
5.2006
91
jBPM
der Prozessdefinition entsteht eine Pro­
zessinstanz. Nur die Zustände dieser In­
stanz werden nach der Ausführung eines
Knotens persistiert. Alle Knoten einer
Prozessinstanz können auf die gleichen
Daten zugreifen. Das kann man sich wie­
derum als eine globale java.util.Map, also
ein Singleton, vorstellen. Die einzelnen
Knoten können über diese Map miteinan­
der kommunizieren. jBPM berücksichtigt
nicht nur Java-Aktvitäten (Methodenauf­
rufe), sondern auch externe Tasks, welche
von bestimmten Personen (Rollen) ab­
gearbeitet werden müssen. Insbesondere
dieses Feature setzt ein effizientes Warten
auf die Benutzereingaben voraus.
Ein Ausführungspfad innerhalb eines
Systems wird Token genannt. Gleichzeitig
hält ein Token auch die Referenz auf den
aktuellen Knoten. Die Kommunikation
zwischen Systemen oder die Ausführung
von menschlichen Tasks kann jedoch die
Ausführung des Tokens unterbrechen.
Dadurch ergeben sich automatisch War­
tezustände. Ein Wartezustand kann durch
ein Ereignis, ein so genanntes Signal, be­
endet werden. Das ist nicht nur auf die
Wartezustände beschränkt, im Gegenteil
– ein Signal verursacht den Übergang von
einem Zustand (Knoten) in einen anderen.
Falls von einem Knoten lediglich ein ein­
ziger Übergang ausgeht, reicht lediglich
das Auftreten eines Signals für den Kno­
tenwechsel. Bei mehreren Möglichkeiten
muss der Pfad bei dem Auftreten des Sig­
nals mitgegeben werden. Dabei handelt es
sich um einen einfachen String.
Bei der Ausführung eines Knotens
(Node) kann auch Geschäftslogik ausge­
führt werden. Neben der Durchführung
von Geschäftslogik ist ein Node auch für
das Warten oder die Übergabe der Kon­
trolle an andere Knoten zuständig. Nach
der jBPM-Philosophie sollte jedoch der
Prozess von der technischen Realisierung
streng getrennt werden. Diese Zustän­
digkeit erfüllen so genannte Actions. Es
handelt sich hierbei um Delegates, welche
indirekt einen ActionHandler kennen.
Bisher hat sich die Workflow Engine mit
sich selbst beschäftigt. Nun kommen die
Entwickler ins Spiel. Eine konkrete Reali­
sierung des Interfaces ActionHandler aus
dem Package org.jbpm.graph.def wird
entsprechend ausgeführt.
92
5.2006
public interface ActionHandler extends Serializable {
void execute( ExecutionContext executionContext )
throws Exception;
}
Der ActionHandler kann durchaus mit
dem Command Pattern (GoF) verglichen
werden. Ähnlich zu den Message Driven
Beans sollte man auch hier lediglich zu an­
deren Geschäftskomponenten verweisen
und nicht die fachlichen Vorgänge kom­
plett in der Methode execute ausimple­
mentieren. Auch hier gilt: Trennung der
jBPM-Technik von der Realisierung der
Fachlichkeit :-).
Die Technik
Die Elemente der beschriebenen Vision
wurden direkt auf den jBPM-Sourcecode
abgebildet. Die bisher beschriebenen Be­
griffe wie z.B. Node, Token, Transition
usw. findet man tatsächlich in der Imple­
mentierung der jBPM als Klassen wieder.
Nodes
Nodes repräsentieren die Bubbles eines
Aktivitätsdiagramms. Nodes werden mit­
hilfe von Transitionen verbunden. jBPM
bringt bereits einige Node-Implementie­
rungen gleich mit:
•State: Ist die einfachste Sorte der Nodes.
Ein State wartet einfach auf einen
Auf­ruf der Methode signal() der Pro­
cessInstance. Dabei kann es sich um ein
externes Ereignis handeln. Ein State ist
einfach „leer“, d.h., hier wird keine Ge­
schäftslogik ausgeführt.
•Node: Obwohl ein Node die Superklas­
se von State ist, kann sie wesentlich mehr
als der State selbst, d.h., State überschat­
tet die Funktionalität der Klasse Node
und tut selber nicht sehr viel. Das ist aus
der objektorientierten Sicht zumindest
als bedenklich einzustufen … Für die
Fun­­ktionalität bringt allerdings diese
Tatsache keine wesentlichen Nachteile
mit sich. Ein Node wartet nicht. Im Ge­
genteil, nach der „Ausführung“ eines
Node wird dieser automatisch über
die Default-Transition (d.h. bei einer
einzigen ausgehenden Verbindung)
verlassen. Somit erscheint der Einsatz
von Nodes zunächst als nicht beson­
ders sinnvoll. Allerdings verhalten sich
die Nodes nur so, wenn diese über noch
keinen ActionHandler verfügen. Die
Hauptaufgabe von Nodes ist die indi­
rekte Ausführung von Geschäftslogik.
Diese wird jedoch nicht durch eine Un­
terklasse von org.jbpm.graph.def.Node
realisiert, sondern vielmehr von einer
konkreten ActionHandler-Instanz be­
reitgestellt. Bei dieser Instanz handelt es
sich um eine so genannte Node Action,
also einen Delegate, welcher die notwen­
dige Logik mit sich bringt. Bei der As­
soziation einer Node Action mit einem
Node, übergibt der Node die Kontrolle
an den konkreten ActionHandler, d.h.,
der ActionHandler ist nun für die Aus­
führung des nächsten Übergangs zu­
ständig. Der ActionHandler kann ent­
weder die Ausführung der Default- oder
einer beliebigen anderen Transition an­
stoßen. Der ActionHandler kann somit
auch den weiteren Ausführungspfad des
Prozesses beeinflussen.
•Decision: Entscheidungen können von
ActionHandlern eines Node getrof­
fen werden. Allerdings wird diese Ent­
scheidung „hart kodiert“. Ferner ist die
Entscheidung lediglich im Sourcecode
sichtbar und steht dem Prozessmodel­
lierer nicht zur Verfügung. Die Decision
kann man vielmehr als die Vorgabe des
Prozessmodellierers an den Entwick­
ler verstehen. Decisions sollten immer
verwendet werden, wenn sie für die
Fachlichkeit des Geschäftsprozesses
eine Rolle spielen. Technische Entschei­
dungen dagegen, können durchaus in
den ActionHandlern getroffen werden
– diese sind für den Modellierer eher un­
interessant. Ähnlich zu dem einfachen
Node wird auch hier keine Unterklasse
der Decision gebildet. Vielmehr wird
diese Zuständigkeit wieder an einen ex­
ternen DecisionHandler delegiert.
public class SpecialDecisionHandler implements
DecisionHandler {
public String decide(ExecutionContext execution
Context) throws Exception {
return “special_transition_name“;
}
}
•Auch diese Entscheidungslogik sollte
nicht direkt in der Implementierung des
www.javamagazin.de
jBPM
Interfaces realisiert werden. Stattdes­
sen sollte man an dieser Stelle lediglich
bestehende Geschäftskomponenten
bzw. Services ausführen und entspre­
chend interpretieren. Das Ergebnis der
Entscheidungsfindung ist ein einfacher
­String. Dieser sollte mit einer ausge­
henden Transition des aktuellen Deci­
sion-Knotens übereinstimmen.
•TaskNode: Nun der TaskNode dient der
Interaktion mit einer externen Rolle.
Der TaskNode blockiert solange, bis alle
zugewiesenen Tasks von der zuständigen
Rolle abgearbeitet werden. Die Abarbei­
tung der Tasks führt zu einem neuen Si­
gnal, welcher letztendlich das Verlassen
des TaskNode bedeuten könnte (es kön­
nen ja noch weitere nicht abgearbeitete
Tasks dies verhindern …). Ein TaskNo­
de ist also ein besonders hartnäckiger
StateNode. Aus den Tasks entstehen
Task-Instanzen, die von den Akteuren
(Actors) abgearbeitet werden.
•Fork: Auch Fork ist ein Node. Die Zu­
ständigkeit des Fork Node ist klar defi­
niert: die Parallelisierung des Prozesses.
Der Fork Node transformiert eine einge­
hende Transition in zwei ausgehenden.
Die Funktionalität deckt sich mit den
Forks aus den Aktivitätsdiagrammen
überein.
•Join: Der Join Node ist das Gegenteil
eines Fork Node. Dieser konvertiert
die zwei eingehenden Transitionen wie­
der in eine ausgehende. Ein Join Node
wartet so lange, bis alle parallelisierten,
eingehenden Transitionen ankommen.
Erst dann wird der Join Node über die
Default-Transition verlassen. Somit ist
ein Join Node konzeptionell mit dem
aus UML bekannten Join-Bar absolut
vergleichbar
Event Actions und Node Actions zu un­
terscheiden. Event Actions können an
jedem Node angemeldet werden. Dabei
muss der entsprechende Zustandsüber­
gang wie z.B. After Signal, Before Signal,
Node Enter oder Node Leave angegeben
werden. Die Action wird dann beim Auf­
treten des entsprechenden Ereignisses
ausgeführt. Da die Event Action eigent­
lich nur von außen die Transi­tionen
be­obachten, dürfen diese den Ausfüh­
rungspfad nicht beeinflussen. Anders
sieht es bei den Node Actions aus. Diese
werden insbesondere bei den Nodes, also
der Superklasse, angewendet. Node Ac­
tions repräsentieren die technische Um­
setzung der Nodes und können durchaus
die weitere Ausführung des Prozesses be­
einflussen. Node Actions können sogar
die Aufgaben der Decision Nodes über­
nehmen.
Scheduler
Bisher mussten die einzelnen Knoten von
einem externen Actor getrieben werden.
Die Workflow Engine reagiert lediglich
auf die externen Ereignisse wie z.B. Be­
nutzereingaben oder Nachrichten von an­
deren Systemen. Bisher wurde allerdings
ein wichtiger Actor – der Timer – nicht
berücksichtigt. Ein Timer kann zu jedem
State­ deklarativ zugeordnet werden. Da­
bei ist explizite Erzeugung und Zerstörung
eines Timer beim Auftreten der Events No­
de Enter und Node Leave möglich. Bei der
Erzeugung eines Timer können sein Timeout und die Wiederholungsanzahl ange­
geben werden. Nach dem Time-out kann
eine gewählte Aktion ausgeführt werden.
Falls konfiguriert, kann auch die aktuelle
Node mithilfe einer angegebenen Transiti­
on verlassen werden. Timer werden aktiv,
wenn der aktuelle Knoten nicht vor dem
Ablauf des Timers bereits verlassen wird.
Timer sind also sehr hilfreich für die
Realisierung von Time-outs (zum Beispiel
bei der Überwachung der Benutzereinga­
ben) oder für die Implementierung von
automatischen Zustandsübergängen.
Die Timer werden mithilfe eines Sche­
duler ausgeführt. Dieser braucht für die
asynchrone Ausführung der Timer einen
Thread. Dies ist aber in einem EJB-Con­
tainer nicht erlaubt. Um das Deployment
in einen Application Server dennoch zu
ermöglichen, wird ein spezielles Servlet
bereitgestellt. Das Servlet org.jbpm.web.
JbpmThreadsServlet ist lediglich für die
Instanziierung des Schedulers und Star­
ten eines Thread zuständig. Nun wird
die jBPM Engine im Web-Container aus­
geführt, die ActionHandler-Implemen­
tierungen können aber bei Bedarf auch
Remote auf die entsprechenden ServiceImplementierungen im EJB-Container
zugreifen.
Auditing/Activity Monitoring
Die jBPM Engine bringt einen eigenen
Log­ging-Service mit. Dabei handelt es
sich jedoch keineswegs um eine weitere
Konkurrenz zu den Frameworks log4j
oder java.util.logging. Im Gegenteil
– bei dem LoggingService handelt es
sich um systematisches Monitoring der
jBPM-Vorgänge. Der org.jbpm.logging.
Action
Nodes werden insbesondere von den Pro­
zessmodellierern verwendet. Dabei in­
teressiert weniger die Realisierung dieser
Prozessvorgaben. Jedem Knoten können
sog. Actions zugeordnet werden. Jede Ac­
tion kennt einen ActionHandler, welcher
durchaus mit dem bekannten Interface
java.awt.event.ActionEvent verglichen
werden kann. ActionHandler können
die Ausführung der Geschäftslogik an­
stoßen. Allerdings ist hierbei zwischen
www.javamagazin.de
Anzeige
5.2006
93
jBPM
stand des Prozesses, welcher tabellenartig
(ähnlich zu einer Map) abgelegt wird. Für
den Zugriff auf die Prozessvariablen wird
jedoch nicht direkt mit der ContextSes­
sion, sondern vielmehr mit der Context­
Instance gearbeitet.
ProcessInstance processInstance =
new ProcessInstance(processDefinition);
ContextInstance contextInstance =
processInstance.getContextInstance();
contextInstance.setVariable(“key“, “value“);
contextInstance.setVariable(“date“, new Date());
Abb. 1: Der jBPM-Designer
log.LoggingService wird bei Zustands­
übergängen, Node Events, Ausführung
von Timern usw. für die Persistierung
des „fachlichen“ Zustands verwendet.
Standardmäßig verwendet der Logging­
Service für die Persistierung der LogEinträge Hibernate. Die Reihenfolge
der Einträge bleibt natürlich erhalten, es
wird das Datum, Token, Actor-ID bereits
von der abstrakten Klasse org.jbpm.log­
ging.log.ProcessLog vorgegeben. Von
dieser abstrakten Klasse erben andere,
spezialisierte Logs wie z.B. NodeLog,
welche noch zusätzliche Informationen
(bei NodeLog die Dauer der Ausführung,
den Knoten selbst, das Datum/Uhrzeit
des Eintritts und des Austritts des Kno­
tens) mit sich bringen. Mit diesem Ansatz
werden keine flachen Dateien, sondern
vielmehr objektorientierte Strukturen
weg­geschrieben. Dabei werden nicht
nur die zusätzliche Information, sondern
auch die korrespondierenden Instanzen
festgehalten. Eine objektorientierte Sicht
auf die Logs öffnet ganz neue Möglich­
keiten der Auswertung. Der Zugriff auf
die Daten kann sowohl über die bereits
bestehenden Hibernate-Entitäten als
94
5.2006
auch für z.B. Report-Zwecke direkt über
JDBC wie z.B. DAOs erfolgen.
Persistenz
jBPM verwendet nicht nur für die Persis­
tierung der Logs das Hibernate-Frame­
work, vielmehr handelt es sich hier um ein
durchgängiges Konzept. Für alle bis­her
vorgestellten Entitäten wie zum Beispiel
Node, State, Token, Timer, Actor usw.
existiert ein Hibernate-Mapping, somit
können automatisch alle Entitäten persis­
tiert werden. An dieser Stelle merkt man
die Vorzüge der „transparenten“ Persis­
tenz. Die objektorientierten Strukturen
können ohne umständliche Konvertie­
rungen direkt und transparent am Ende
der Transaktion in die Datenbank wegge­
schrieben werden. Die Persistierung der
Objekte wurde fachlich in unterschied­
liche Bereiche getrennt. Prozessrelevante
Entitäten werden mithilfe der GraphSes­
sion persistiert und auch geladen. Es kön­
nen sogar zur Laufzeit der Engine neue
Prozessdefinitionen persistiert werden.
Die ContextSession ist dagegen für
die Persistierung der Prozessvariablen zu­
ständig. Dabei handelt es sich um den Zu­
Es können zunächst alle Java-Datentypen
als Variablen abgespeichert werden. Al­
lerdings wird hier ein Objekt erwartet,
sodass man entweder die Verpackung der
elementaren Datentypen in die Wrapper
selbst übernimmt oder dies an das Java 5
Autoboxing delegiert. Zusätzlich können
noch alle java.io.Serializable-Instanzen
gespeichert werden, bei ausgefallenen An­
forderungen müssen jedoch eigene Imple­
mentierungen des org.jbpm.context.exe.
Converter diese Aufgabe übernehmen.
Die Konvertierung und Rückkonvertie­
rung einer nicht persistenten Instanz in
eine persistente Repräsentation muss von
der Implementierung dieses Interfaces be­
reitgestellt werden.
Es existiert noch eine Reihe von wei­
teren Sessions, eine spezielle LoggingSes­
sion, TaskMgmtSession, SchedulerSes­
sion usw. Die hier vorgestellten Sessions
umhüllen eine Hibernate-Session und
lassen sich gut mit dem DAO Pattern ver­
gleichen. Dabei erhält nicht jedes DAO
eine neue Hibernate-Instanz, sondern
vielmehr einen bestehenden Singleton.
Diese Aufgabe übernimmt der Persistence­
Service, welche eine Facade zu der jBPMPersistenz realisiert. Die thematische
Gruppierung der Sessions erleichtert den
Umgang mit der Persistenz.
Die Tool-Unterstützung
jBPM kommt mit einem eigenen Desi­
gner-Plug-in, welches aber getrennt he­
runtergeladen werden muss. Nach der
Eclipse-Installation (Eclipse 3.1.1 wird
bereits unterstützt), kann mit dem Pro­
jekt-Wizard ein jBPM Process Project er­
www.javamagazin.de
jBPM
stellt werden. Das wird auch empfohlen,
da dadurch ein einfacher Prozess mit funk­
tionierendem JUnit-Test erzeugt wird.
Die Installation des Designers verläuft
problemlos – es werden auch keine Libra­
ries oder Projekte wie z.B. GEF vorausge­
setzt. Der jBPM-Designer erlaubt visuelle
Modellierung von Prozessen. Beim Spei­
chern erfolgt die Synchronisierung mit der
Datei prozessdefinition.xml. Der Designer
ist zwar komfortabel, aber unterstützt
noch nicht alle Features wie z.B. Timer.
Entwickler werden wahrscheinlich nach
wenigen Klicks die XML-Datei direkt edi­
tieren, die Prozess-Designer werden sich
sträuben, ihre geliebten „Bubble-Tools“
aufzugeben, um mit einem Eclipse-Plug-in
weiterzumodellieren. Hier liegt das Pro­
blem. Das Diagramm sieht zwar wie ein
stereotypisiertes Aktivitätsdiagramm aus,
das Ergebnis wird jedoch direkt in einer
JPDL-Datei abgelegt (die JBoss-Prozess­
definition). Somit können Aktivitätsdia­
gramme aus bestehenden Modellen nicht
wieder verwendet werden. Andererseits
kann man so den jBPM-Designer ohne ein
UML-Tool verwenden.
Da das JPDL-Schema einfach ist, kann
man es auch generieren. Dies wäre insbe­
sondere für Projekte sinnvoll, in denen
UML-Werkzeuge bereits für die Modellie­
rung der Fachlichkeit verwendet werden.
Die nichtfunktionalen Qualitäten
Neben den rein funktionalen Anforde­
rungen sind auch die nichtfunktionalen
Anforderungen der jBPM für den reellen
Einsatz interessant:
•Skalierbarkeit/Cluster-Fähigkeit: Die
Prozessinstanzen der jBPM Engine sind
durchaus zustandsbehaftet. Neben den
reinen Informationen über den aktuellen
Prozesszustand (z.B. die Referenz auf
den aktuellen Knoten) können ja auch
nahezu beliebige Benutzerdaten mitver­
waltet werden. Umso interessanter ist
die Frage, ob so ein Ansatz überhaupt
skalieren kann. Die Zustände der En­
gine werden von Hibernate verwaltet.
Der Zeitpunkt der Persistierung des Zu­
stands kann mithilfe von Transaktionen
bestimmt werden. Die Skalierbarkeit
der jBPM Engine wird also direkt von
der jeweiligen Transaktionsstrategie be­
einflusst. Nach dem Commit der Trans­
aktion ist der ganze Zustand der Engine
persistent. Da eine Prozessinstanz den
ganzen Zustand in einer zentralen Da­
tenbank verwaltet, ist der Ansatz auch
clusterfähig, da zwischen den atomaren
Prozessschritten die Cluster-Instanzen
sogar gewechselt werden können. Die
Cluster-Fähigkeit und der Grad der Ska­
lierbarkeit der jBPM Engine sind mit ei­
ner Stateless Session Bean vergleichbar,
welche innerhalb eines Methodenauf­
rufs auf Hibernate-Entitäten zugreift.
Die Cluster-Fähigkeit der jBPM könnte
durch den Scheduler gefährdet werden.
Dieser wird ja mithilfe eines Servlets
implementiert, welches in der Initia­
lisierungsphase einen Thread startet.
Der Thread übernimmt aber lediglich
die Rolle eines Taktgebers. Da der Aus­
führungsplan auch in der Datenbank
persistiert wird, ist auch dies unkritisch
– im Cluster-Betrieb wird lediglich öfter
auf die Jobtabelle zugegriffen. Dennoch
sollte man im Cluster-Betrieb vorsichtig
sein. In der Standard-Konfiguration ist
der Second-Level-Cache eingeschal­
tet. Ferner könnten sich potenziell die
Cluster-Knoten gegenseitig die Daten­
Anzeige
bank überschreiben. Man sollte hier
unbedingt die Konsistenz des Prozess­
zustands mit pessimistischen (z.B. „se­
lect for update“, was aber nur selten
empfohlen werden kann) oder optimis­
tischen Locks sicherstellen. Es ist aber
nichts Ungewöhnliches – lediglich ein
Standardproblem beim Einsatz von
OR-Frameworks mit eingeschaltetem
Cache im Clusterbetrieb …
•Anpassbarkeit/Deployment: jBPM
wird in JBoss bevorzugt als ein SAR
oder WAR deployt. Bei anderen Ap­
plication-Servern kann man sich für
ein WAR oder EJB-JAR entscheiden,
wobei die Ausführung des Scheduler
im EJB-Container zu Problemen füh­
ren kann. Neben dem eher statischen
Deployment können zur Laufzeit neue
Prozessdefinitionen installiert werden.
Dies funktioniert sogar im laufenden
Betrieb sehr gut. Getrennte Classloa­
der (jede Prozessinstanz wird in einem
eigenen Classloader ausgeführt) er­
möglichen sogar gleichzeitige Ausfüh­
rung von unterschiedlichen Versionen
einer Prozessdefinition. Ferner können
sogar neue Prozessdefinitionen in zum
Beispiel ActionHandlern erzeugt wer­
den. Die jBPM-Architektur macht einen
durchdachten und klaren Eindruck.
Die Trennung der Definition von der
Instanz (beispielsweise ProcessDefinti­
on, ProcessInstance) erlaubt eine hohe
Erweiterbarkeit. Der Kern der Engi­
ne wurde in unterschiedliche Module
partitioniert, wobei lediglich das Pro­
zess-Modul unbedingt erforderlich ist,
alle anderen Module sind optional. Für
typische BPM-Anwendungsfälle wird
eine Erweiterung der jBPM jedoch nicht
notwendig sein, im Gegenteil meistens
jBPM
müssen lediglich „Prozess-Listener“
implementiert werden.
•Konformität: Der Geschäftsprozess
kann zwar auch zur Laufzeit der Anwen­
dung definiert werden, im Normalfall
wird aber solche hohe Flexibilität nicht
benötigt. Der Geschäftsprozess wird
zu diesem Zweck in einer XML-Datei
definiert. Die Java Process Definition
Language (JPDL 3.1) ist zwar proprie­
tär, dafür aber sehr einfach aufgebaut.
Die hier beschriebenen Konzepte bzw.
Entitäten werden direkt auf XML Tags
abgebildet. Dies erhöht die Wartbarkeit
und erleichtert auch ggf. die Generie­
rung der Prozessdefinition. Es existiert
auch eine BPEL-Erweiterung, allerdings
erst im Alpha-Status. Im Gegensatz zu
den anderen Modulen wird die BPELErweiterung mit einer „Custom“-Li­
zenz vertrieben. Somit sollte man sich
im kommerziellen Umfeld erkundigen,
was das konkret bedeutet. Alle ande­
ren Module sind mit der LGPL-Lizenz
erhältlich, was den kommerziellen Ein­
satz uneingeschränkt erlaubt. Auch bei
reinen Rich-Anwendungen muss leider
immer ein WAR mitdeployt werden.
Der Scheduler benötigt einen Thread,
welcher ja im EJB-Container nicht ge­
startet werden kann. Abhilfe könnte
hier eine MBean oder eine Timer Bean
schaffen – diese könnte die Zeitgebung
des Scheduler übernehmen.
Fazit
jBPM macht einen sehr guten Eindruck.Al­
lerdings war die Qualität der JBPM Engine
bereits vor der Übernahme durch JBoss Inc.
recht hoch. Für Einsteiger ist besonders das
Starter-Kit zu empfehlen. Hierbei handelt
es sich um einen vorkonfigurierten JBoss
3.0.2 mit einigen Beispielprojekten, eine
vorinitialisierte HSQL-DB, Schemas für
die gängige Datenbanken und eine unge­
wöhnlich gute Dokumentation. Somit ist
jBPM auf jeden Fall einsetzbar. Man sollte
jedoch SOA, Orchestrierung, Choreogra­
phie nur dort einsetzen, wo es fachlich tat­
sächlich auch sinnvoll ist. Die meisten ser­
verseitigen Anwendungen kommen auch
hervorragend ohne eine Workflow Engine
aus. Andererseits lassen sich mit jBPM lang
laufende Transaktionen,Time-outs, Benut­
Anzeige
zerwechsel oder Auditing einfach und ele­
gant lösen. Bei allen Buzzwords und Hypes
darf man die funktionalen Anforderungen
des Kunden nie vergessen. Zunächst die
Fachlichkeit, dann die Technik …
Wie „Professional“ der Sourcecode
von jBPM tatsächlich ist, merkt man nach
einem kurzen Review sofort – er ist so klar
und verständlich, dass man ihn nicht mit
Javadoc-Kommentaren verunreinigen
möchte :-).
Adam Bien arbeitet als freiberuflicher Berater
und Dozent im Enterprise-Java-Bereich. Seine
praktische Erfahrung stammt aus seiner Mitarbeit an vielen Java- und Java EE-Projekten,
in denen er als Architekt und Softwareentwickler tätig ist. Er entwickelt bereits seit JDK 1.0 mit Java
und hat die Bücher „Enterprise Java Frameworks“, „J2EE
Patterns“, „J2EE HotSpots“ und „Struts“ sowie zahlreiche
Fachartikel zur verteilten Java-Programmierung verfasst.
Adam Bien ist BEA Technical Director, Mitglied des Advisory Board der JAX in Frankfurt und Expert Group Member
des Java Community Process (JCP). Momentan beschäftigt
er sich mit der Model Driven Architecture (MDA), EAI-Komponentenarchitekturen für Java EE und .NET und einigen
Buchprojekten.
Links
[1]jbpm.org
[2]www.adam-bien.com