Re: [jbpm-dev] jbpm 5 feedback

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