Es war nicht gefragt, aber ich würde vom Einsatz von Domino Workflow abraten.
In einem Projekt, das ich entwicklungsmässig betreue, ist es eine stetige Quelle des Ärgers.
Aus folgenden Gründen:
- es funktioniert als black box und erschwert somit das debugging.
- gerade wenn man in die DWF callback Methoden längere Routinen einbaut. reagiert es sehr unrobust gegen Serverabstürze/ Herunterfahren des Servers während des Agentenlauf. Dies gefährdet die Datenkonsistenz. Das ist nicht lustig. ...und reale Geschäfts-Anforderungen an ein System erfordern eben schnell mal längere, nicht-triviale Routinen.
Aus Wartungszwecken einen Server herunterfahren ist ein normaler Vorgang. Da dann erst mal einen Konsolenbefehl gegen den Agentenmanager absetzen zu müssen, um zu schauen, welche Agenten denn nun gerade laufen, halte ich für kein zeitgemässes oder erstrebenswertes Vorgehen in einer modernen IT.
- es führt zu einem vendor-lock-in. Es ist ein rein proprietäres IBM Produkt. Selbst bei größeren Kunden und spezifischen Problemen gibt IBM die sourcen nicht raus. In meinem Fall will der Kunde auch wg neuen Anforderungen an die Anwendung auf eine J2EE-Lösung wechseln. Er macht deshalb kein kostenpflichtiges update auf die neue Version. Das verteuert den IBM-Support für die gegenwärtige Lösung, zu dem man sich nun durchgerungen hat.
- wir haben ein sehr spezifisches Problem, wo der DWF Backgrounder offenbar auf der Produktiv-zOS-390 ein Memory Leak Verhalten aufweisst, das selbst mit Binärkopien der nsf-Datenbank in der produktionsnahen Testumgebungs-zOS-390 nicht reproduzierbar ist. Ausserdem läuft der Backgrounder auch in der Produktivumgebung ohne memory leak, wenn er von einer Workstation aus gestartet wird.
Das Memory Leak äussert sich, indem der Backgrounder immer mehr Arbeitsspeicher zieht, nix mehr freigibt und irgendwann den Agentenmanager zum Absturz bringt (definitiv no fun und kann nur von IBM gelöst werden, da es nix mit den Routinen in den call-backs zu tun hat und IBM den source-code nicht rausrückt).
Wenn eine interne Administration und eine externe Entwicklungs-Consulting mit solchen Dingen konfrontiert sind, führt dies zu Spannungen. Diesen schwelenden Verantwortlichkeitskonflikt in eine zielführende Lösungssuche zu transformieren war von allen Seiten nicht einfach, ist uns aber gemeinsam gelungen.
- zwar werden noch neue Versionen herausgegeben. Die Bedeutung des Produktes in der IBM Produktpalette erscheint mir aber nicht (mehr) sonderlich hoch angesiedelt zu sein. Mein Arbeitgeber hat schon bei Projektstart von dem Produkt abgeraten.
- Domino bietet von Hause aus gute Möglichkeiten, um Workflows zu programmieren.
- die API von DWF erscheint mir wenig übersichtlich und aufgeblasen.
- Es gibt in Java-Land da interessante open-Source und kommerzielle Lösungen für Workflow-Builder-Tools. Ausserdem bemühen sie sich um Komformität gegenüber in diesem Bereich wichtiger werdenden Standards. Es mag ein schlimmes und einseitiges Vorurteil sein, aber ich habe manchmal das Gefühl, das Standards und Stabilität 2 Dinge sind, die zu der Psychologie der c++ Hacker, die u.a. DWF konzeptioniert haben, oft orthogonal sind.
Gruß Axel
