Both the Activiti community and our consulting customers are repeatedly asking me about how to run Activiti on IBM WebSphere Application Server. In this blogpost I want to summarize the problems and challenges you face when you want to do that and along the lines give a sneak preview of the upcoming WebSphere support in camunda fox (our enterprise BPM platform based on Activiti).

Let’s start with the challenges.

Transactions

A first challenge is transaction management. When developing a process application with Activiti, you often want the process engine to participate in container transactions. This allows you to implement units of work in which both the process engine and other transactional resources like a database, a message queue or EJB’s participate. The Java EE Solution to this problem is JTA, a specification which defines multi-resource transactions. Activiti integrates with JTA out of the box, if you configure the JtaTransactionInterceptor. This makes sure, that whenever you run a command (do something in Activiti, like completing a user task), we either start a new transaction or participate in the currently active transaction. The desired behavior is that if you invoke Activiti form an EJB Session Bean, it will take part in the transaction managed by the Session Bean / EJB Container. The same is also true in the opposite direction: lets say you call an EJB from an asynchronous service task, in that case Activiti will open a transaction when executing the service task and the EJB has the possibility to participate in that transaction. Why is this so helpful? As I said before it gives us the possibility to implement units of work in which both Activiti and the EJB Container take part and by the means of transactions ensure consistency: if Activiti fails, the EJB fails and vice-versa (remember ACID transactions?).

Now, why is this challenging on WebSphere? WebSphere Application Server does not provide a standard JTA javax.transaction.TransactionManager (like for instance JBoss AS or Glassfish), but instead exposes a proprietary interface named com.ibm.wsspi.uow.UOWManager. IBM is allowed to do so, as the Java EE / EJB specification does not require vendors to provide a JTA TransactionManager implementation. All they are required doing is providing a javax.transaction.UserTransaction (which Websphere does). The UserTransaction interface would allow Activiti to open new transactions and participate in existing transactions; however that is not enough for Activiti to function correctly. For some commands (for example when decrementing retries after a failed job) we need REQUIRES_NEW semantics for executing the command. This means we need to suspend the current transaction and start a new transaction. Now the javax.transaction.UserTransaction interface does not provide such functionality, which means that you need to use proprietary IBM API for achieving this. This is one reason among (others) why running Activiti on WebSphere application server requires you to solve the transaction problem. One possibility would be to use Spring’s org.springframework.transaction.jta.JtaTransactionManager abstraction and configure the SpringTransactionInterceptor in Activiti.

Performing Background Work

A process engine like Activiti uses the calling thread for performing most of its work. This is a natural consequence from the requirement to share transactions between Activiti and the application code, as transactions are thread-bound. This means that, when you call Activiti, the call will block until Activiti has performed its work. But there are also certain situations where Activiti will call you. For example if you have a timer in the process, Activiti will wait for the timer to reach its due date and then continue with executing the process. Hence Activiti performs some kind of background work, where it checks if it has work to do (the concept is called “Jobs”) and if so, it will perform this work. To make this happen Activiti needs to manage its own threads.

Now, in a managed environment like an applications server, you do not want to manage the threads yourself, instead you want the container to manage them (more exactly: it is even forbidden by the Java EE Specification). This is for various reasons like for instance to allow the container to perform additional “magic”, like monitoring the threads, detecting deadlocks, ensure that work submitted by an application is canceled when the application is undeployed, that threads requested by an application are stopped if the application is undeployed and so on. Most of this is to ensure that “everything is under control” and to ensure the overall stability of your application and server environment. Another important feature is ensuring that work submitted by an application is executed within the correct security / naming / transaction context.

When running Activiti on WebSphere, the main challenge is having the JobExecutor (this is the component which performs the background work) delegate to supported, container-managed threads. On WebSphere this means delegating to an asynchronous beans WorkManager. There are multiple interfaces to the WorkManager; one of them is commonj.work.WorkManager, another one com.ibm.websphere.asynchbeans.WorkManager. Using the WorkManager for Activiti background work was a problem until recently, as the activiti JobExecutor always started its own Threads and it was not easy to configure it. Recently we have done a number of refactorings in which we separated the JobExecutor logic from the thread management, such that it is now easier to implement a JobExecutor delegating to a Websphere WorkManager (watch out for Activiti 5.9).

Ok, so if we know all this, why is there no Activiti distribution for WebSphere you can just download?

Why is WebSphere Support not pre-built in Activiti?

The reason is that it is not only a technical problem. Activiti aims at being a highly configurable and embeddable engine. This means that conceptually it possible to integrate Activiti with whatever Java-based environment you come up with. This is a good thing! However, that also poses some challenges. One challenge is knowing where to stop. Take for instance WebShere Support: let’s say we add WebSphere support classes to Activiti. Now the main problem is to test and to maintain it. This includes automated testing and quality assurance, preferably on different versions of the application server, different Java Runtimes (e.g. the IBM JDK) and so on. That kind of effort is impossible for us to do in the context of an open source project, especially as WebSphere is not the only application server out there. This is why we focus on delivering a high quality embeddable process engine in the Activiti project, get that right and do not assume responsibility for integration with various platforms and vendors. Because, as I said before: even if we made that promise, it is hard for an open source project to deliver on it. And don’t forget: Somebody has to pay my salary

One way out for you by the way could be the Spring Framework which already contains abstractions for many vendor-specific technologies like transactions and threading. So by providing first-class integration with the Spring Framework, we give users of Activiti the possibility to integrate with various vendors more easily, but it still means you have to do some integration work yourself and especially take the responsibility for the integration and maintenance of it yourself.

Support in camunda fox

In the camunda fox enterprise bpm platform we provide pre-built integration with IBM WebSphere Application Server 8. We do perform automated testing, quality assurance and maintenance and we offer professional support. This is one of some differences between Activiti open source and camunda fox enterprise.

While this is no “official” announcement about the camunda fox platform for websphere, I cannot stop myself from giving you a sneak preview about what you can expect in terms of functionally. You must have already gathered some of it form this blog (I know, it’s long again…): we support container managed transactions and container managed threads for background work. In addition, we support a central process engine service which can be shared by all applications installed on the application server. That also means that it allows you to align the container deployment lifecycle with process deployment lifecycle, i.e. when you deploy a WAR file (application) which contains processes, the processes are automatically deployed to the central process engine service. This is includes some class-loading magic as well. But more on this at a later point in time. So for the moment, enjoy the following screen-shots:

Process Engine Configuration using the WAS web console

Configuration of the WAS WorkManager used by the JobExecutor