Version 3

    This document describes a overall architecture and key features that are considered for jBPM5.  Feedback on anything in this document (or anything that you believe should be in this document but is not) is welcome and highly appreciated.  Let us know what you care about and find most important so we can use that to assign priorities.  It will be used as the basis for creating the jBPM5 roadmap, so now is the time to give your feedback.

     

    jBPM5 will be based on the combined experience of jBPM and Drools Flow.  This consolidation will bring together the benefits of both solutions.

     

    DISCLAIMER: This document does not yet describe the jBPM5 roadmap.  Based on the feedback, features may still be added and/or removed.

     

    Architecture

    The following figure depicts the (planned) architecture of jBPM5.  Each of the components will be explained in more detail below, and key characteristics will be described. (Click on the picture for a larger image)

     

    jBPM5.png

    Figure 1:  jBPM5 architecture

     

     

     

    Core process engine

    A core process (or workflow) engine capable of executing your processes.  The engine will have a strong focus on BPMN2 (as the underlying XML format for storing the process definition).  BPMN2 not only defines a standard on how to graphically represent a business process (like BPMN 1.1), but now also includes execution semantics for the elements defined, and an XML format on how to store (and share) process definitions.  This standardized format will be used as the main process language from now on.  We will attempt to provide a (semi-automatic, user-assisted) migration path from jPDL (3.x) to BPMN2.


    Provides an API for starting or signaling process instances, managing your process instances, etc.  Can be configured and integrated into different contexts.


    Key characteristics:

    • clear API

    • native BPMN2 execution

    • embeddability (from running as a simple Java POJO component inside your application to running as an independent service)

    • based on a Process Virtual Machine (PVM), allowing the definition of multiple process languages on the same process engine

    • other non-functional requirements like persistence (JPA), transactions (JTA, others), performance, etc.

    • clustering

    • event listeners, auditing, history logging

    • process instance migration allows you to upgrade already running process instances to a newer version of the process definition

     

    As an intermediate milestone, we will first try to support the common executable subclass of the BPMN2 specification (which is a subset of all the elements defined in the specification on executable processes, supporting only the most common node types) before supporting the entire BPMN2 specification.

     

     

    Human tasks

    Human tasks are important whenever tasks need to be executed with the interaction of human actors. This can be split into multiple parts:

    • Human Task Service: The back-end service for managing the life cycle of tasks.  The process engine itself is not tied to one specific implementation but allows implementations to be plugged in. By default, an independent implementation based on the WS-HT specification will be provided. This specification describes things like the life cycle (assign, claim, complete, release, etc.) but also includes features like group assignment, escalation, assignment rules, etc.

    • Human Task Console: A web-based application that can be used to look up task lists, fill in task forms, etc.  This console targets end users (that will be executing the tasks in the process).  Continuation of the human task management currently part of the existing BPM console.

    • Form Editor: Support for creating custom task forms (that can be shown when a task needs to be completed).  This editor targets developers and will provide basic assistance for creating (HTML-like) task forms.  While different task form solutions can be integrated, a default one based on xforms (or similar) will be provided.

     

     

    Process Repository

    A (logically) centralized process repository allows you store and manage your processes (and related artefacts).  This also includes a web-based console for managing your processes, targeted to business users.  They can inspect and possibly even dynamically update the processes and build and redeploy the updated knowledge base. Features like artefact categorization, search, collaboration and scenario testing before deployment are supported.  Also includes integration with this repository using Eclipse or file system.  Continuation of the Guvnor repository currently part of the Drools project.

     

     

    BPM console

    A web-based console for managing process instances. This includes features like managing your process instances (starting/stopping), inspecting their state and variables, etc.  This console targets developers (wanting to quickly test their processes) and administrator (managing running processes).  Continuation of the process management currently part of the existing BPM console.

     

     

    Eclipse-based process tooling

    An Eclipse plugin will assist the user in specifying their BPMN2 processes. This plugin includes a graphical editor for specifying your business process as a flow chart (using drag-and-drop and property panels).  This editor targets developers. Therefore, it will also provide additional features like validation, testing, debugging, etc.

     

     

    Web-based process tooling

    A web-based editor for specifying BPMN2 processes.  This editor targets business users. This is a continuation of the collaboration with the Oryx / Signavio team in providing web-based editing of BPMN2 processes.

     

     

    Simulation

    The ability to simulate the execution of your processes.  This for example allows you to (manually our automatically) simulate one path (or alternative paths) through your process, but also measure time and resource utilization of your processes, based on for example history data or statistical input.  This is a continuation of the experimental simulation module currently part of the jBPM3 project.

     

     

    BAM / BI

    This can be split into a number of parts:

    • Report editor: Uses the Eclipse BIRT (Business Intelligence Reporting Tool) plugin to create reports that show the key performance indicators. Its easy to define your own reports yourself, using the predefined data sets containing all process history information, and any other data sources you might want to add yourself.  The Eclipse BIRT framework allows you to define data sets, create reports, include charts, etc.  Continuation of the reporting currently part of the existing BPM console.

    • Reporting console: BIRT reports can be dynamically generated and visualized in a web console.  This console targets business users.  Continuation of the reporting currently part of the existing BPM console.

    • BAM engine: Business Activity Monitoring (BAM) is all about monitoring the execution of your processes in real time and being      able to respond to events immediately.  The BAM engine allows you to combine events from various sources, search for event patterns, generate high-level events, respond to critical situations, etc.  Part of the Service Activity Monitoring (SAM) project.  Based on the Drools Fusion as Complex Event Processing (CEP) engine.

    • BAM console: A BAM console can be used to get a real-time overview of the state of your system.  This includes dashboard overview, graphs, etc.  This web-based console targets business users.  Part of the Service Activity Monitoring (SAM) project.

     

     

    Usability

    Domain-specific processes: The process palette can easily be extended with domain-specific nodes.  This allow users to model their processes using domain-specific concepts that they are more familiar with.

    Installation script: simplifies installing the engine, Eclipse plugin, and web tooling, and can be used to quickly generate a demo installation.

    Continuous integration and QA: based on Hudson, just like jBPM and Drools do already

    Documentation

    OSGi

     

     

    Integration

    Integration with various other projects.

    • Drools: Instead of forcing users to define all their business knowledge inside the process (i.e. using a process-oriented approach), we allow users to model their knowledge using a combination of business processes, business rules and event processing. By integrating processes, rules and events, users can select the paradigm that best suits their needs and combine them, taking advantage of the advanced integration of the various paradigms we have provided. This also means that users only have to learn one unified solution, as the tooling provides seamless integration, regardless of whether you are using processes, rules or event processing.  As a result, you will see a shift from a process-oriented to a more knowledge-oriented approach (including API, tooling, etc.)

    • Authentication / Authorization: A security module with configurable access permissions is required to offer varying levels of access to the system.  This requires integration with existing authentication and authorization services (e.g. PicketLink)

    • Seam: Using processes to control the flow of your web application

    • JBoss ESB: The process engine could be deployed as a service on the JBoss Enterprise Service Bus (ESB). This allows the process engine to act as an orchestration engine between the different services that are accessible through the service bus.

    • JOPR: support for the JMX standard to enable process definition and runtime monitoring and inspection using any JMX console

     

    We would like to welcome any feedback feedback on this proposal, using  the jbpm-dev@lists.jboss.org mailing list, or in private by sending your comments to your JBoss contact. If you want to subscribe to the jbpm-dev mailing list or browse the archive, use:

     

         http://lists.jboss.org/mailman/listinfo/jbpm-dev