BPM System Arquiteture Questions

[louzadod]

BPM System Architecture
———————–

Here in our organization we are thinking about BPM as being the driver for
software development.
We are going to build a kind of business portal application.
Each module will be about a different business area (BA).
We need some level of independence (version control, deployment) among BAs.
But we also need some degree of integration towards a unified portal.

We are trying to align our architecture roadmap to the Activiti's one.

Today we are considering the following architectural models:

1) Separated Process Engine per BA:
- share platform JARs (Spring, Activiti, and their dependencies) in a common classloader
- share a datasource pointing to Activiti schema
- isolate each BA in a standard WAR/JEE file
- instantiate a separaded process engine per BA

pros:
  - solves current Class.forName issues in Activiti for invoking Java Tasks.

cons:
  - several ProcessEngines –> higher memory footprint

questions:
  - is there any consistency problem on instantiating several process engines (state, concurrency, caching)?
  - what's the real memory footprint of a process engine instance? Is it a real problem?

2) Single and shared process engine among all BAs
- isolate each BA in a standard WAR/JEE file
- JavaTasks acessible via Rest API (decoupling)
- Process engine also acessible via Rest API

pros:
  - total decoupling between workflow engine and BA
  - shared process engine –> lower memory footprint

cons:
  - JavaTask and process engine invocation latency is higher due to network/http stack
  - need for more access control points (service task is now exposed by http rest interface)

questions:
  - will Activiti be ready in version 5.0 GA to support such Rest model? If not, when?

3) Possible use of OSGi
- Process Engine started as bundle and acessible to other BAs (OSGi service listeners)
- each BA will be an isolated OSGi bundle.
- Process Engine will be able to find BA specific classes (Java Tasks, for example) using, for example,
  "Eclipse-RegisterBuddy" and "Eclipse-BuddyPolicy" manifest headers.

pros:
- Eliminate the need for restful distribution (java tasks, process engine) –> lower latencies –> less need for access control points
- Possibility to redeploy BAs in production in a robust way –> higher availability

cons:
- higher development complexity due to the osgi model (specially if BA uses other libraries not ready for OSGi)

questions:
- When will Activiti be ready for OSGi?
- Which OSGi version will Activiti follow?
- Will Activiti be compliant with


General Questions
—————–
- In general, considering the scenario exposed in the beginning, which of the three models is the recommended and why?

[jbarrez]

questions:
- is there any consistency problem on instantiating several process engines (state, concurrency, caching)?
- what's the real memory footprint of a process engine instance? Is it a real problem?

No consistency problems. Activiti was designed to cope exactly with such requirements.
However as you state;, you would have ofc a higher memory footprint. We didnt measure yet, but I'm sure it is not high at all.

will Activiti be ready in version 5.0 GA to support such Rest model? If not, when?

No, we won't have out of the box support for REST.
However, it should be easy to do in your own implementation of a delegation for the serviceTask.

- When will Activiti be ready for OSGi?
- Which OSGi version will Activiti follow?

Currently; Guillaume from FuseSource is making Activiti OSGI ready.
There should be (experimental) support for it in the 5.0 release.
I've got no clue about the OSGI version, but I saw 'blueprint' passing by several times.

- In general, considering the scenario exposed in the beginning, which of the three models is the recommended and why

I don't have experience with option 3, so I didnt consider it.

Option 2 will give you one centralized place to maintain your BPM engine. Which is the typical BPM approach.
However, this also means that you need to expose all the operations you want, in a remote way. With all the performance consequences ofc.

Option 1 will allow you to customize the engine use in a very specific way for each of your wars.
This makes it a bit more agile and you really are developing in a POJO way.

So it's all a matter of taste actually 😉
But I'm obviously leaning more towards option 1 (but Im biased ;-))

[louzadod]

Joram, thanks a lot for your precious answer.
Considering our current moment, we will go for option #1 and keep the eye open for option #3 (osgi).

[jkronegg]

Using a H2 file database, the ProcessEngine memory footprint is about 4 MB. If you have a lot of ProcessEngine in the same classloader, you may be interested to reduce the memory footprint by sharing MyBatis configuration variables.