Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Process orchestration and automation of tasks require a solid and scalable engine.
With score, we aim to provide an open-source, generic orchestration engine that can be used in multiple environments and scenarios such as: cloud setup and maintenance, build systems, QA, and many more.
score's code base comes from HP's Operation Orchestration product.
score is a generic workflow engine based on Java. It supports multiple common orchestration languages. The following are within the projects scope:
- A scalable core engine that can run execution plans. May be created either with code or by provided compilers.
- Provide compilers that can convert a given workflow description format (including XML/JSON) to an execution plan that the engine can execute.
- Provide example AFL (Advanced Flow Language) content. These are workflows that are compiled using the AFL orchestration language.
- Provide Out-of-the-box (OOTB) content that can be run in the engine. This includes common actions written in Java; score's native language.
- Support multiple common orchestration languages. AFL is already included while a BPMN compiler is in the projects roadmap.
- Provide a standard compiler interface that orchestration languages will use.
- To encourage the adoption of the engine, score provides comprehensive documentation and code samples using the engine to showcase its versatility.
Content management and visual history reporting capabilities are out of scope.
score is a generic engine that is able to execute workflows. A workflow has a logical structure that resembles a flow-chart.
Workflows contains both logical operations and actions. A workflow must be compiled using one of the available orchestration languages before use.
A compiled workflow is known as content and can take several forms such as jar files or a binary object stored in a database.
The fundamental architecture of the project consists of:
- Worker - The unit that actually executes the steps from the execution plan. Execution logic is optimized for high throughput and is horizontally scalable.
- Orchestrator - A queue-based work distribution mechanism. Highly available and horizontally scalable.
- Persistency for cluster management - Allowing a cluster of orchestrator and worker nodes. Optional for simple single-node deployments.
- Compiler - Compiles a given flow format into an execution plan that can be executed by the workers. The introduction of a new flow formatting language is achieved by hooking the right compiler. Currently, we have an AFL OOTB compiler implemented.
- Remote worker - A worker with remote communication abilities. Can be used to execute work across firewalls.
Note that score deployment has two flavours:
- Simple flavour - Consists of a single-node deployment of orchestrator and worker in the same runtime container. No external DB is required.
- Distributed flavour - A highly available and scalable deployment that requires an external DB schema and a servlet container for hosting the orchestrator node(s).
score, being an engine, is most useful when integrated into other tools and/or frameworks based on different use-cases.
We believe that Eclipse Foundation is the right place for score to be exposed to developers seeking an orchestration engine.
This will also offer an opportunity for score to be inherently used as part of core projects within Eclipse.
For example, the Eclipse IDE could be used in order to author score flows. When the BPMN compiler is implemented, it will process BPMN standard XML to execution plan that score can execute.
This will allow model flows developed in the BPMN2 project to be utilized. Stardust uses XPDL which extends the BPMN language. So if a compiler was developed that supported XPDL, the user will be able to create a flow in Stardust modeler and then execute in score.
The code is now part of the HP software products, and is named “HP Operations Orchestration”. Copyright is held by HP Software, and was approved to be open-sourced.
Currently, the community around the code is only HP software employees who work in the HP OO product.
We aim to release a beta version towards the end of 2014.
In our roadmap, over the next 1 to 1.5 years we plan to provide:
- A workflow engine that can execute content in multiple languages.
- OOTB content that will provide value to users and support single-node deployment.
- Provide OOTB flows that will enable users to orchestrate Docker capabilities.
- Allow authoring of score workflows within the Eclipse IDE.
Community Building In order to grow the community, we plan to:
- Provide examples of project usage.
- Create a website to promote score.
- Integrate with other software solutions.