[jbpm-dev] jbpm 5 feedback

[Kris Verlaenen]

Feedback inlined !

Wim Geeraerts wrote:
> This is the feedback we have at this point:
>
> CORE PROCESS ENGINE
> The time line will be very important for us: which BPMN2 nodes will be
> implemented first?
>   
We're currently looking at supporting the "common executable" subclass 
first.  This is one of the conformance classes that has recently been 
added to the specification and includes the most common node types for 
describing executable processes.  On top of that, some other already 
existing node types will probably be supported as well.

>  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)
>  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
>   
The engine is built on the PVM concept, so adding custom node 
implementations is possible.  The use case you are describing seems even 
simpler though, as it does not really seem to be a custom node but 
rather a domain-specific node, which will be even easier to plug in.

>  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.
>   
Process instance migration is never automatic.  The default strategy is 
just continue with the old process definition.  If you decide to migrate 
existing instances, we can only provide a fairly simple migration 
strategy (basically map nodes to their existing counterparts in the new 
process), with pluggable strategies for application-specific both data 
and state transformations.

> HUMAN TASK
> good that is is based on a standard
> Will  this be offered as a POJO instead of a webservice?
>   
We want to offer the core engine as a POJO service but provide the WS-HT 
web interface if you want it (the RiftSaw project for example would use 
the WS interface using BPEL).
> Will this be customizable?  (as described above, we want our own
> flavour of tasks to be created)
>   
The human task service is completely pluggable, so you can have your 
custom implementation.  Regarding the customization of the default WS-HT 
service, I suggest you take a look at the WS-HT standard to see whether 
the specification is generic enough to support your use cases.
> Will the task data pattern be implemented?  Having scoped variables is
> important for us.
>   
The task can have input and output / error data associated with it, 
which can be anything you want it to be (translated to byte[] internally 
for storage).
> We need  group assignment / escalation / assignment rules - again this
> should be customizable
>   
These are defined in the spec and we try to follow it as close as possible.
> 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.
>   

> 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?
The repository contains both your processes and your rules, so they are part
of the same knowledge set.  At any time, you can see which processes and 
rules
(and associated domain model) are currently used.
> 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).
Yes, we don't recommend using that, domain-specific nodes allow a 
deploy-time binding
of an abstract task node to an implementation.
>   So we need a better
> way to link the business logic / business rules from within the
> process description and version these.
> Dynamically updating processes - how whill this behave if process
> instances are active at that time?  This is a nice feature but with a
> lower priority.
>   
You're actually not removing the old, you're just adding a new definition.
> Scenario testing before deployment - Does this mean we can test the
> application using the new process definitions before they are
> deployed?  Nice feature but again lower priorty according to us.
>   

> BPM CONSOLE / WEB-BASED PROCESSING TOOL
> It would be beneficial to have the same functionality available via
> EJB.  I.e. it would be nice if the web tools would just be a WS layer
> on top of  a set of EJBs (which we could use to create our own
> integrated tools).
>   
They are currently using a REST interface, it would be possible to 
investigate if
they could be exposed for example as EJBs as well.

> SIMULATION
> Something we would use in a later stadium to allow service engineers
> to adapt processes to optimize usage of resources f.e.  But for us
> this has a lower priority.
>
> BAM/BI
> It would be nice if the data that is used to create the BIRT reports
> on is available, so that we can integrate our own BI solution (Oracle
> BI f.e.) on top of this.
>   
The reports are based on the history log, which is accessible from any 
application
if you want to, and customizable.

> We will use this not only to show statistics but also to do trend
> analysis and report changes in trends, f.e. some data normal for one
> site is abnormal for another site
> So again here according to us it is more important to focus on the
> core (make sure the data is there) and a customizable way to consume
> the data (with BIRT as default implementation)
>   

> INTEGRATION
> authentication / authorization: it must be possible to provide our own
> module here.
>   
That is of course the idea.
> JOPR => is there also an integration with RHQ?
>   
The integration is based on JMX, so I think it supports both.

Thanks for the feedback.

Kris