Version 84
Created by thomas.diesler on Dec 22, 2008 4:21 AM. Last modified by krisverlaenen on Apr 16, 2010 12:50 PM.

    WARNING: The jBPM roadmap is currently being revised, so the information below might no longer be completely accurate. For more information about jBPM5, check out

    http://community.jboss.org/wiki/jBPM5RequestforComments

    Introduction

    jBPM is a BPM and workflow engine.  BPM and workflow are fragmented domains.  The long term goals are to unify concepts, make BPM and workflow ubiquitous technology and widen our out leading position.  Without that unification, a BPM solution will always remain a niche product. The Process Virtual Machine is the basis of our unification.  The Process Virtual Machine enables jBPM to run multiple process languages natively on one unified engine.  Secondly, jBPM is embeddable.  It runs in any transactional Java environment.  Adding more convenience for each of these environments is another crucial aspect of our roadmap to obtain mass adoption.

     

    Our roadmap is given direction with the following focus points:

     

    Productization

    This means that we'll focus on anything that is necessary to make jBPM a good component in the JBoss products.

    • Explicit identified supported configurations, clear API.
    • CI with good coverage and easy reproducability
    • Provide installer that JBoss products can use to install jBPM into JBoss product
    • Provide proper integrations with other components in the JBoss products
      • S*****
      • Guvnor
      • JOPR
      • Drools
    • Business Intelligence (BI)
    • Business Activity Monitoring (BAM)

    Simplify getting started

    Lower the treshold for people to get started with jBPM.

    • Scripts for setting up the evaluation demo setup
    • Scripts for generating configs, installation in JBoss and jBPM-enabled webapps
    • Based on a few configuration parameters
    • Support is based on the configurations that can be generated

    Improve operational convenience

    jBPM is already known for coping with high demand environments.  But it usually requires a lot of skills of the development team using jBPM to set it up properly.  In that area we want to increase the convenience that we offer.  And by offering more convenience for operational support, we also lower the treshold for people to get and keep jBPM up and running.  We'll focus on offering a more complete set of convenience features for managing a jBPM installation when put into production.

    • Explicit controlled testing for concurrent thread access leading to optimistic locking exceptions.
    • Job management.  Allow for retry of jobs that are blocked due to recurring exceptions (like DLQ).
    • Keeping the runtime process state database healthy
    • Archiving history
    • DB migration between 4.x releases

    QA

    jBPM 4 now offers a service based API.  The same API can be leveraged in various kind of environments.  For example

    • Transactions demarcated on a user defined EJB method in JBoss spanning multiple jBPM operations and user domain model updates
    • jBPM being invoked from a webapp without a transaction being in progress in JBoss.  In that case the jBPM operation should demarcate the JTA transaction
    • Plain tomcat webapp and a user wants to have a transaction for every jBPM method invocation
    • Plain tomcat webapp and a user wants to combine jBPM updates with domain model updates
    • Remote application client offering the API to execute the jBPM service methods on a remote jBPM server over the EJB remote command service

     

    First, our documentation should clearly indicate which of those environments are supported and which are bleeding-edge-use-at-your-own-risk.

    Secondly for each environment that we support, our continuous integration should include a job that executes the full functional test suite in that environment.

    Thirdly, the continuous integration driver scripts should leverage as much as possible the installation scripts that we offer to our users for these environments.

     

    The structure and majority of this continuous integration infrastructure is already set up.  But it will probably take a couple more releases before we have identified the exact environments that we'll support and streamlined with the installation functionality that we expose to our users.

    BPMN 2

    Standard compliant native BPMN 2 runtime engine.

    • Process Execution Conformance (first priority)
    • Process Modeling Conformance (second priority)
    • Signavio web based process modeller
    • Web based monitoring console

    • Leveraging the PVM robustness, API, QA and implementation features

    jPDL

    jPDL is the language for BPM, workflow and transactional control flow in Java.  With jBPM, it's always possible to code your own activity behaviour.  But we want to expand on the out-of-the-box experience.  Adding more direct support for control flow activities and functional activities.

    • foreach activity
    • add ejb invocation to java activity
    • jms send activity
    • jms receiver?
    • email receiver so that users can perform tasks by replaying to a workflow mail
    • ejb3 variable support

    Adoption

     

    Another focus point is increasing our adoption further to become the de facto standard for workflow and BPM in Java.  To go to the next level of adoption, we need to lower the treshold to start using jBPM by simplifing embeddabilit.

    • Tomcat support (supported, userguide)   
      • tomcat wide installation
      • generate skeleton tomcat-ready .war with jBPM inside
    • Spring support   
      • cfg generator tool?
    • war, ear support (unsupported, devguide)   
      • ant scripts or just docs ?
    • SEAM support
    • OSGi support
    • GAE support

    Provide for jPDL to BPMN2 transformation

    An effort is being started to provide for a migration path between jPDL to BPMN2. The initial efforts will to be providing for a tool that will transform existing jPDL definitions to BPMN2 process definitions. This is the first step on the road to migration of jBPM v3.2.x processes onto jBPM v4.x.

    Full software development lifecycle support

    A new focus is to embed executable business processes into the larger context of software development.  Instead of focussing just on the developer world, we'll expand to the collaboration with the business analyst.  While many BPM products claim to be targetted towards non technical business analysts, their approach is unrealistic and doesn't work in practice.  We have a clear idea about how tool support should look like to get a very effective collaboration between business people, technical developers and operational people.  JBoss is launching a number of initiatives in this area.  We'll be collaborating with those teams to embed jBPM where applicable and expand those ideas where necessary.

    Releases

    • jBPM 4.4 : March 1, 2010
    • jBPM 4.5 : May 1, 2010
    • jBPM 4.6 : July 1, 2010
    • jBPM 5

    Concrete feature ideas

    This section contains the high level overview of features for jBPM that we use to analyse high level goals and prioritize our next releases.  This list is inspired based on feedback and requests from the community.  The concrete roadmap is distilled in JIRA and JIRA remains the reference.

    High importance

    • jBPM-ESB integration   
      • esb activity
      • Locate services through the registry
      • Invoke services without regard to their underlying implementation
      • Support synchronous or asynchronous calls
    • SEAM integration 
      • UEL integration (CDI style)
    • Finish jms activity / jms receive activity

    Normal importance

    • Controlled minimal tests for concurrent DB access: SOSE's (Joram Barrez)
    • Putting script code in privileged blocks to allow security mgr to control authorization inside scripts. (Marc Schoenefeld)
    • foreach: https://jira.jboss.org/jira/browse/JBPM-2414
    • Exposing all history information through public API: https://jira.jboss.org/jira/browse/JBPM-2398
      Authentication (related to 'User provided transactional resources'), so that audit logs can point out who did what: https://jira.jboss.org/jira/browse/JBPM-2417
      Ensure proper task form values are properly stored in history for audit purposes : https://jira.jboss.org/jira/browse/JBPM-2416
    • Declare process variables : https://jira.jboss.org/jira/browse/JBPM-2415
    • Transient variables ?
    • jPDL Exception handlers
    • Web service or rest interface to jBPM service operations (expose, review and document existing console rest interface ?)
    • jBPM Statistics    
      • Avg duration of jBPM command executions (~= transaction duration)
      • Time spend in jBPM itself (exclude user code)
      • #TX committed / #TX rolled back
      • Consider exposing these statistics to be exposed in JOPR/JON
    • Email receiver   
      • Allow task forms to be processed by a mail receiver
      • That way users can get tasks as email. 
      • When they reply to it, the mail is parsed and the values are extracted and the task can be completed
    • Process debugging. (Maybe the process debugging infrastructure can be leveraged for the controlled concurrency testing)

     

    Low importance

    • productize group activity: https://jira.jboss.org/jira/browse/JBPM-2413
    • Improve coverage in automated QA for transactional tests and optimistic locking tests
    • Automated QA for Clustering
    • Automated QA for load testing
    • Automated QA for console and/or documentation of manual test procedures
    • Automated QA for designer and/or documentation of manual test procedures
    • JMS support (and/or JCA inflow support) for asynchronous messaging
    • document parameters in installation scripts : https://jira.jboss.org/jira/browse/JBPM-2523

    • extract hibernate reference from jbpm.default.cfg.xml https://jira.jboss.org/jira/browse/JBPM-2524

    • business calendar pluggability: https://jira.jboss.org/jira/browse/JBPM-2334
    • User provided resources   
      • transaction scope    
        • hibernate session
        • jdbc connection
        • authenticated user
      • process engine scope   
        • session factory
    • Async service methods   
      • A global async command service that can be configured so that every invocation is asynchronous
      • Default synchronous + programmatic specification of async for the next invocation.  E.g.
        • processEngine.executeNextMethodAsync();
        • processEngine.getExecutionService().startProcessInstanceByKey("ICL");
    • Google App Engine support   
      • JPA persistence?
      • Threads?
    • make task forms i18n-able: https://jira.jboss.org/jira/browse/JBPM-2405
    • JMS binding for asynchronous messaging   
      • Identify which JMS implementations we target
      • Learn which JMS impl configuration properties interact with our job execution algorithm (like retries and duplicate delivery)
      • Build out generic job executor test suite so that it can be leveraged for all impl (job executor, different jms implementations)
      • Make sure that JMS can be configured for async messaging and keep job executor for handling the timers.
    • JPA integration   
      • JPA entities as process variables
      • transaction integration
    • Programmatic API to build process definitions (ProcessDefinitionBuilder)

    • Build out execution modes: http://www.jboss.org/community/wiki/jBPM4ExecutionModes

    • http://www.jboss.org/community/wiki/GWTConsoleFeatureSet
    • Authorization   
        • Who's allowed to start a process instance
      • Record end-to-end demo, meaning starting to develop a process in the designer, deploying to the runtime engine and showing the console to execute a process instance
      • OSGi-ification of jBPM
        • Improve the standalone task usability by adding audit history and treating it everywhere like a task from a process.

        jBPM 5

        jBPM 5 stability guarantees:

        • jBPM API updates will be kept to a minimal.  Methods that will be removed in jBPM 5 API should be marked as deprecated in the last 2 jBPM 4 releases.
        • All jPDL 4 will keep running on jBPM 4
        • Automatic upgrade of the jBPM DB will be provided from 4.x to jBPM 5

         

        This section collects improvements and ideas that might impact backwards compatibility and that therefor we can only address in jBPM 5.

        • Productize BPMN
        • Split ExecutionService into JpdlService and BpmnService.  Move signal operation from ExecutionService to a JpdlService. 
        • Document, clarify and harmonize lifecycle for process definition, process instance, execution and task.  It should be clear when we talk about finished processes what that exactly means.

        jBPM Release Procedure

         

        Starting with jbpm-3.3.0.GA we will have a release cycle of eight weeks per minor release. The motivation is to improve the predictability of jbpm releases. To make this work, we follow the following rules:

         

        -------------------------------------
W1
W2 Define set of JIRA issues 
--Jira freeze------------------------
W3 Work on issues
W4 Work on issues
W5 Work on issues
W6 Work on issues
W7 Integration week
--Code freeze------------------------
W8 Release
--Release----------------------------

         

        Jira Freeze means that the complete set of issues for the upcomming release cycle is defined and that there are no more  unassigned issues. This ensures that

        1. everybody in the team knows what to do over the next couple of weeks
        2. consumers of the project know what to expect
        3. the release can be on time and in scope

         

        After Jira freeze, no-one can expect new issues to be prioritized for that release.

         

        Before integration week (W7) command 'mvn clean install' should run fine before checking in any code chagnes.

         

        Integration week means that before all commits, the full integration test suite is executed successfully.  Also developers should organise their work so that in this last week no major changes are committed.  This ensures that regression of the integration test suites is kept to a minimum.  And that at code freeze, the integration test suites are in good shape.

         

        Code Freeze means that all issues must be resolved and a QA branch can be created.

        Changes to the code should only address regression that shows up during the QA periode.

         

        Release Date means that the project will be released on that date.

        The criteria is that the project passes the QA matrix as it currently stands and that there are no more unresolved issues.

        28725 Views Categories: Tags: