[jbpm-dev] jbpm 5 feedback

[Andrea Zoppello]

Hi all,

I'm a jpm 3.X version and i want ( if possible )  give my two cents 
about what
i would like to expect from JBPM Release 5.

>From  functional point of view:

1) Support for BPMN2 executable model.

 From technical point of view i'd like these features:

1) Ability to use JPM within an OSGi container, so i would like to have 
bundles for engine
and to have jbpm services exposed as OSGi services.

2) A better separation between the engine and the persistence layer. In 
my opinion the
jbpm3.X code is too much coupled with hibernate, i'd really like to have 
a separation to be able
for example to use JPA or ( for example a NoSQL database ) for persistence.


Any thoughts??

Andrea

Il 11/05/2010 10:52, Wim Geeraerts ha scritto:
> 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?
>   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
>   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.
>
> HUMAN TASK
> good that is is based on a standard
> Will  this be offered as a POJO instead of 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.
>
> 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.
> 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.
> 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).
>
> 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.
> 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.
> JOPR =>  is there also an integration with RHQ?
>
> Kind Regards,
>
> Olivier Debels, Wim Geeraerts, Roel Adriaensens  ( Agfa HealthCare)
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
>