The API Mission
The situation with jbpm-3.2.3.GA and below is that there is no stable public API defined for it. As a result, application code depends on implementation detail that changes without prior notice between releases.
To fix this we are going to define an API which is going to be the standard of how you work with BPM in JBoss. Together with the API we will provide Compatibility Test Suite (CTS)
For UML and further explanation goto the API Design and API Roadmap pages.
What is the API based on?
The API conceptually follows the BPMN 1-1 Specification. Doing so we leverage an established standard to describe Business Processes. The ProcessEngine executes that model.
As a result of significant research that has gone into BPMN 1-1 we can be sure that the abstract model defined within reliably covers what is needed to model a BPM process adequately. The terminology that we use for API design is defined in the API Glossary
There are a number of BPMN editors available that allow you to draw BPMN conform process models.
A BPMN editor produces output suitable for presentation - not necessarily for execution. We will look at various options of bringing the aspect of execution to the BPMN model. Ultimately we will have BPMN conform process model that can somehow be executed on the ProcessEngine
Closely linked to BPMN is a set of standard Recognized Patterns. We will schedule support for these patterns on the API Roadmap. We go from simple to complex, making sure we do not compromise correctness and collect qualified feedback during the API Release Cycles.
What does the API cover?
The API is going to cover the concepts and construct from the BPMN 1-1 Specification in a Compatibility Test Suite (CTS). Additionally, it will cover well known Recognized Patterns in sample applications. To monitor progress and to add your requirements you can go to JIRA API Component
What is expected to be stable, what is not?
Application code that uses the API will not be effected by jBPM updates. Minor versions of the API are backward compatible. The API has support for a number of process descriptor formats, which are also backward compatible between minor versions.
Code that has dependencies on jBPM implementation classes might break. We do however not intend to change the jBPM3 code base (unless necessary) until we reach API completeness. Database layout is considered implementation detail that might change between minor versions.
How is the correctness of the API verified?
We ship a set of samples that are based on the API. Functionality that is available through the API is covered by a sample, documented in the wiki and integrated in automated testing. We verify that all samples run as expected in all supported target containers with all supported JDKs.
In parallel we work on jBPM4 (a.k.a. the Process Virtual Machine). For every API construct there must be a mapping against the jBPM3 and the jBPM4 code base. Hence, the jBPM4 code base goes lock-step with jBPM3 in terms what is provided through the API. As a result, users can switch to jBPM4 when we reach API completeness with their application code unaffected.
What are the supported target containers?
We support the lasts three releases of the JBossAS and Apache Tomcat in a given version. For the current status, see the page on supported target containers
How can I participate on API design?
The entry point is JIRA API Component. How to get started with the BPM codes base is documented in jBPM Infrastructure
Comments