Re: [jbpm-dev] jbpm 5 feedback

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(a)tiscali.it&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbpm-dev >> >> > > _______________________________________________ > jbpm-dev mailing list > jbpm-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbpm-dev _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev