ja, der Spruch mit dem Hammer und dem Nagel passt hier sehr gut

Es ist tatsächlich immer die Frage, wo man her kommt, und was man erreichen möchte. Von daher war die Diskussion für mich sehr interessant. Vielen Dank dafür.

Gruß
Rolf

Okay, dann sind wir jetzt ja wieder eher beieinander, ich habe ja auch nicht geschrieben “Technischer Zustandsautomat? Den bauen wir selber” Nee, natürlich ist jBPM nicht die eierlegende Wollmichsau. Der Use Case von dem ich gesprochen habe waren Geschäftsprozesse und Workflows. Wenn man in den tief technischen Bereich vordringt und alles abschneidet, was so eine Process Engine mitbringt (Persistenz, visuelle Modellierung, Vorfertigung im Bereich Task-Management und Serviceanbindung, …), dann ist sie denke ich auch wirklich nicht mehr das Richtige. Wobei gerade das Beispiel des Pageflows grenzwertig ist. JBoss Seam verwendet jBPM erfolgreich als Pageflow Engine. Ohne Persistenz natürlich, aber auch das ist ja kein Problem. Wobei hier ja genau die visuelle Darstellung genutzt werden soll, also zumindest ein Feature der Engine.

Also: Natürlich ist also mit der Process Engine als Hammer nicht jedes Problem ein Nagel! Gerade wenn man in den tief technischen Bereich vordringt würde ich auch nicht mehr unbedingt jBPM einsetzen. Da bestehen andere Anforderungen…

Wobei ich deinen Vergleich mit dem OR-Mapper nicht zählen lassen möchte. Wenn man nicht gerade Batch-Massenverarbeitung macht ist das mitnichten langsamer als Plain-JDBC. Schlussendlich steckt viel Know-How im OR-Mapper zu Optimierung der SQL-Statements. Eine Anmaßung von nicht SQL-Genies wie uns (also zumindest mir), das mal eben im Projekt besser machen zu können

Schöne Grüße
Bernd

danke für deine Antwort.

Ich werde deinen Rat befolgen und mal einen Blick in die Sourcen von jBPM 4 werfen. Ich bin vor allem an den API-Dokus interessiert.

Ich sollte wohl noch ein bisschen genauer auf meinen Standpunkt eingehen. Vielleicht wird dann verständlicher, worauf ich hinaus will.

(Wenn ich im Folgenden über PVM spreche, dann beziehe ich mich auf die Version, die auf der Webseite dokumentiert ist, also die von 2008. Den Stand aus den jBPM 4-Sources kenne ich noch nicht.)

Ich habe nämlich weniger an Business-Anwendungen gedacht, in denen man richtige Geschäftsprozess modellieren und dann abarbeiten möchte. Dafür finde ich jBPM tatsächlich gut geeignet, und auch nicht schwer zu verwenden. Ich dachte aber eher an Verwendungen, bei denen man normalerweise nicht an Geschäftsprozesse denken würde, ohne Application Server, Transaktionsmanager, evtl. auch ohne Datenbank: die Steuerung irgendwelcher programminterner Zustände.
Hier mal ein paar Beispiele (vielleicht nicht die besten, aber was besseres ist mir auf die Schnelle nicht eingefallen):
- Steuerung des Pageflows in einem Wizard in einer GUI-Anwendung
- Steuerung der Zustände in einem Netzwerkkommunikationsprotokoll.

Solche kleinen Zustandsverwaltungen findet man in sehr vielen Programmen. Klassicherweise würde man sowas mit einem switch-Konstrukt in einer Schleife (ein sehr primitiver Zustandsautomat) oder mit einem if-else-Gebirge lösen. Hässlich, aber pragmatisch. In solchen Fällen würde niemand die Zeit investieren, eine komplexe Engine einzubetten, sondern einfach zur klassichen, hässlichen Lösung greifen.
Dabei wären solche Fälle mit einer minimalistischen Prozess-Engine meiner Meinung nach gut bedient, da man den Zustandsautomaten dann nicht selbst schreiben müsste, sondern sich nur um die eigentlichen Aktionen kümmern müsste.

Für genau solche Fälle finde ich einige der Ansätze von PVM passend:
- Definition des Workflows in Code, nicht in XML: Meiner Meinung nach besser zu lesen, schneller zu tippen (dank Intellisense), und der Compiler prüft, ob alles passt. Es muss sowieso der Entwickler ran, wenn etwas geändert werden muss, da es sich um Programminterna handelt, und nicht um abstrakte Geschäftsprozesse.
- Eine einfache API (ProcessFactory), um die Prozesse zusammenzubauen: Noch bequemer und schneller kann man einen Prozess wohl nicht zusammenbauen.
- Austauschbarkeit von Services, um die Engine an die eigene Umgebung anzupassen.
- Lightweight (größtenteils): nur das Notwendigste wird angeboten; speziellere Konzepte (z.B. Taskhandling, Swimlanes), die für den von mir geschilderten Anwendungszweck unnötig wären, kann auf der Basis-Engine aufbauend entwickelt werden.

