jBPM

jBPM (Java Business Process Management) is an open-source, Java-based toolkit for modeling and executing business processes. Rather than being a general-purpose programming language, jBPM is a declarative environment: developers describe a process as a graph of tasks, gateways, and events, the engine then drives that process to completion, coordinating human work, automated service calls, timers, and business rules along the way. Since its fifth major release, the native notation has been BPMN 2.0 (Business Process Model and Notation), an OMG standard that gives processes a vendor-neutral graphical and XML representation. Sponsored for most of its life by Red Hat as part of the JBoss community, jBPM sits at the center of a larger family of business-automation technologies, alongside the Drools rule engine and the OptaPlanner constraint solver, and is now incubating at the Apache Software Foundation under the Apache KIE umbrella.

History & Origins

jBPM was created by Tom Baeyens and grew out of work begun around 2003, emerging as a recognizable open-source workflow project in 2004. It joined the JBoss family of middleware projects, and when Red Hat acquired JBoss in 2006, jBPM became part of Red Hat’s open-source portfolio, where it would be developed and productized for nearly two decades. Over time project leadership passed from Baeyens to Kris Verlaenen and later Maciej Swiderski.

The early life of jBPM was tied to its own process language, jPDL (jBPM Process Definition Language), an XML notation built on a model the project called Graph Oriented Programming: a process was an executable graph of nodes and transitions. jPDL was expressive and well integrated with Java, but it was specific to jBPM. As the broader industry coalesced around the BPMN 2.0 standard, the project began, around August 2009, to build a native BPMN 2.0 implementation in parallel with jPDL, hosted on the Process Virtual Machine (PVM) introduced in jBPM 4. The PVM was a deliberate piece of architecture: a generic execution core capable of running more than one process language.

A pivotal change came in 2010–2011. The jBPM project and Drools Flow, the workflow sub-project of the Drools rule engine, were merged. The result, jBPM 5.0.0.Final, released on 31 January 2011, abandoned jPDL as the headline language and adopted BPMN 2.0 as the native notation, running on the shared Drools/KIE platform. Around the same period Tom Baeyens and fellow contributor Joram Barrez left to start Activiti, a competing open-source BPM engine backed by Alfresco; Activiti would itself later be forked into Flowable. jBPM thus became the ancestor of an entire lineage of Java BPMN engines.

Design Philosophy

jBPM reflects a few consistent ideas about how enterprise software should be built.

• Declarative process, imperative detail. The shape of the work, the order of steps, the decision points, the parallelism, is expressed declaratively as a BPMN diagram, while the concrete logic of any individual step (a service call, a calculation) lives in Java or in invoked services. The intent is that a process model can be read, and even edited, by analysts, not just programmers.
• Processes and rules belong together. By merging with Drools Flow, jBPM committed to a worldview in which business processes and business rules are two faces of the same “knowledge.” A loan-approval flow, for instance, can hand off to a Drools rule set to evaluate eligibility, all within one knowledge session.
• A standard notation, not a proprietary one. The move from jPDL to BPMN 2.0 traded lock-in for interoperability. A BPMN 2.0 model is portable in principle across compliant engines, and is backed by a widely taught industry standard.
• Human work is a first-class citizen. Unlike pure orchestration engines, jBPM treats human tasks, work that must be assigned to and completed by people, as a core construct, complete with task lists, assignment rules, and escalation.

Key Features

BPMN 2.0 process modeling

The heart of jBPM is its execution of BPMN 2.0 processes. A process is authored either graphically (in Business Central or an Eclipse-based designer) or directly as BPMN 2.0 XML, and is composed of familiar building blocks:

• Tasks — service tasks, user (human) tasks, script tasks, business-rule tasks, and more.
• Gateways — exclusive, parallel, inclusive, and event-based branching and merging.
• Events — start, end, timer, signal, message, and error events for reacting to the world.
• Sub-processes — embedded, reusable, and event sub-processes for structuring large flows.

A small BPMN 2.0 fragment shows the declarative, XML-backed nature of a definition:

1
2
3
4
5
6
7

<process id="orderApproval" name="Order Approval" isExecutable="true">
  <startEvent id="start"/>
  <sequenceFlow sourceRef="start" targetRef="review"/>
  <userTask id="review" name="Review Order"/>
  <sequenceFlow sourceRef="review" targetRef="end"/>
  <endEvent id="end"/>
</process>

The snippet is illustrative of BPMN 2.0 structure rather than a complete, runnable deployment.

Human task management

jBPM includes a human-task service (historically aligned with the WS-HumanTask specification) that manages the lifecycle of work assigned to people: claiming, starting, completing, delegating, and escalating tasks, with group- and role-based assignment.

Integration with rules and planning (the KIE platform)

Because jBPM shares its runtime with Drools, a process can invoke business rules directly through business-rule tasks, and both are managed through the common KIE (Knowledge Is Everything) API and KIE containers. The related OptaPlanner solver rounds out the platform for optimization and scheduling problems.

Case management

From version 7 onward, jBPM added case management support for less structured, knowledge-worker-driven scenarios, where the exact sequence of activities is not known in advance and the case evolves dynamically, in contrast to rigidly predefined processes.

Tooling and runtime

jBPM ships with Business Central, a web workbench for authoring, deploying, and monitoring processes, and with a KIE Server execution component exposing REST and other remote APIs so that applications can start processes and complete tasks programmatically.

Evolution

jBPM moved through several distinct eras, each marked by a major release:

The trajectory is one of steady consolidation: from a stand-alone workflow engine with its own language, to a member of a unified knowledge-automation platform built on a shared runtime and a standard notation. The most recent shift has been toward Kogito, which re-implements process and rule execution for cloud-native stacks such as Quarkus and Spring Boot, emphasizing fast startup, small memory footprint, and Kubernetes-friendly deployment.

Current Relevance

jBPM remains widely deployed in enterprises, particularly through Red Hat’s commercial offerings, which have carried names including JBoss jBPM, JBoss BPM Suite, and Red Hat Process Automation Manager. The standalone open-source 7.x line reached its last maintenance release (7.74.1.Final) in July 2023, after which active community investment moved toward Kogito for greenfield, cloud-native automation.

The larger story of the late 2020s is the platform’s move to the Apache Software Foundation. Drools, jBPM, OptaPlanner, and Kogito were donated to Apache and now incubate together as Apache KIE. The first major release under the foundation, Apache KIE (incubating) 10.0.0, arrived in December 2024, following roughly fifteen months of work since the previous KIE-group release in September 2023, with a follow-up 10.1.0 release continuing the modernization effort. For organizations with existing jBPM investments, this means the engine continues, now under open governance, while new projects increasingly target the Kogito/SonataFlow generation of the same lineage.

Why It Matters

jBPM matters as one of the longest-running and most influential open-source business process engines. It helped bring BPMN 2.0, an industry-standard, vendor-neutral process notation, into the mainstream of Java enterprise development, and it pioneered the idea that business processes and business rules should be unified rather than siloed, an idea embodied in the KIE platform it shares with Drools.

Its influence also runs through its descendants. The departure of jBPM’s original creators to found Activiti, which in turn was forked into Flowable, means that much of the open-source Java BPMN landscape traces back to decisions made in the early jBPM project. And its ongoing evolution, from jPDL to BPMN 2.0, from monolithic engine to cloud-native Kogito, from Red Hat stewardship to Apache governance, makes jBPM a compact case study in how enterprise infrastructure software adapts across two decades while keeping a vast installed base running.