Re: [jbpm-dev] jbpm 5 feedback

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 >