Nun gibt es aber auch Dinge, die ich auch an PVM schon wieder overblown finde:
- Die Persistenz-API ist auf OR-Mapper ausgelegt (z.B. die Methode save(Object) in der Session-API). Die Abbildung auf JDBC oder textbasierte Dateiformate ist schwierig; die Verwendung eines OR-Mappers stellt aber einen gewissen Overhead dar (auch aus Performancegründen).
- Die Verwendung einer XML-Konfigurationsdatei: wenn die Engine mit ein paar Zeilen Code für einfache Fälle konfiguriert wäre, wäre sie meiner Meinung nach schneller eingebettet.

Ich hoffe, mein Standpunkt ist nun etwas klarer. Für die von mir geschilderten Fälle würde ich wohl dazu tendieren, selbst etwas sehr leichtgewichtiges zu programmieren, während ich das für richtige Geschäftsprozesse in Enterprise-Anwendungen definitiv nicht tun würde.
Ich stimme dir aber zu, dass man den Aufwand nicht unterschätzen sollte. Spästens bei Splits und Subprozessen würde das Ganze wahrscheinlich etwas komplizierter werden.

Gruß
Rolf

Kann ich eigentlich nicht ganz nachvollziehen. Ja, jBPM hat eine kleine Lernkurve. Aber auf der anderen Seite finde ich es wirklich sehr leicht integrierbar, und das haben wir bereits in zahlreichen Projekten bei verschiedenen Kunen erfolgreich praktiziert. Ein paar Kniffe sollte man dazu halt kennen oder natürlich einen entsprechenden Berater anheuern (hüstel ).
Der Punkt ist: Eine selbstgebaute Engine läuft fast immer irgendwann aus dem Ruder und verursacht in der Wartung immense Kosten, das kann sich niemand heutzutage mehr ohne Not leisten (mit Not meine ich: Sehr spezielle Anforderungen, die in der Tat nicht abgedeckt sind). Oft braucht es auch lange, bis alle Anforderungen wirklich identifiziert wurden und sich die Engine stabilisiert. Ich finde den Vergleich zum OR-Mapper naheliegend: Hibernate hat auch eine Lernkurve, aber würdest du wirklich einen eigenen OR-Mapper bauen wollen?

Zur Frage JBoss PVM: Die PVM ist inzwischen released und stabil, da sie ja die Grundlage für jBPM 4 bildet. Die Webseite ist da leider inaktuell (trigger ich mal an). Aktuell ist es wohl am besten, einen Blick in die SVN-Sourcen zu werfen. Jaja, ich weiß Aber hey, es ist ja auch eher das interne Herz, was man nur anfasst, wenn man sich die Finger sowieso mit Java schmutzig machen möchte.

Übrigens: Wenn du dir dort mal anschaust, was mit der jPDL-Sprache noch on top kommt, ist dies wirklich sehr wenig. Wenn du also eine fertige Engine suchst bringt es wenig Vorteile die PVM statt jBPM jPDL zu verwenden. Außer du willst bewußt eine eigene Sprache implementieren (so wie wir aktuell BPMN 2.0 oder Bonita mit XPDL), dafür ist das Konzept der PVM dann ja auch gedacht

Es nachbauen kann ich auch nur noch mal davon abraten, ich habe ja hautnah als Committer miterlebt, wie viel Arbeit und vor allem auch Gehirnschmalz in der PVM stecken. Und da flossen ja bereits viele Erfahrungen aus jBPM 1-3 von verschiedenen klugen Köpfen ein. Spätestens Dinge wie Transaktionssteuerung, Clustering, Multi-Threading sind halt auch nicht easy…

Naja, letztendlich muss es aber jeder selber wissen. Ich schau es mir dann im jBPM-Migrationsprojekt später an ) Nee, quatsch. Also wenn du wirklich ganz konkrete Punkte hast, weswegen jBPM nicht passt und ihr ne eigene Engine braucht, würde mich das wirklich interessieren, kannst du also gerne schreiben.

Weihnachtliche Grüße
Bernd

Ich kann gut verstehen, wenn jemand selbst eine Engine bauen möchte, statt eine der etablierten zu verwenden. Insbesondere dann, wenn die Engine eingebettet werden soll, denn dafür finde ich persönlich schon jBPM zu groß/unhandlich.

Bernd, du hast JBoss PVM angesprochen. PVM sieht in der Tat vielversprechend aus. Es scheint sich tatsächlich (fast) auf das nötigste einer Process Engine zu konzentrieren, und sollte sich damit auch leichter an eigene Anforderungen anpassen lassen als die großen Engines. Allerdings ist die letzte offizielle Release auf jboss.org von 2008, und hat Alpha-Status. Die Dokumentation lässt auch noch viel zu wünschen übrig, und Roadmaps scheint es für das Projekt auch nicht zu geben. Somit würde ich selbst es momentan nicht einsetzten, da das Projekt nicht besonders ‘lebendig’ aussieht.
Allerdings würde ich PVM, wenn ich selbst eine Prozess-Engine entwickeln würde, zumindest als Inspiration verwenden, denn da stecken einige gute Ideen drin.

