博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

JBPM 后期版本的计划（zz）

Posted on 2009-09-22 20:37  Leshem  阅读(853)  评论(0)  编辑  收藏  举报

创建于: 2008-12-22 上午4:21 作者 Thomas Diesler - 最后修改:  2009-9-14 上午5:20 作者 Joram Barrez

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

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.2 : November 1, 2009

  • Improve binding of classes to processes
    • Related: GPD Problems view: fix unavailable classes
    • Fix need for classes during ant deployment
  • Simplifying the jBPM installation on JBoss
    • Improve documentation of configuration features
  • Review task outcomes
  • Database upgrade support
  • Make Signavio JDK 5 compliant

jBPM 4.3 : January 1, 2010

  • Improving the end-to-end demo
  • Set up QA/CI for controlled optimistic locking scenarios
  • Finish the user defined transaction demarcation to combine domain model updates with jBPM updates
  • Selection of the ideas listed below

jBPM 4.4 : March 1, 2010

  • Selection of the ideas listed below

jBPM 4.5 : May 1, 2010

  • Selection of the ideas listed below

jBPM 4.6 : July 1, 2010

  • Selection of the ideas listed below

jBPM 5

  • Productized BPMN
  • Full software development lifecycle support (see above)

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.

Productization work in progress

  • Integration with JBoss IDM (Jeff Yu is working on this)
  • Process conversion tool (Jim Ma is working on this)
  • Controlled minimal tests for concurrent DB access: SOSE's (Joram Barrez)
  • Designer support for older versions (Koen Aers)  
    • Support for multiple, configurable runtimes
  • ProcessInstance migration in case of new process definition deployment

New productization ideas

  • BPMN web based editor
  • jPDL web based editor
  • BPMN 2.0 eclipse based editorClustering
  • Automated QA for console and/or documentation of manual test procedures
  • Automated QA for designer and/or documentation of manual test procedures
  • jBPM-ESB integration  
    • Locate services through the registry
    • Invoke services without regard to their underlying implementation
    • Support synchronous or asynchronous calls
    • Make invocation layer pluggable so that third-party ESBs can be integrated as well
    • Part of community download ?   
  • SEAM integration  
    • Pageflow
    • Pageflow designer
  • JMS support (and/or JCA inflow support) for asynchronous messaging
  • Putting script code in privileged blocks to allow security mgr to control authorization inside scripts. (Marc Schoenefeld)
  • Possibility: adding BPEL engine to simplify BPM product component matrix for jPDL, BPMN and BPEL.
  • Burr's requirements input
    • ESB and SEAM integration
    • Seam+jBPM+ESB use case - a user who tries to use all 3 technologies  together in a single project, single JVM.
    • Migration strategy
    • Must not be slower then the previous version
    • Works on the DBs, JVMs and OSs that the SOA-P is certified against
    • Other: BAM, BPMN, Richer tooling that supports Business Analysts, Integration with our BPEL solution, etc.

Community ideas

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.