jBPM vs Activiti
W sumie, to nie zamierzam robić żadnych ogromnych analiz porównawczych, o tym w internecie już trochę napisano. Czasami dyskusje są na poziomie przekonywania się grup zwolenników Eclipse i IntelliJ IDEA, gdzie każdy "broni swego", ale można też spotkać artykuły w stylu "jBPM5 vs Activiti5? dumb question?".
Każdy z produktów opiera się na nowej specyfikacji BPMN 2.0, zatem są "na czasie". Uniwersalny format umożliwia zmianę rozwiązania lub wykorzystanie innych, teoretycznie nie powiązanych narzędzi. Przynajmniej w teorii 
Wracając do rozważań - z jednej strony jest JBoss i jBPM5, za którym stoją poprzednie wersje oraz silnik reguł - Drools. Z dugiej - kontunuacja jBPM4.4 tyle, że pod innym szyldem, stąd też inna nazwa.
Ale sprawa jest bardziej skomplikowana. Red Hat wspiera tylko starą wersję jBPM'a - 3. Wersji 4-tej nigdy nie zamierzał. Zgodnie z planami dopiero wersja 5-ta będzie posiadała status LTS (Long-Term-Support). Ale... (zawsze musi być jakieś ale???) owa wersja nie jest zwykłą kontynuacją. I nie chodzi tu tylko o zmianę wykorzystywanej składni na standard BPMN 2.0. Zmiany są dużo większe - otóż m.in. zostają połączone dwa, niezależne do tej pory, silniki - silnik procesowy (czyli kontynuacja wcześniejszych wersji) oraz silnik reguł (Drools oraz m.in. Drools Flow). Do tego dochodzą - konieczne poniekąd - zmiany w architekturze. To powoduje, że duży nacisk prac musi być położony na integrację obu platform, a stabilizacja jeszcze trochę potrwa.
Activiti jest produktem, który być może trafił na swoje przysłowiowe 5 minut. Zapoczątkowany przez dwóch liderów jBPM'a w (niemalże) osieroconej wersji 4, sponsorowany m.in. przez Alfresco, z udziałem innych dużych graczy (jak np. SpringSource) jest faktczną kontynacją jBPM4.4. Nikt się zresztą z tym nie kryje, nawet numer pierwszej wersji Activiti to 5. Podobnie jak jBPM5 wspierany jest przez aktywną społeczność, wynikiem którego jest znaczne wyprzedzenie planów i zaskakująco szybki rozwój.
A po co mi to wszystko? Ano kiedyś już sobie myślałem, że w wielu przypadkach część prac związanych z wytworzeniem oprogramowania można przerzucić na tzw. parametryzację, wdrożenie, czy jak tam to sobie ktoś chce nazwać. I nie chodzi mi tu o rozwiązania, z którymi najbardziej kojarzy się proces biznesowy oraz wszystkie diagramy krążące po sieci. Chodzi o proste automaty, których uruchomienie ma na celu wykonanie szeregu czynności. Zakończenie przetwarzania oznacza koniec procesu. Możliwość wstrzymania zadania, przypisania do jakiejś grupy/osoby i inne "biznesowe czynności" to tylko dodatki (przydatne, owszem, ale nie są niezbędne). To, co natomiast jest istotne, to możliwość integracji automatu z własnym kodem (w moim przypadku javą i skryptami wykonywanymi przez maszynkę procesową).
Dla jasności - daleki jestem od stwierzdzenia, że można zrobić silnik, a potem wdrażać to wszędzie i każdemu poprzez prostą podmianę parametrów. To się nie uda. No, chyba, że mowa o prostych systemach (klasyczny przykład pizzerii), gdzie czas przetwarzania nie ma większego znaczenia. W systemach klasy enterprise - to się nie sprawdzi. Ale możemy zdefiniować wspólne elementy, które przy odpowiedniej granulacji mogą być ustawione w różny sposób i rozmaicie konfigurowane. I właśnie do tego świetnie się nada taki automat.
Sama maszyna robiąca wyliczenia jedyne co by robiła, to uruchamiałaby proces, który po prostu się zmieni. A cała reszta - pozostanie bez zmian. Poza testami samego procesu zbędne stają się retesty całego systemu, przestoje, redeploy i cały cykl wgrywania nowej wersji. Pomijam ewentualną samodzielność Klienta, bo nie zawsze jest to celem (i z reguły wcale to nie jest priorytet...)
Ale wracając do tematu... ponieważ z kilku źródeł napierała na mnie coraz większa potrzeba zaznajomienia się z tymi rozwiązaniami poświęciłem ostatnio trochę czasu na bliższe przyjrzenie się co i jak można zrobić. Przynajmniej do tego, co ja potrzebuję.
Zacząłem od jBPM'a wersji 3, ale szybko przeskoczyłem na 4-kę, dokładniej jBPM 4.4. Ta przypadła mi całkiem do gustu, dokumentacja jest niezła, szybko dało się uruchomić próbne procesy. W zasadzie mógłbym przestać szukać, ale jedna rzecz nie dawała mi spokoju - wersja 4 nie będzie miała żadnego wsparcia, prace nad nią praktycznie się skończyły, a cała para poszła w nową wersję. Zatem bez sensu wchodzić w coś co właściwie przeszło do historii.
Niestety, jak to bywa z produktem w trakcie rozwoju, a tym bardziej przed wydaniem wersji stabilnej, istniejąca dokumentacja nie jest tak bogata jak do 4-ki. Szybko okazało się, że w porównaniu z 4-ką to... mizernie się nadaje do moich potrzeb. A jeżeli się nadaje i już działa tak jakbym chciał, to nie udało mi się tego w skończonym (bynajmniej nie zerowym) czasie znaleźć i uruchomić. Poddałem się. Jednak nie chciałem wracać do świata dinozaurów (znaczy się jBPM4).
I tu przyszła niespodzianka - otóż trafiłem na projekt Activiti. Im więcej o nim czytałem, im bardziej się zagłębiałem, tym bardziej dochodziłem do wniosku, że to jest właściwy kierunek. Posiada wszystko, co potrzebuję (i co najważniejsze, działające), stosuje notację BPMN 2.0 + rozszerzenia (poprzez własny namespace) umożliwiające zrobienie czegoś w prostszy sposób niż w "klasycznym" BPMN 2.0.
Dodatkowo - w przeciwieńswie do jBPM5 - posiada działający edytor z możliwością wysterowania zawartości poszczególonych elementów. Ściślej mówiąc - dla zadań typu script można zdefiniować skrypt, dla zadań serviceTask można podać co ma się wykonać (klasa, wyrażenie). Można podawać i definiować wyrażenia EL. Inaczej mówiac - tak przygotowany diagram nadaje się do faktycznego wykorzystania przez maszynę procesową. I to była ostatnia rzecz, która przeważyła nad moim ostatecznym wyborem. Bez sensu bowiem jest tworzenie diagramu, a potem jego ręczne przerabianie, kodowanie lub poprawianie czy uzupełnianie. A co w przypadku jak będziemy chcieli coś w tym wszystkim zmienić? Nie, nie, to musi być zintegrowane. Jak nie, to już wolę pisać w xml'u.
Podsumowując - jeżeli analizować systemy klasy BPM, które można zaszyć w tworzonym systemie to zapewne oba - jBPM5 oraz Activiti są poważnymi kandydatami. Na dzień dzisiejszy stawiam na Activiti, jednak jak będzie za rok? Tego nikt nie wie. Jeżeli Activiti za rok będzie się rozwijał tak samo prężnie jak teraz to może się okazać, że wykorzystał swoje 5 minut. Należy się też spodziewać, że za rok jBPM5 będzie już posiadał stabilne i poprawione wydania, uzupełnioną dokumentację. Krótko mówiąc, że da się go użyć. Produkcyjnie. Oba produkty czeka jeszcze długa droga, jednak na dzień dzisiejszy to Activiti może się pochwalić udanymi wdrożeniami produkcyjnymi. Zamierzam dołożyć do tego grona kolejne.
Inna rzecz, że za rok, może krócej pojawi się więcej niezależnych narzędzi, w pełni wspierających notację BPMN 2.0 oraz na tyle elastycznych, żeby nie tylko dawało się coś narysować, ale żeby dało się z tego korzystać w zespole biznes + architekci + deweloperzy...
Na koniec kilka linków dla chętnych:
Activiti5
activiti.org - Activiti BPM Platform
Liderzy:
www.jorambarrez.be
processdevelopments.blogspot.com
jBPM i Drools
jBPM
Drools
Inne
jBPM5 vs Activiti5? dumb question?
Business Process Model And Notation (BPMN) 2.0
www.omg.org
Alfresco