Data-driven Workflows for Microservices

Microservices is an architectural style inspired by service-oriented computing that has recently started gaining popularity. Jolie is a programming language based on the microservices paradigm: the main building block of Jolie systems are services, in contrast to, e.g., functions or objects. The primitives offered by the Jolie language elicit many of the recurring patterns found in microservices, like load balancers and structured processes. However, Jolie still lacks some useful constructs for dealing with message types and data manipulation that are present in service-oriented computing. In this paper, we focus on the possibility of expressing choices at the level of data types, a feature well represented in standards for Web Services, e.g., WSDL. We extend Jolie to support such type choices and show the impact of our implementation on some of the typical scenarios found in microservice systems. This shows how computation can move from a process-driven to a data-driven approach, and leads to the preliminary identification of recurring communication patterns that can be shaped as design patterns.

💡 Research Summary

The paper addresses a limitation in the Jolie programming language, which is designed around the microservice paradigm, by introducing a choice‑type mechanism that enables data‑driven workflows. Traditional Jolie programs rely on input‑guarded choices, a construct inherited from process algebras such as the π‑calculus, to decide which operation to execute after a message is received. While this process‑driven approach works, it forces developers to write separate guarded blocks for each possible request shape, leading to duplicated code and less flexible service contracts.

To overcome this, the authors extend Jolie’s type system with a choice operator (the ‘|’ symbol) that allows a single message type to be defined as a union of several sub‑types. For example, type request : customer | car_return declares that a variable of type request may contain either a customer structure or a car_return structure. This mirrors the “choice” construct found in WSDL and other service‑oriented standards. The extension required changes to the language grammar, the parser, and the runtime type‑checking component of the Jolie interpreter. At parse time the new operator is recognized and a list of candidate sub‑types is stored in the internal type descriptor. At runtime, when a message arrives, the interpreter builds a temporary abstract syntax tree (AST) of the payload and sequentially attempts to match it against each candidate sub‑type. The first successful match determines which branch of the service logic will be executed.

The paper demonstrates the impact of this change through a concrete car‑rental scenario. In the process‑driven version, the service defines two separate operations (get_car and return_car) guarded by input‑choice brackets; the client must invoke each operation explicitly. In the data‑driven version, a single operation process(request)(response) is defined, and the request type is the union of customer and car_return. Inside the operation a match construct (still experimental in the current interpreter) dispatches to the appropriate handling code based on the concrete type of the incoming request. Both implementations produce identical observable behavior—accepting a rental request, returning a car identifier, and handling a damaged‑car return—but the internal flow differs: the data‑driven version eliminates the need for multiple guarded blocks and centralizes decision‑making in the type system.

From an implementation perspective, the authors discuss how the interpreter’s execution engine was refactored. The original engine performed static analysis of input‑guarded choices, mapping each operation to a fixed handler. With choice types, the engine must perform dynamic dispatch based on runtime type information, adding a linear‑time matching step proportional to the number of alternatives. The authors argue that because typical services have only a few alternatives, the overhead is negligible compared to the benefits of reduced code duplication and clearer service contracts.

Beyond the technical contribution, the paper identifies emerging design patterns enabled by choice types. The “Data‑Choice Router” pattern allows a single endpoint to serve multiple request shapes, simplifying API surface area. The “Type‑Driven Orchestration” pattern suggests modeling complex workflows as hierarchies of choice types, letting an orchestration engine automatically compose the flow without explicit scripting. These patterns align with microservice best practices such as incremental deployment, versioning, and contract evolution.

In conclusion, the addition of choice types transforms Jolie from a purely process‑oriented language into a hybrid that supports data‑driven decision making. This shift improves developer productivity, eases the evolution of service interfaces, and opens avenues for new architectural patterns. The authors acknowledge that quantitative performance evaluation is left for future work, and they propose further research on formal verification of choice‑type matching, scaling the mechanism to more complex type unions, and porting the concept to other microservice frameworks.