First look at Activiti

This week I had to face Activiti - a new workflow engine for Java, and since this topic has not yet been discussed at Habré, I decided to share my impressions. I'll say right away - the impressions are a bit sad, but about this under the cut

A bit of background

jBPM 3

There was a workflow framework for java jBPM . It was a good framework (in principle, it still exists, but why it will become clear later in the past tense). I used it during the development of the first version of EmForge . I liked this framework for several reasons:
* Easy embeddability in the application - as a matter of fact you put the Jar-nick (with dependencies) to yourself - and you have support for configurable processes in the application;
* Understandable API;
* Familiar technology (the same Hibernate);
* As a result of using Hibernate - support a large number of databases;
* "Proximity" to the developer - the processes are drawn in Eclipse, you can immediately write a unit-test that tests the written process;
* The jPDL notation used, although not a standard, was convenient for describing “everyday” processes.

All this together made jBPM very friendly primarily for the developer, while SOA solutions remained a “toy” for “serious” architects - BPEL support in jBPM did not take root, and it looked like something frivolous, “childish” solution - well, to each his own. Nevertheless, jBPM has become (I think I will not be mistaken) the most popular workflow solution for java.
')
In the version with which I started working (jBPM 3), not everything was smooth - there were problems. I would single out:
* Integration with the Spring Framework through the crutches spring-modules;
* Orientation to Hibernate - I would prefer using JPA with the ability to work with different implementations (would improve the possibilities of integration into the developed application);
* The API was inconvenient for implementing “searching” tasks and processes — you had to write your own “direct” sql queries, that is, to crawl into the implementation of jBPM.
* There were certain limitations in the description of the processes.

I had to put up with something, something was done with crutches, something was fixed by my own “add-ons”. In general - it would be logical to expect from the next version of the "improvements" and "fixes"

jBPM 4

However, in the next version - jBPM 4, the developers chose the path of “deep” refactoring. In fact, a new engine was written, with a completely new API and a new database. I do not know how much it was necessary to recycle everything, but nevertheless - in the new version there were certain advantages:
* Native integration with Spring
* A more convenient description of the processes and calls java-code or spring-component;
* API more convenient for search;
* Separate storage in the database runtime data and "history" - in theory should speed up the work.

In general, the new version left a pleasant impression - although not all the functionality that was present in jBPM3 was in jBPM4. Among the shortcomings we can probably relate the old binding with Hibernate - although it is quite possible that this is a political decision - since jBPM was developed “under the wing” jBoss

Activiti

Well, the code was updated, you can also satisfy users - that is, bring the new version to the mind. But it was not there. The main developer of jBPM - Tom Baeyens leaves RedHat (jBoss) and goes to Alfresco
As a result, a new project is being launched, Activiti . The project immediately receives version 5.0 (hinting at the continuation of jBPM) and has now reached stage 5.0.rc1. Of the main changes:
* Hibernate is thrown out - iBatis is used instead (idiot!). As I understand it, the decision is political: using only a component under the Apache license (which I prevented from understanding the LGPL, I don’t understand it imposes licensing restrictions on the final product itself), plus Alfresco switches from Hibernate to iBatis for some reason;
* BPMN2 notation is used instead of jPDL;

I worked with Activiti to implement the integration of Activiti and Liferay . And here are some impressions of the current version (close to release):
* API remained very similar to JBPM 4 - in fact, changed the packages and class names;
* It seems like after long discussions they added support for working with the base through JPA - although this is “experimental” and at your own risk (I haven't tried it yet);
* Other companies joined the project - which promises wider support (although jBPM was also supported by many people);

But, in essence, this is not a step forward - but a step sideways. And it is good if the project goes further - and there will be no next “global” refactoring or re-rendering.

But as minuses we get:
* Significantly narrowed the list of supported databases (due to the refusal of Hibernate in favor of myBatis), plus the type of database is not determined automatically, with the circuit upgrade, there are also some misunderstandings;
* Due to the rejection of jPDL in favor of BPMN2, some convenient features that were in jPDL were lost (for example, several output transitions from tasks). I am for the use of standards, but where it is reasonable. The process described in the Activiti designer cannot be performed anywhere except Activiti, so the standard does not give anything here, and jPDL was (imkho) more convenient for everyday tasks (BPMN is more academic - and in fact is humanized by BPEL). In general, it is clear that here you can argue and argue - but the fact remains - some things that were easily done in jBPM 4 - cannot be done in Activiti;
* The quality of the code seemed to me worse. Just caught my eye - the description of the interface of the service operates not only with the interface of objects (as it was in jBPM 4) - but also with specific implementations. for example, IdentitySession operates not only with User & Group interfaces, but also with their implementations - UserEntity & GroupEntity. For comparison - the same class in jBPM - note the number of javaDoc comments. This is all just trivia in principle - but I get the impression that Activiti is being developed in some haste - which may not have a very good effect on the quality of the code. (By the way - it’s not perfect itself - and I don’t always write comments to javadoc - but the point is that they were in jBPM - but they were not in Activiti)
* New functionality was not strongly discovered (from the point of view of the API and the development of processes) - but a lot of what was in jBPM was “lost”. That is, if you are currently using jBPM 4, then I don’t see any reasons for switching to Activiti.

Why in the end are sad thoughts?

* Instead of a planned, evolutionary development of a good project, we get a series of refactoring-rebranding and “political” jumps, as a result of which the project (IMHO) only loses functionality;
* jBPM is essentially dead. I am skeptical that the project will continue to live after the departure of its main developer, although jBoss is also announcing jBPM 5.0
* At the same time, how Activiti will continue to live is not entirely clear. It is possible that instead of one good engine we get two - but what will they be?

Okay - cry - and that's enough. I hope the information outlined here will help you in choosing a workflow engine for the next project, although I’m honestly won’t lose what choice is right.