Status message

This proposal has been approved and the Eclipse score project has been created.


This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project: 

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).
Why Here?: 

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.


Project Scheduling: 

We aim to release a beta version towards the end of 2014.

Future Work: 

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:

  1. Provide examples of project usage.
  1. Create a website to promote score.
  1. Integrate with other software solutions.
Project Leads: 
Source Code
Initial Contribution: 

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.

Source Repository Type: 
meir wahnon's picture

i think we will target BPMN 2 once we start working on BPMN compiler

A big diff between score and stardust is the Out Of the Box content we plan to provide with it,

meanning , in stardust you can call java methods, but there is no 

built in java methods to ease the creation of your flow logic.

In score, we plan to add OOTB content, which are like building blocks that can be used for your flows, like SSH and REST methods

that way building flows with complex logic will be easier...

(no need to rewrite code)


Harar Zafrir's picture

Hi Adrian,


We are currently supporting the AFL orchestration language and have plans to support additional languages

such as BPMN, as this will probably happen after the project is more mature, we do not know at this point the exact implications

of supporting a specific BPMN version.

We still need to go forward and learn more about related projects in SOA - i.e. Stardust.

Regarding monitoring - score is basically an engine and meant to be integrated as a library.

Dashboards / UIs are not part of the current scope, but APIs are exposed and meant to be used.


Please let us know if you think we should set up a conference call to discuss these aspects in details.


Best regards,


Adrian Mos's picture

Hi guys,

just re-sending what I originally sent out as an email which I realize you may not have seen:

Thank you for this submission. I would be interested in learning a couple of things and I'm sure other PMC members might have follow-up questions.

- Is there a connection with business workflow tools and process design/execution languages such as BPMN 2? I think you mention BPMN down the road, are you going to target version 2?

- Any connection with SOA?

- Are there monitoring capabilities that you are offering (APIs, dashboards, etc)?




Marc Gille-Sepehri's picture

From what I can see in the overview:

  • It definitely belongs into the SOA Platform Project.
  • It has significant overlap with Stardust, which is by nature no obstacle, but the projects should discuss this overlap and identify synergies.
  • The project might use the BPMN2 Modeler and/or the Stardust BPMN2 We Modeler.
  • The project might consider the Mangrove to BPMN2 mappings.

In any event: Welcome to the club! Hope to see you at ECE 2014.

Harar Zafrir's picture

Thanks Marc!

Apologies for not responding for so long, we have been very busy working on this project's code and structure lately,

and did not pay enough attention to the progress on the project setup in Eclipse.

We definitely need to learn more about Stardust and Mangrove, we will look into these projects, learn and probably ask a few questions...

Please let us know if you think it would be benificial to have a conference call at this point to discuss the overlaps.


Best regards from all the score team,