Activity for service orchestration

[jorgemoralespou]

Hi,
we have developed long time ago a Service Orchestration Engine on top of jBpm 3.2. As we wanted to be real fast in some modes, we had different kind of engines (transient, persistent, asynchronous, ….). We did not need task or identity services.
This is how our transient engine behaved.

1-Deploy a process in JBoss through a specialized deployer, which parsed the xml process definition and the resulting ProcessDeployment was put into a JBossCache, replicated into a clustered setup of servers.
2-Extend jBPMcontexts to hold custom context information and custom scopes.
3-Extend Variable resolver and related to allow for EL to access this new contexts, to use function in EL.
4-Extend ActionHandlers (using a custom BaseActionHandler) to hook custom functionality around, before or after execution.
5-Use JBossCache replicated for storing variables for interprocess or inter-execution information. (This allow to use composition of non-persisted processes to simulate persisted-process or wait states)
6-Create auto-transition engine, in non-stop mode for nodes (No wait states). Every time a wait state should be done, process is decompossed into more simple non-persistable-processes

This allow us to use system in a Telco environment, performig millions of requests per day, in a clustered environment.

My concerns is, will it be possible to achieve the same with Activity?
In concrete:
- Disablement of services (history, task, identity)
- Plugable process repository (shared memory (infinispan, i.e.), shared database, nosql database, memcached, subversion, or whatever,…)
- Interceptor based creation of behaviours
- Easy way to extend UL

Thanks,

[tombaeyens]

Good description of the use case.   And good to know that. 

Yes, we definitely target the engine to be flexible for these kind of use cases.  Activiti is the next generation of PVM.   Afaict, most of those use cases should already be covered.  There is a chance that we'll actually productize the PVM itself.  Which means that we would pull it in a separate library, extensive docs on all those pluggability points.  But that still has to be decided as that is not on our critical path and a major work.  The more help we get (there is already significant interest in contributing from a lot of parties) the more chances we can actually productize it.

regards, tom.

[jorgemoralespou]

Thanks for your answer.

The thing here is that as I have seen now, and in previous ocassions with the PVM for jBPM 4, it still can suffer a lot of changes, so we (users) can only wait, observe, maybe propose some things, but not rely on actual work for our developments.
My experience in this (not broad) is that PVM probably is well suited to "productice" because we (users again) can produce our own langauges on top of PVM, removing or hidding the parts we don´t want to expose in our use case.

I´ll be keeping an eye on Activiti, and the forums, to try to push you on helping me with my use case  :lol:

Regards

[ccappuccino]

Haha
I think in the final vision, the PVM will be independent in its own Package.
It will be more clear and more flexible; but I know it will be more hard working…….Haha.
Keep forward.