BPM stands for Business Process Management. There are 2 different aspects of BPM: BPM as management discipline and BPM as software engineering. The BPM vendors have long time tried to make abstraction of those 2 distinct aspects. That path lead to more confusion then anything else.
BPM as a management discipline is the responsibility of every strategic executive manager. It's to ensure that the organization performs well in their core business processes. This involves understanding what values the organization delivers and how those are achieved. This means analyzing, documenting and improving the way that people and systems work together. As part of that work, it's useful to work with models and diagrams. BPMN diagrams express the execution flow of the steps to accomplish a certain goal. Important to note that these models are used for people to people communication. They can be underspecified, which means that they can contain valuable high level information without including unnecessary details. Such underspecified process models are also known as abstract business processes.
BPM as software engineering means that executable business processes will be executed by a BPM System (BPMS). Executable business processes are based on a diagram that represents the different steps in an execution flow. The diagram can actually look exactly the same as the abstract business process. But executable business processes are different in some very fundamental ways. First of all they need more technical details. That part is generally accepted.
But what is less understood is that executable processes only take the perspective of a single system, the BPMS. The BPMS can act as a coordinator, so steps in the process could be for example user tasks. Then the user task becomes a wait state for the BPMS. And when the external task is completed, then the BPMS acting as a coordinator should be informed about the completion. In that context, a BPMS often acts as a state machine. So it's clear that the BPMS, even as a coordinator, can not handle steps between 2 external parties. For example, warehouse clerk handing over an order to a packager that wraps the order package. Imagine none of that is automated, then there is no way of the BPMS to be informed about those steps. So they can't be modeled distinctly in the executable business process.
Another less known difference between abstract and executable business processes is that executable processes are part of the software development lifecycle. That implies they are under the control of the technical developers and that executable processes need unit testing just like any other piece of software.
Traditional BPM vendors try to abstract those differences with automagical round tripping between abstract process models and executable process models. But in general, that approach fails in practice.
Once you have your business processes deployed, Activiti automatically captures everything that happens in the Activiti history DB. For example, how long does each process instance or activity instance take, who submitted which data and when, in which continent does this sale occur, which order is this process for, which contract was this insurance claim for, and so on. If you don't turn it off explicitely, all that information stored in the history information. From that history information, various kinds of reports can be generated. Those reports show analytics on that data. Like for example: The average time for each activity in the process, the amount of sales per region, the percentage of rejected orders, and so on.
Because the graphical diagram of the executable business processes has been driven by the business people, it means that the automatically generated analytics also have meaning on a business level. That is a crucial win for BPM Systems.
Another use case for the history information are audit logs. Also those come for free when developing your solution based on a business process. Who filled out what and when gives highly traceable decisions. The task comments even can give the full context of why certain decisions were taken at the time.
First, you as a developer get business intelligence and audit logs features for free. And with building your solution on business processes, Activiti will help developers to structure their software better. Think about user tasks, external systems and timers that need to be managed. And then try to think how you like your transaction boundaries of your application. That puzzle can be a challenge in enterprise applications. Building that kind of features becomes a lot easier when structuring an application around a business process. Managing wait states, timers and asynchronous continuations becomes peanuts. A business process can express that structure a lot more compact then working with the fundamental instruments that the Java platform offers like JDBC and JMS. And Activiti makes sure that you can easily link in Java or scripting for jobs that are better done in other languages.
The Process Virtual Machine (PVM) is an architecture design pattern for process engines. The structure of the process definition is separated from the implementation of the different activity types. And the runtime data structure for process executions is based on a pointer to an activity in the process graph. Activity types and hence whole process languages become pluggable on that single core engine.
In the forseeable future, Activiti will only target BPMN 2.0 as a general purpose process language. But we anticipate that Activiti will be leveraged to build a lot of limited and dedicated process languages for specific use cases. For example pageflow that models the navigation between pages in a webapp, or a simple language to script Spring integration services, or orchestrate some Spring batch jobs, and so on.
The BPM market has longtime been fragmented because there was no concensus amongst BPM vendors. Several standards and specifications tried to fill that gap in the past, but none gathered enough traction in the industry to become an accepted standard for doing BPM. But luckily, times are changing, and over the past years BPM vendors have sat together to create a standard that unifies the BPM landscape. That standard is called 'BPMN', which stands for 'Business Process Model and Notation', and is developed and maintained by the Object Management Group (OMG) since 2004.
The first version of the BPMN specification (versions 1.x, first version released in 2004) focussed on graphical notation only, and became quickly popular within the business analyst audience. This means that the BPMN 1.x specification defines how concepts such as a human task, an executable script, automated decisions, etc. are visualized in a vendor-neutral standardized way. The second version (2.0), extends that focus to include execution semantics and a common exchange format. This means that BPMN 2.0 process definition models are not only exchangeable between graphical editors, but those models can also be executed as-is on any BPMN 2.0 compliant engine such as Activiti.
It's easy to understand that the future of BPM is BPMN 2.0. And we at Activiti are very happy to bring you that future, today.
The Process Virtual Machine allows the Activiti Engine to support multiple process languages natively. Which language that the developers will choose is hard to predict at this time. In fact, developers will use different process languages depending on their needs. We'll go through great efforts to make BPMN 2.0 as developer friendly as possible. For example with the principle of BPMN shortcuts. We'll also include Java event listeners and Spring support into BPMN 2.0 so that your Spring beans can be accessed from any expressions.
Activiti builds further on the huge experience that we build up from founding jBPM till the Process Virtual Machine design in jBPM 4. In Activiti we now have united very skilled and talented people and companies to build the next generation BPM technology. BPMN 2.0 will be the future of BPM and we have the know-how to bring these features in a developer friendly manner. Activiti's dedicated focus on BPMN 2.0 enables us to deliver a future proof BPM and workflow solution.
Given that we spend a lot of effort building jBPM 4 and that we were very proud of the results, we regret that a jBPM 4 is discontinued as indicated by JBoss
"It is fair to say that there was expectation that jBPM 4 would appear in a version of the SOA Platform as a replacement for jBPM 3. With the changes to the jBPM project team and the next steps in unifying our efforts in this area across projects, it is not going to happen."
Activiti will not suffer from a single company vulnerability. We're extremely happy that Alfresco gave us the opportunity to develop Activiti with an intend to make it an Apache project. Core at the Apache foundation's value is the continuity of projects and guaranteeing that it stays true the community. So one of the requirements is that multiple companies have to be actively involved in the community of a project. From the start, SpringSource is joining this initiative so we are well on our way to ensure Activiti will have a long life that is not under the full control of a single person or company.
That's to indicate that we're not building experimental stuff here. We continue to build on our experience that we gained developing the jBPM versions 1 to 4. We use that knowledge as a base line and work with the community to build the next generation BPM solution.
Activiti is licensed under the Apache License 2.0 to encourage widespread usage and adoption of the Activiti BPM engine and BPMN 2.0. By choosing such a liberal licence, we want to emphasize our goal of commoditizing BPM technology.
Subsequent database compatibility will be driven by demand.
The Activiti Engine uses the database for synchronization. A process is executed in transactional steps. Each step is calculated with a single thread. Which is logical since calculations that need to happen between two wait states is typically minimal and hence typically it is not an optimisation to calculate different paths in concurrent threads. Access to a DB connection has to be synchronized anyway.
By default, Activiti Engine uses the thread of the client to perform it's work. That is the easiest to embed it into other software. In the future we envision configurations that allow for asynchronous execution of the service methods. The current architecture would allow that very easily.
Processes include activities that need to wait for an external trigger. Activiti Engine will never block a thread in those situations. That is when the execution state is persisted and then the transaction commits. If you look at the database and you imagine that all calculations to execute the process happen instantly, then it's often easier to envision the logic of Activiti Engine.
The behavior of Activiti Engine to calculate possibly multiple steps in a process until a wait state is reached is the default behavior. Asynchronous continuations will be introduced to allow for a more fine grained demarcation of transactions for those situations where it is needed.