[jbpm-dev] jbpm 5 feedback

Wed May 12 16:48:31 EDT 2010

What is the point of using a NoSQL database?
NoSQL is only useful when using a vast amount of data (petabytes). If
you use a reasonable amount of data then the usage of relational
databases is the best option. JPA is a standard, well documented and
widely spread.

On 12 May 2010 15:14, Salaboy <salaboy at gmail.com> wrote:
> 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
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>