Version 14
Created by tom.baeyens on Aug 27, 2009 10:17 AM. Last modified by jbarrez on Jan 5, 2010 4:25 PM.

    Goal of this document

     

    * scrapbook (ideas, braindumps, etc) for releases of BPMN2 implementation on top of jBPM PVM

    * community input + core developers --> wiki -> refinement -> documentation

     

    History and goal

    The jBPM BPMN2 implementation was started in close collaboration with the community in augustus 2009 after releasing jBPM 4.0.

    Later, it was decided that the first release (ie documented/QA'd) to incorporate parts of the BPMN2 spec would be jBPM 4.3.

    The goal of this effort is to build a native BPMN2 runtime engine (or better said implementing 'BPMN2 exectuable') leveraging the Process Virtual Machine (PVM).

    Do note that the primary focus of this release is native executability, not the graphical notation - but we recognize its importance for further releases.

     

    Team


    • Joram Barrez: Leading the BPMN2 initiative. Responsible for the overall implementation while also focussing on the 'business side' of things (eg Signavio web based editor)
    • Alejandro Guizar: Responsible for the implementation of the (web) service related aspects of the BPMN2 spec, leveraging his BPEL expertise.
    • Koen Aers: Focussing on the eclipse based BPMN editor and BPMN2 implementation in general.
    • Bernd Ruecker: Mentor and initiatior of the BPMN2 initiative. Bernd is also an OMG BPMN2 spec committee member. He is the CEO of Camunda, a consulting company specialized in BPM projects.  Bernd is an active contributor of jBPM and already contributed significant pieces to jBPM, such as the simulation capabilities of jBPM 3. 
    • Ronald "kukeltje" van Kuijk: Donated the initial proof of concept implementation (based on preliminary work by Bernd for his BPMN book) of the BPMN language on top of the jBPM PVM.  Ronald is a consultant and brings years of experience from the business side of BPM, combined with an in depth technical knowledge of jBPM.

     

    Sources

    Check out wiki page jBPM4 Building from Source to see how to build the jBPM sources.  The BPMN2 implementation is a sub-module of the jBPM project (see module/bpmn). Testcases for the BPMN2 module are located in the test-db module, combined with the jPDL testcases. The reason for this is that both rely on the PVM and the full QA process is made easier by this instead of having the testclasses in the respective module.

     

     

    What is BPMN2

     

    The Business Process Modeling Notation (BPMN) is a standard for a graphical notation of business processes models. The standard is maitained by the Object Management Group (OMG).

    Basically, the BPMN spec defines how a task must look like, which constructs can be connected to each other, etc. in a meaning that cannot be misinterpreted.

     

    Earlier versions of the standard (<= version 1.2) are limited to the modeling only, aiming at a common understanding between all stakeholders involved in documenting, discussing and implementing business processes. The BPMN standard has proven itself, as many modeling tools on the market today use the symbols and constructs specified in the BPMN standard. In fact, the current JPDL designer also uses BPMN symbols.

     

    Version 2.0 of the BPMN specification, which is currently in beta phase and is scheduled to be finalized in June 2010, allows to add precise technical details to the shapes and symbols available in BPMN and at the same time specify what the execution semantics of BPMN 'elements' are. By using an XML language to specify the executable semantics of a business process, the BPMN specification has evolved into a language for business processes that can be executed on any BPMN2 compliant process engine - while still having the powerful graphical notations.

     

     

    JPDL vs BPMN

     

    One of the first questions that might, rightfully, come to mind is why BPMN2 is being implemented while there is jPDL. Both are languages that have as goal to define executable business processes. From a high-level technical point of view, both languages are equivalent. The main distinction is that BPMN2 is as vendor-neutral as you can have with standards, while JPDL has always been tied to jBPM (although some might argue that a vendor lock-in for an open-source process language such as JPDL is less a lock-in than with closed-source products).

    Within jBPM, both language implementations are built on top of the jBPM Process Virtual Machine (PVM). This means that both languages share a common foundation (persistence, transactions, configuration, but also basic process constructs, etc.). As a result, optimizations to the core of jBPM often benefits both languages. Leveraging the PVM, the BPMN2 implementation is built upon a foundation that has already proven itself in the past and has a large end-user community.

     

    When evaluating the languages and comparing them which each other however, following points must be taken into consideration:

     

    • BPMN2 is based on a standard accepted by the BPM industry.
    • BPMN2 is implementation-unaware. The downside of this is that integrating with Java technology will always be easier with JPDL. So, from a Java developer's perspective JPDL is simpler and feels more natural (some of the 'layers' of BPEL/WSDL are in BPMN as well)
    • A focus of JPDL is XML readability. BPMN2 processes will still be readable to a certain level, but tooling or a more detailed knowledge of the spec will definitely be required to achieve the same level of productivity.
    • Java developers who are super-fast in JPDL since they know the JPDL language by heart, will find the use of tools sometimes bothersome and the language itself overly complicated.
    • BPMN2 contains a large set of constructs described in the specification. However, the "binding" of interfaces to code is left open in the spec (comparable with XPDL), even is WDSL is considered the default. This means that a process portability can be lost when porting the process to an engine that doesn't support the same binding mechanism. Calling Java classes for example is already going to be such a jBPM specific binding.

     

    It is natural to the political level of BPMN2 specification process to go rather slow. JPDL on the other hand will be able to incorporate changes faster, integrate with new technologies when they are released and evolve generally at a quicker pace compared to BPMN2.

    Of course, since both are built on top of the same PVM, it is only logical that additions to JPDL can be ported to BPMN2 as an extension without much hassle.

     

    Getting started

    goal: describe the steps to set up the demo setup for a bpmn2 process. For a first iteration it is sufficient to have the BPMN2 process deployed as an example in the demo.setup.xxxx scripts.

    See https://jira.jboss.org/jira/browse/JBPM-2675

    Basic BPMN2 process example

    goal: describe steps to create a 'hello world' BPMN2 process (such as http://www.jorambarrez.be/blog/2009/07/01/jbpm4-hello-world/ )


    See https://jira.jboss.org/jira/browse/JBPM-2660


    BPMN2 constructs


    The BPMN2 specification defines a very rich language for modeling and executing business processes. However, this also means that it is quite hard to get an overview of what's possible with BPMN2. To simplify this situation, we've decided to categorize the BPMN2 constructs into three 'levels'. The separation itself is primarily based on the book 'BPMN method & Style' by Bruce Silver (http://www.bpmnstyle.com/), the training material of Dr. Jim Arlow (http://www.slideshare.net/jimarlow/introductiontobpmn005) 'How much BPMN do you need' (http://www.bpm-research.com/2008/03/03/how-much-bpmn-do-you-need/), but also our own experience.

    We define three categories of BPMN2 constructs:

    • Basic: constructs in this category are straight-forward and easy to grasp. Constructs in this category can be used to model simple business processes.
    • Advanced: contains more powerful or expressive constructs, but this comes with higher modeling and execution semantics learning curve. 80% of the business processes are implementable with constructs from this and the previous category.
    • Complex: constructs in this category are used in specific and/or rare cases, or their semantics are difficult to understand.

     

    The next sections will show the constructs per category. It's here where documentation/examples can be added.

    Constructs in bold are not yet implemented!

     

    Basic constructs

    Events

    Swimlane

    • Pool
      • Graphically: container for partitioning a process from other pools
      • Can be empty (black-box pool)
      • Sequence flow cannot cross pool boundaries
      • Interaction between pools is done through message flow
      • In XML: laneSet --> Lanes/parentLane
      • Process can contain one or more lanset
      • LaneSet attributes
        • process
        • [0..*] Lanes
        • [0..1] parentLane -> laneset can be a child of a lane
    • Lane
      • Sub-partition within a pool (organisational purpose)
      • Can be nested
      • Attributes
        • name
        • [0..1] partitionElement -> reference to a baseElement (e.g Performer)
          • All lanes in the same laneset must define partition elements of the same type (eg all lanes in a laneset define the Performer element as partition element, but with different values).
        • [0..1] partitionElementRed -> idem?
        • [0..1] childLaneSet --> reference to an inner laneset
        • [0..1] flowElementReds -> list of flowElement paritioned in this lane (according to the paritionElement defined above)
      • Influence on execution?
        • Little. Perhaps for user task assignment? Spec isnt very clear on how to use the paritionElement.

        Activitities

        Gateway

        Other

        • [4.3] Resource (basic) https://jira.jboss.org/jira/browse/JBPM-267
          • resource.jpg
          • (picture copied from the BPMN2 spec, version augustus 2009. click on the pic for a more readable picture)
          • For a first release, resource parameters seem less important
          • HumanPerformer / PotentialOwner are important (primary use case: User Tasks). Main question here is how we map these on jBPM assignee/candidate-users/candidate-groups?

        Connecting constructs


        Advanced constructs

        Events

        • Message start event
        • Timer start event
          • Start on a fixed date
          • Or regularly start with a time expression (eg. every monday) -> more likely a use case
          • problem: time expressions are too limited -> cron like expressions?
          • problem: how does the engine know when to trigger?
            • dedicated thread?
            • Use the JobExecutor with a dedicated job?
              • Create trigger job after deployment. When job fires, it starts process instance and creates a new job if a timeCycle is defined
            • DeploymentProperty could be used to speed things up?
            • How do you keep it performant for many, many time-triggered processes?
        • Signal start event
          • ProcessEngine wide listener to events
        • Message end event
        • Signal end event
        • Error end event
          • simple: throw error event and let it propagate
        • Escalation end event
          • simple: throw escalation event and let it propagate
        • None
          • Throwing
        • Timer
          • catching
            • Delay process
            • async + duedate
          • Boundary (interrupting/non-interrupting)
            • Interrupting already exists in JPDL (default timer on outgoing transition) -> in BPMN 2 this is called 'exception flow'
            • Non-interrupting can be done by creating a new child execution when the event is catched
        • Message
          • Throwing/catching
          • Boundary (interrupting/non-interrupting)
        • Error

        •  

          • Boundary (interrupting)
            • Should already be in the PVM to some degree (org.jbpm.pvm.internal.model.ExceptionHandlerImpl)
        • Escalation
          • Throwing
            • Fire a custom event
          • Boundary (interrupting/non-interrupting)
            • Use exception handling mechanism
        • Signal
          • Catching/Throwing
            • Signal can potentially be used for inter-process synchronisation
            • Cannot use regular event listeners here
              • Because it's not guaranteed that the process definition containing a signal catch (or start, for that matter) is even loaded into the memory!
            • So basically, the process engine needs to keep a list of listeners for each signal type
              • What about performance?
          • Boundary (interrupting/non-interrupting)
            • Same mechanism as standard catching event

        Gateway

        • Inclusive
          • Diverging: all conditions are evaluated and all sequence flow that evaluate to true are taken (in parallel)
            • Note: zero true evaluations is valid according to the spec!
            • Default path can be specified if no conditions evaluate to true
            • implementation is easy
          • Converging: merge incoming paths
            • From the spec:
              • The Inclusive Gateway is activated if
                • At least one incoming sequence flow has at least one Token and
                • for each empty incoming sequence flow, there is no Token in the graph anywhere upstream of this sequence flow, i.e., there is no directed path (formed by Sequence Flow) from a Token to this sequence flow unless
                - the path visits the inclusive gateway or
                - the path visits a node that has a directed path to a non-empty incoming sequence flow of the inclusive gateway
            • implementation not trivial
              • What constructions are available in PVM for searching if a direct path exists?
        • Complex

        Connecting constructs

        Activities

        • ServiceTask (WS)
        • SendTask (WS)
        • ReceiveTask (WS)
        • Business rule task

        Subprocess

        • Embedded
        • Ad-hoc
        • Reusable (call activity)

        Data

        • InputOutputSpecification
        • Data object
        • DataAssociation
        • DataInput/DataOutput
        • DataInputAssociation/DataOutputAssociation
        • InputSet/OutputSet
        • Property

        Other


        Complex constructs

        Events

        • Conditional start event
        • Multiple (parallel) start event
        • Cancel end event
        • Compensation end event
        • Cancel
          • Boundary (interrupting)
        • Multiple
          • Catching/Throwing
          • Boundary (interrupting/non-interrupting)
        • Conditional
          • Catching/Throwing
          • Boundary (interrupting/non-interrupting)
        • Compensation
          • Throwing
          • Boundary (interrupting)
        • Link
          • Throwing/Catching

         

        Gateway

        • Event-based

        Subprocess

        • Transaction
        • Event subprocess
          • Interrupting / non-interrupting


        4.4 Planning

        • Signavio end-end demo
        • User Task + resource review
        • Pool
        • Lane
        • Inclusive Gateway
        • Service Task WS
          • Library or low-level HTTP invocation?
          • Testing/QA !
        • Embedded SubProcess
        • IoSpecification
        21296 Views Categories: Tags: