Chapter 1. Introduction

JBoss jBPM is a flexible, extensible framework for process languages. jPDL is one process language that is build on top of that common framework. It is an intuitive process language to express business processes graphically in terms of tasks, wait states for asynchronous communication, timers, automated actions,... To bind these operations together, jPDL has the most powerful and extensible control flow mechanism.

jPDL has minimal dependencies and can be used as easy as using a java library. But it can also be used in environments where extreme throughput is crucial by deploying it on a J2EE clustered application server.

jPDL can be configured with any database and it can be deployed on any application server.

1.1. Overview

The core workflow and BPM functionality is packaged as a simple java library. This library includes a service to manage and execute processes in the jPDL database.

Overview of the jPDL components

Figure 1.1. Overview of the jPDL components

1.2. The jPDL suite

The suite is a download that contains all the jBPM components bundled in one easy download. The download includes:

  • config, configuration files for a standard java environment
  • db, SQL scripts for DB creation and compatibility information
  • designer, the eclipse plugin to author jPDL processes and installation scripts (this is not part of the plain jpdl download) See also Section 1.3, “The jPDL graphical process designer”.
  • doc, userguide and javadocs
  • examples
  • lib, libraries on which jbpm depends. For more information on this see Section 5.3, “Third party libraries”
  • server, a preconfigured jboss that contains jbpm inside the console web application (this is not part of the plain jpdl download)
  • src, the jbpm and identity component java sources

The preconfigured JBoss application server has the following components installed :

  • The web console, packaged as a web archive. That console can be used by process participants as well as jBPM administrators.
  • The job executor enacts timers and asynchronous messages. There is a servlet context listener in the console web app that launches the job executor, which spawns a thread pool for monitoring and executing timers and asynchronous messages.
  • The jBPM database, an in-process hypersonic database that contains the jBPM tables.
  • One example process is already deployed into the jBPM database.
  • The Identity component libraries are part of the console web application. The tables of the identity component are available in the database (those are the tables that start with JBPM_ID_)

1.3. The jPDL graphical process designer

jPDL also includes a graphical designer tool. The designer is a graphical tool for authoring business processes. It's an eclipse plugin.

The most important feature of the graphical designer tool is that it includes support for both the business analyst as well as the technical developer. This enables a smooth transition from business process modelling to the practical implementation.

The plugin is available as a local update site (plain zip file) for installation via the standard eclipse software updates mechanism. And there is also a feature package that you can unzip in your eclipse home directory.

1.4. The jBPM console web application

The jBPM console web application serves two purposes. First, it serves as a central user interface for interacting with runtime tasks generated by the process executions. Secondly, it is an administration and monitoring console that allows to inspect and manipulate runtime instances. The third functionality is Business Activity Monitoring. These are statistics about process executions. This is useful information for managers to find bottlenecks or other kinds of optimisations.

1.5. The jBPM core library

The JBoss jBPM core component is the plain java (J2SE) library for managing process definitions and the runtime environment for execution of process instances.

JBoss jBPM is a java library. As a consequence, it can be used in any java environment like e.g. a webapplication, a swing application, an EJB, a webservice,... The jBPM library can also be packaged and exposed as a stateless session EJB. This allows clustered deployment and scalability for extreme high throughput. The stateless session EJB will be written against the J2EE 1.3 specifications so that it is deployable on any application server.

Depending on the functionalities that you use, the library jbpm-jpdl.jar has some dependencies on other third party libraries such as e.g. hibernate, dom4j and others. We have done great efforts to require only those dependent libraries that you actually use. The dependencies are further documented in Chapter 5, Deployment

For its persistence, jBPM uses hibernate internally. Apart from traditional O/R mapping, hibernate also resolves the SQL dialect differences between the different databases, making jBPM portable across all current databases.

The JBoss jBPM API can be accessed from any custom java software in your project, like e.g. your web application, your EJB's, your web service components, your message driven beans or any other java component.

1.6. The JBoss jBPM identity component

JBoss jBPM can integrate with any company directory that contains users and other organisational information. But for projects where no organisational information component is readily available, JBoss jBPM includes this component. The model used in the identity component is richer then the traditional servlet-, ejb- and portlet models.

For more information, see Section 12.11, “The identity component”

1.7. The JBoss jBPM Job Executor

The job executor is a component for monitoring and executing jobs in a standard Java environment. Jobs are used for timers and asynchronous messages. In an enterprise environment, JMS and the EJB Timer Service can be used for that purpose. Conversely, the job executor can be used in an environment where neither JMS nor EJB are available.

The job executor component is packaged in the core jbpm-jpdl library, but it needs to be deployed in one of the following ways: either register the JobExecutorLauncher servlet context listener in the web app deployment descriptor to start/stop the job executor during creation/destruction of the servlet context, or start up a separate JVM and start the job executor in there programatically.