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.

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

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(a)gmail.com&gt; 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(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 >

Hello Andrea! Am 12.05.2010 10:00, schrieb 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. > jBPM 3.x itself speaking? I feel honored. ;)

> 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. > This is something Tom has been aiming for with jBPM 4.x as well. I think it's a good thing but it does not have that much priority in my eyes but maybe it's good to keep this in mind to ease a later implementation. > 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. >

I partly agree. In the future jBPM should be more independent of the underlying database layer and I think JPA is the way to go. But IMHO extending this to document-oriented databases is not possible and does not make any sense. Document-oriented databases serve a speecial purpose: serving documents which are schema-free and being able to retrieve them very quickly. When it comes to jBPM or a process engine in general you don't work schema-free but you have a big amount of homogeneous data to deal with: process instances, task lists etc. Regards Sebastian

Hi All, First off all thank you comments here some further clarifications / response: 1) OSGi... i think that this is a prirority... there's a lot of interest around it and a lot of companies are moving towards OSGi powered applications. BTW with regards to jbpm it could be  not only a JBPM problems but also on it's dependencies..

2) About the persistence layer i perfectly agree tha JPA is the right choice but what i really would like to see is the layer implementing the engine core to be separated from the persistence one.

3) Regard NoSQL i think that in some situations it could fit very well ( for example grid system as salaboy suggested ). I'm not suggesting to drop the realtional persistence layer but to support also other based on NoSQL.

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.