[jbpm-dev] jbpm 5 feedback

[Salaboy]

I was thinking about a noSql support, and it will be really nice to  
have.
In the other hand JPA is an standard that allows different  
implementations, so if we can find a JPA implementation with a noSQL  
provider will be great!

- Ing. Mauricio Salatino -

On May 12, 2010, at 4:00, Andrea Zoppello <zoppello at tiscali.it> wrote:

> 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
>>
>>
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev