Is it possible to avoid hibernate?

[jorgemoralespou_2]

Hi,
I want to use jBPM, or even, extend PVM with my customizations to make a simple service orchestration language. All of it, needs to run in memory, with no persistence at all.
First of all, I`m trying to create a Repository to deploy my Deployments, but I see hibernate is needed for PVM.
Can I avoid it using a custom DeploymentImpl and RepositorySessionImpl?

[tom.baeyens]

that is a target. but we'll be only able to bring this to the surface in the mid term

if you're able to compile the code, then look at the test-pojo module.

but that usage is not yet stable. getting the programmatic, non-persistent api stable is going to take more time.

[jorgemoralespou_2]

Is there any kind of design docs. I'm eager to collaborate with this task, but I don't want to work in a diverging direction.

[tom.baeyens]

with the jbpm core, it should be possible to build out all execution modes as described in http://www.jboss.org/community/wiki/jBPM4ExecutionModes

i believe that you are referring to the 'Memory' execution mode, right ?

the direction we're thinking in for that use case is to use the ProcessBuilder to create process definitions. Probably we can leverage the JpdlParser for that as wel. That will immediately give most of jPDL features instead of having to start from an empty PVM. Maybe some dependencies on the environment configuration sneeked in here or there.

Our current idea is to use methods on the objects themselves for the memory execution mode, and skip the services api's

It would be great if you could try that direction and see where you run into problems.

Keep us posted

[jorgemoralespou_2]

What I'm thinking of is, to build my own custom ProcessRepository. This process repository would be held in memory, as I only want latest process definitions to be used. Then I would like to instantiate different ExecutionServices, with different persistent strategies for executions and history (memory, db) to enable asynchronous process executions (persistent mode) and synchronous process execution. (memory execution, and persistent or without history).

I'll try to start with the on memory process repository, trying to hold ProcessDefinitions in Memory. And then, I think Iĺl try to configure an ExecutionService, without history.

Any thoughts?

[tom.baeyens]

implementing the repository service on top of the classpath resources is another option. it's less flexible, but indeed much more achievable. so it is a good path to try out as well.

[camunda]

Tom wrote:

Our current idea is to use methods on the objects themselves for the memory execution mode, and skip the services api's

Woudn't it be much cleaner design if the APi is used as well? And have a in memory implementation which just keeps references of running instances?

But it is not easy to build, I agree...

[jorgemoralespou_2]

I agree with Camunda that an API should be the way. This way you only have to configure the cfg.xml file with services you want, mode you want, implementatiosn for the service, and client code wouldn't need to change much. If you use ExecutionService, this service should be used for any kind of execution. The difference could be to have o not to have a HistoryService, for example.

[tom.baeyens]

yes. that all makees sense.

let's start with trying to get as much as possible of jbpm to run in memory mode through the normal service based api.

still remains to be seen how well the current implementation already supports this strategy.

if all we need is some memory implementations of the some sessions and small patches here and there to head to make this work then i want to include those patches very much. theoretically the design should support it...

[jorgemoralespou_2]

Hi,
I have found that a "last moment change" with the introduction of NewDeployment interface into the api, has left a lot of references to DeploymentImpl where NewDeployment should have been used instead.
Also, I think that it seems that there should be more programming against interfaces, as there is a lot of code where there is no easy way to interchange implementing classes.

[jorgemoralespou_2]

"jorgemoralespou_2" wrote:
Hi,
Also, I think that it seems that there should be more programming against interfaces, as there is a lot of code where there is no easy way to interchange implementing classes.

As an example:

public interface Deployer {

 void deploy(NewDeployment deployment);

}

should be:

public interface Deployer {

 void deploy(DeploymentImpl deployment);

}

[kukeltje]

"jorgemoralespou_2" wrote:
Hi,
I have found that a "last moment change" with the introduction of NewDeployment interface into the api, has left a lot of references to DeploymentImpl where NewDeployment should have been used instead.

I saw your jira issue for this.

[kukeltje]

Oops... something got lost...

Do you have examples of the not programming against interfaces and why you think those classes should be overridable. Preferably in a new topic since it is not directly related to this one.

[tom.baeyens]

The public API is intended to provide guidance and only expose methods for end users. It's not the purpose of that API to support other implementations.

Deployer is not part of the public API. It's an internal interface for our own pluggability.

[jorgemoralespou_2]

I know that Deployer is not part of the public API, and that internal is that "internal", but for the shake of the tsak of making jBPM not depending on hibernate, and trying to have another kind of RepositoryService "a non persisted with hibernate, rather than in memory" I have to cope with creating new classes, and bindings, and this stuff, and I have to create my implementations of some classes, practically the same as the ones in internal, only due to the fact that they are not programmed to allow extendibility.
Maybe I have to do this all by my own, but I think that a little cooperation can e helpfull.
As I said in a previous post, I started by trying to create a new RepositoryService, that hold Deployments in memory (probably a JBossCache in the future). For that I have my MemoryRepositoryService (with its binding in jbpm.user.wire.bindings.xml). I could reuse most of the commands in RepositoryService, but createDeployment has to create a new DeploymentImpl, since the one in the core depends on hibernate (LOB). And from there I have to replicate tons of classes that could have done it if it would have referenced NewDeployment instead of DeploymentImpl.

I know that this tasks (and part of the api) may only be for core developers, but since I wanted to use jBPM4 for what I have been using jBPM3, I wanted to acomplish this task as soon as possible. I've been waiting for this a long time, since jBPM4 was firstly scheduled for months ago, and that make us (in our company) not change the process engine library we were using.

I really think jBPM4 can be a very good software, but looking at its internals made me think that probably it was released before than it should.

Would you mind my comments, or should I go all by myself?

As I said, public API is for clients. I don't think what I`m looking for in here, (right now) is to use it as a client, as it don't fulfill my needs.

Thank you,