This document describes the life cycle of a typical business process, from design and implementation all the way to analysis. For each of the phases in the life cycle, we will describe in more detail what this phase is all about. We will also show how Drools Flow can assist you during each of these phases, with a description of the various components that are relevant during that phase combined with screenshots or even small screencasts to show the most important features.
Click on any of the 5 phases in the business process life cycle below to start!
The main advantages of using Drools Flow in this context are:
- Unification: During the last few decades, several standards for specifying
business processes (BPMN, XPDL, WS-BPEL, etc.) and even more proprietary formats have been
defined. Drools Flow is a fully open-source process engine implementation that hides the
details of which process language is actually used to specify the business process as much as
possible, and provides a unified solution where several process languages can be combined.
As a result, all features that are implemented on top of the engine using this generic API can
automatically be used for all supported process languages.
- Generic process engine: The core engine is a generic process engine that provides the basic building blocks and core services (persistence, transactions, events, etc.) for implementing a specific process language. This allows us to support the execution of different process languages on the same engine, i.e. BPMN2, OSWorkflow, jPDL, etc.
- Embedding custom components: Drools Flow does not require you to implement the process language on top of the generic process engine, but also allows you to embed your own (legacy) component for executing a specific process language. For example, Drools Flow supports the execution of WS-BPEL processes by integrating the RiftSaw engine (based on the Apache ODE engine).
- Integration: Drools Flow integrates with a lot of (internal and/or external)
open-source projects to better support all phases of the life cycle. This allows
us to continuously add new and exciting features without having to implement it all
ourselves. This for example includes:
- Guvnor as process repository
- RiftSaw (Apache ODE) for WS-BPEL execution
- JBoss BPM console for web-based process management
- Oryx for web-based BPMN2 process editing
- Service Activity Monitoring (SAM) for Business Activity Monitoring (BAM)
- JOPR for administration / monitoring
- JBoss ESB as service-oriented platform
- ProM for process mining and analysis
- Future: Drools Flow does not only offer support for the basic functionality
that can be found in all BPM engines nowadays but also tries to provide new and exciting features
that (we believe) will become more and more important in the future:
- Domain-specific processes: We believe processes should be defined in a high-level, declarative manner and easy to understand. Drools Flow allows users to define domain-specific processes by plugging in custom, domain-specific nodes, making the process easier to understand.
- Dynamic processes (also known as unstructured or ad-hoc processes or case management): Traditional process engines require the user to specify the exact order of all the activities in the process, using a flow chart to connect all activities. Unstructured processes cannot be predefined entirely (e.g. to support human choice, conditional activities, exceptional situations, runtime addition of activities, etc.).
- Knowledge-oriented: Instead of forcing users to define all their business knowledge inside the process (i.e. using a process-oriented approach), we allow users to not 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 seemless integration, regardless of whether you are using processes, rules or event processing.
The following figure also gives an overview of the various components and in which stage of the process life cycle they are most important:
The resulting architecture of all the components relevant in the different phases of the life cycle is shown below. User interface components at the top are divided into web-based tooling (targeted towards more business users) and Eclipse tooling for developers. The architecture also shows how the various backend services are (directly or indirectly) linked to each other.
