AnsweredAssumed Answered

BPM System Arquiteture Questions

Question asked by louzadod on Nov 8, 2010
Latest reply on Jul 25, 2014 by jkronegg
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

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

  - several ProcessEngines –> higher memory footprint

  - 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

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

  - 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)

  - 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.

- 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

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

- 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?