Activiti 7 Kick Off Roadmap

If you were looking at the Activiti/Activiti repository, you might have noticed that we are restructuring the project. Activiti is taking a new direction towards Microservices architectures and we are planning to make big design upgrades.

This new direction will give users the flexibility to open up the architecture, replace components as needed and to scale the engine and your applications independently. In combination with containerization (Docker), Microservice architectures with event-driven endpoints provide a cloud native approach to deploy and interact with the engine in a distributed fashion.

However, we are well aware that users are currently embedding Activiti 5.x and 6.x in their applications. As we move toward the final release of the next major version of Activiti, we will provide a set of compatibility and migration tools. Embedding of the Activiti engine will continue to be an important feature for the project. You won’t need to re-architect your application to use this version of Activiti. However, new Microservice architectures implementations will be able to take advantage of this new approach.

We understand that not everyone is using microservices yet but for those that are (and those that are going to) we need to make a real upgrade of the technology behind the engine and how the internal components integrates with each other. The Activiti Process Engine was designed several years ago, this means that there are some components, extension points and mechanisms that have a high impedance with modern architectures and environments.

We recognise that most Open Source process engines out there claim that they are following Microservices practices, but we haven’t seen the major refactoring in how the process engine works or how it integrates with cloud providers and other Microservices that would be required to be a truly Microservice architecture. Most of these other projects treat other Microservices as REST endpoints that you can interact with. By doing so, you neglect the infrastructure that you are using and we want to leverage that. We also recognise the need for playing nicely with Containers and other technology stacks. For that reason we need to upgrade how the engine and other services deal with versioning and immutability. With Microservice architectures, if you want to integrate nicely in fast evolving environments you need to make sure that other technology stacks integrate well with your APIs and data types. For that reason, we are designing our new APIs to provide consistent data types and HAL (Hypertext Applications Language) APIs to help you to build modern applications with cutting edge technologies.

We have created a short term roadmap for this initial refactoring, which will provide the stepping stones for more advanced services that will come towards the end of the year such as:

We will reuse as much of Spring Cloud as possible to make sure that the Process Engine doesn’t overlaps with services provided by the infrastructure

By covering all these key points we plan to provide a set of services that you will be able to use as building blocks for your implementations, making sure that the process engine is only responsible for automating your business processes, and the impedance mismatch with your infrastructure is minimal. The following is the proposed roadmap for the next three months. We aim to test our release process by the end of July 2017, so the first one might be delayed a little bit.

Milestone #0 – 31 July 2017

Clean up Activity

Repository cleanup & restructuring

Dependency upgrades/Alignment with Spring 5 & Spring Boot 2

Infrastructure

GIT / Travis / Bamboo / Maven Central

Daily Snapshots

Test Coverage review

Testing frameworks review

Logging Frameworks review

Domain API + HAL API + Runtime Bundle

Process Definitions

Process Runtime

Task Runtime

Source/Producer of Audit Events

Event Store for Audit Information – Initial Implementation

We should be able to query for all the events generated by multiple process engines

Milestone #2 – 29th September 2017

We should be able to query the current state of processes and tasks without talking with the engine

Application Service / Case Management Features – initial version

Provide basic case management constructs

Provide coordination between different process runtime bundles

Deal with versioning, upgrades and case management like behaviours

We encourage to all users to start trying our milestones as soon as possible so you can get a gist about how these services are going to fit in your implementations.

We are looking forward for comments, questions, concerns and collaborations. We will be working in a truly open source way, meaning that we want you to participate in the development of this and future roadmaps. We are looking for contributors from all levels, so if you feel attached to one of these topics, you want to learn new things or to participate in the conversation please get in touch.

We are using a Gitter channel here to discuss the roadmap, plan and collaborate everyday, feel free to join: