Hello Wim!
Thank you for your feedback. I'm happy to see quite a lot of people
commenting on the jBPM5 proposal.
CORE PROCESS ENGINE
The time line will be very important for us: which BPMN2 nodes will be
implemented first?
It would be great if we have a number of core nodes in a first phase
and the ability to customize these (both by configuring the core nodes
and by adding custom nodes)
I agreed that customization is an important point. Which nodes are going
to be implemetend first needs to be discussed but I think it is quite
clear that we should start with user tasks and one variant of the
service task as well as with the gateways to be able to control the flow
in the process.
Customization of nodes is key to us, f.e. we want to be able to
define our own task created within a task node with custom attributes
and with links to our domain data
Please see above.
process instance migration is something we don't want to
happen
always. In some situations we want our old process instances to use
old process definitions. Furthermore process instance migration must
be extensible since some of the constraints are application specific.
Jbpm 5 can only provide a good default implementation.
This is an important point and I agree that his needs more flexibility.
HUMAN TASK
good that is is based on a standard
Will this be offered as a POJO instead of a webservice?
I want to see this plugable and as a POJO-component which could be
replaced or extented by a webservice.
Will this be customizable? (as described above, we want our own
flavour of tasks to be created)
Will the task data pattern be implemented? Having scoped variables is
important for us.
We need group assignment / escalation / assignment rules - again this
should be customizable
Human task console / from editor is something which has less
priority
according to us. If the core is there these tools can be created on
top of that afterwards.
Agreed. I agree that this can be created afterwards and I think it is
quite common to realize the task management functionality in your own
application.
PROCESS REPOSITORY
Versioning of processes is a must. Also think about how attached
business logic or rules will be versioned. What is the link between
process version and business rule version? . Furthermore if old
process instances refer to business logic using class names (as in
jbpm3 f.e.), they will no longer work if the business code is
refactored (i.e. the class names are changed). So we need a better
way to link the business logic / business rules from within the
process description and version these.
This has to be carefully thought and is indeed an issue. My first idea
would be to have a seperate jar-file with the right classes for each
version and an own classloader context for each process version. But
this is just an idea.
Best regards
Sebastian
--
Sebastian Schneider
e-mail: Sebastian.Schneider(a)alumni.fh-aachen.de