Da gebe ich dir recht. Ich bin nur immer noch ungläubig, dass es so komplex sein soll, eine Java-Workflow-Engine in diese Umgebung zu integrieren. Und das machen wir ja regelmässig in Projekten… Natürlich hat aber schon jedes Produkt eine Lernkurve, klar, aber ich habe ja geschrieben: “Natürlich darf man den zweiten Teil des Satzes nicht vergessen: “Das muss man aber wissen”. Ja, stimmt. ..”

Naja, trotzdem will ich auch nicht abreden, dass es Anwendungsfälle gibt, in dem eine Workflow-Engine nicht geeignet ist, wenn man eben andere Use Cases löst.
Mich würde einfach interessieren, wie es mit eurem Framework weitergeht und wie eure Erfahrungen in ein paar Jahren sind. Da würde ich mich dann gerne davon überzeugen lassen, dass es der richtige Weg war. Auch meine Meinung ist ja nicht in Stein gemeisselt

Die Anwendung an der ich arbeite basiert auf Eclipse RCP (mit Spring und Hibernate et al). Unter anderem hilft die Anwendung den Benutzer durch ein paar (meist sequentielle) Tasks die zum Teil relative komplex sind (Benutzeroberfläche, Datenverarbeitung etc).

Wie erwähnt stellte sich heraus dass der Code um eine existierende Engine in die Anwendung zu integrieren komplexer gewesen wäre als eine einfache Implementation die genau das tut was benötigt ist. Das ist ein wichtiger Faktor in einem kleinen/agilen Team. Schade dass wir keine leichtgewichtigere Tools gefunden haben (bester Kandidat: Sarasvati).

Wie die Situation in 2-5 Jahren aussieht ist schwer vorauszusagen. Vielleicht stellt es sich heraus dass wir mehr Workflow Features benötigen. Oder vielleicht ist sogar die einfache Lösung Overkill. Oder wir brauchen eine flexiblere Rule-Engine. Was sicher ist: Die einfache Lösung kann einfacher durch eine komplexere Lösung ersetzt werden als umgekehrt!

Vielen Dank für die Meinung. Prinzipiell glaube ich ja auch, dass man nie alles über einen Kamm scheeren kann. Vielleicht habt ihr ja tatsächlich einen Sonderfall vor euch.

Aber ich wäre auch echt gespannt, wie es euch mit dieser “Engine” später im Projekt udn vor allem im Betrieb geht und wie die Sache so in 2-5 Jahren aussieht. Denn wie ich geschrieben habe, der Anfang ist immer leicht und man unterschätzt was da noch alles kommt. Spätestens im Betrieb muss dann doch eben genau sehen, wo ein Prozess steht, vielleicht mal eine Instanz korrigieren usw.

Und sollte euch die Lösung vor die Füße fallen oder die Kernentwickler das Projekt verlassen, naja, dann wirds auch schwierig.

Kurzum: Ich finde das nach wie vor kritisch. Ich möchte ja auch niemandem zu nahe treten, aber ich denke beispielsweise in jbpm hat man nach dem 3 Tage JBoss-Training das notwendigste an der Hand um loszulegen, die wichtigsten Grundlagen vermitteln wir üblicherweise in einem Tag. Also in 2 Wochen sollte da schon ein Prototyp zu machen sein. Vor allem, wenn man stattdessen seine eigene Engine baut, was ja heißt, dass man schon was vom Entwickeln verstehen muss.

Ich denke, meist wird dann auch bei der Evaluierung zu ungezielt vorgegangen. Ich kenne das ja auch selber, man lädt dieses Tool, probiert ein bisschen. Geht nicht gleich, Hmm, naja, dann mal das Tool probiert. Und nach ner Woche ist man eher gefrustet und denkt, keins davon tut wirklich.

Ein bisschen mehr Zeit muss man dann halt dann doch mitbringen. Ich glaube weiterhin das es sich lohnt, lass mich aber auch gerne vom Gegenteil überzeugen. Da wäre zuerst auch mal interessant, für welchen Anwendungsfall die Engine zum Einsatz kommen soll…

Schöne Grüße
Bernd

Ist die Implementation hoch-skalierbar, unterstützt sie Standards und graphische Entwicklungsumgebungen? Nein. Aber ehrlich gesagt wäre nichts von dem wirklich von Nutzen gewesen für uns, und alleine der Code um eine “richtige” Workflow-Engine zu integrieren wäre komplexer (und schwieriger zu testen) gewesen.

Das will nicht heissen dass es sich nicht lohnen kann eine Workflow-Engine zu integrieren, aber eben halt nicht immer (insbesondre solange Engines wie JBoss jBPM als “leichtgewichtig” angesehen werden)…