strategy we used was this:
* in api we only use String getId()
* in db we only use long DBID_
* in java, property id (String) might be composed in several ways. sometimes it's formed by translating the dbid(long) into string, sometimes the id is a separate field.
but i don't yet see how this prevents you from building your own process language ? can you elaborate on that part ?
also: we're very keen to know about your use case. what other process language are you building on pvm ?
Thanks Tom, you made it clear.
The reason why we had our own engine is that we have our own MDD tool. It is something like Weld (former Seam) but all the code is generated from emf model and one can append code to the parts which we are not able to generate at the moment.. It encompass modeling of business model with constraints, client, rules, processes, reporting, authorization and initialization. It is used on few commercial projects but the process part is just in evaluation. Hope it will be one day open source.
So we have own libraries for e.g. scheduling we use quartz with our own api or for saving/retrieving objects we use DAOs and we want the process engine to use this infrastructure.
We also want that our process definition in emf translates one to one (directly) to the process definition xml.
I haven't read JBPM 4 manual yet. I will read it soon. I was working with JBpm 3.x and then with PVM alpha..
We have one interface used for DAOs which has method "Long getId()" but we changed it now to "Serializable getId()" because of the jBPM. But I think it was the right direction.
What we were not able to do was:
Now we have an Exception flow as in BPMN and it is possible. We have Signal, Conditional and Timer events which can be in the flow to attached to a boundary of an activity.. Maybe cancel region as in YAWL or ad-hoc tasks with preconditions would be better.. Also recursive tasks and multi instance tasks are important. In jBPM there is no problem with them when you do it programmaticaly but we wanted to have this in the language itself.
I would also like if ScopeInstance implements Map. Because when using languages as Wicket property language or MVEL it can work with variables in map directly, if it has getVariable() instead of get() we need for the few classes hack the system, e.g. in Wicket when adding a column to the table one of its parameters is the name of variable, but when tasks are shown you should implement own column.. In Hibernate is a bug when mapping the classes implementing Map, but it can be easily solved..
Thank you for your interest!