Here you can find a list (indexed below) of ideas/topics we (the Jolie team) had for master/bachelor thesis and research projects.

Above, the label Work in Progress means some students are undertaking or already did some work on the subject. This means that new proponents may be asked to coordinate their work.

If you are interested in working on these or other topics regarding Jolie and Choreographies feel free to contact me at saverio.giallorenzo[at]gmail.com.


Pluggable monitors/loggers

Jolie has in-built logging and monitoring features but right now they are redirected to the standard output. On the contrary, developers and system administrators may need to redirect logged events to different repositories. The motivations are various: to collect aggregated data, to centralise monitoring, to preserve logs in a tractable format for bug investigation and troubleshooting. This means that Jolie should be able to redirect logged events in a modular way, e.g., in files (csv, xml, json, etc.), databases, streams towards centralised loggers, etc..

The Jolie interpreter already equips a modularised event-based architecture for logging, but lacks the feature to redirect logs to specific repositories.

A work in this direction would i) analyse how companies that adopted a microservices architecture [1,2,3] tackled the problem of logging, ii) plan an intervention on the Jolie interpreter to enable pluggable loggers, and iii) implement the planned solution.

The final result of the work would add a new command for the Jolie interpreter to plug different logging repositories (logging services) that implement the same logging interface, e.g., issuable with the command jolie myService.ol --monitor monitorAddress where monitorAddress can be any location supported by Jolie. Then it suffices that the service at location monitorAddress implements the standard Jolie monitoring/logging interface to be able to receive logging events and proceed to process them.


Namespaces in Jolie

Currently Jolie has no explicit namespacing for types, interfaces, etc.. As an example consider the code

Program1.ol : type MyType: void { .username: string .password: string }

Program2.ol : import "Program1.ol" type MyType: void { .username: string }

Where Program2 overwrites type MyType defined in Program2. To avoid these unwanted occurrences, called name collisions, programming languages provide some namespacing mechanism, e.g. names and packages (java.util.Data) in Java.

The goal is to define a namespacing policy for the Jolie language, investigating which parts of a Jolie program would be affected by the addition of namespaces. The final aim is to implement a new primitive — e.g., include Program1 as User — in the language for specifying which elements of a Jolie program belong to distinct namespaces and to access them avoiding collisions — e.g., User.MyType to refer to type MyType of Program1.


Jolie Package Manager

Like any modern programming language Jolie needs a package management system like Gems for Ruby, Pip for Python or NPM for Node.js.

Jolie already has an experimental implementation of a package manager, called JPM composed of a server that acts as repository of packages and a client to search, install, list, and update packages.

Still, the project needs to evolve to become usable and easy to integrate after a standard Jolie installation.

Working on this project would entail i) analysing the basic features of other package managers and package management environments (provision, versioning, dependency resolution, etc.), ii) make a plan of intervention to add some desirable feature to JPM and iii) implement the planned features in the JPM project.


Sodep+ for better logging and flow tracking

The more a network of services grows, the more difficult it becomes to track the flow of interactions and, above all, to understand what generated bad behaviours (crashes, resource overuse, etc.).

Having unique identifiers for each transaction (each communication, i.e., each one-way or request-response) in the network would immensely ease tracing such behaviours.

A work in this direction would be divided into two parts: the first is an analysis of other solutions already adopted to implement uncoordinated, fast, and lightweight (in terms of computation) generators for hundreds or thousands of globally unique IDs per second. For instance, a similar problem has been faced (and solved with the Snowflake approach) by Twitter when it had to scale their tweets storage architecture from big database instances to uncoordinated and distributed databases.

The second part would devise a solution based on the analysis in the first part of the work. Finally the solution would be implemented as a new version of SODEP, called SODEP+ that associates to each operation a unique operation identifier (OID).


Jolie.js

Jolie provides several abstractions to handle communication and concurrency. It would be interesting to explore how these primitives can give a better control over asynchronous calls, concurrency, and architectural composition (e.g., web workers as embedded services) in the development of client-side applications.

Possible thesis/research directions:

  • a theoretical work on comparing an event-based model of JS with that of Jolie. The final goal is to give a sound and complete encoding from the theoretical model of the Jolie language [7] to an event-based calculus resembling that of JS;
  • building a compiler from Jolie to server-side (node.js, io.js) and/or client-side JS;
  • building a Jolie interpreter in Javascript (possibly reusing the existing code-base of the Jolie interpreter, à la Scala.js)

Liquid APIs

Following the approach presented in Towards a Composition-Based APIaaS Layer, analysing how Jolie interfaces relate to API definition languages like Swagger, RAML, blueprint, etc.

This can both follow a more theoretically-oriented path, on the expressiveness of Jolie interfaces with respect to other solutions, but also applied work on e.g., a tool to translate API definitions into Jolie interfaces and vice versa. This would be a cornerstone for other tools spanning e.g., from SDK generators to easy-to-read API specifications.

An example of integration between Jolie interfaces and REST ones, is Jolie2Rest within the Jester project (a Jolie rEST routER). Jolie2Rest automatise the creation of i) proper configuration files to publish existing Jolie microservices as REST APIs and ii) a Swagger interface documenting all the API published in the router.


Microservices and Reactive Programming

Reactive Programming is a programming paradigm focussed on data-flows and propagation of changes.

An interesting topic is to investigate how reactive programming, and in particular functional reactive programming, relate to Service-Oriented Programming and Microservices. Look here for a semi-serious (yet remarkable) introduction to functional reactive programming.


Jolie microservices, containers, and big data

Data are growing exponentially. Moving them around results in a huge loss of efficiency (in bandwidth and time).

Paraphrasing Francis Bacon,

if the data will not come to the computation, the computation will go to the data

Instead of moving data, we can use containers (e.g., Docker) to deploy a sandboxed Jolie-enabled environment where the data reside. Then a set of Jolie microservices can read the data, do the necessary computation, and return the result. It is also easy to make different instances of the same container work together to coordinate the computation over different yet dependent sets of data.

Services in Jolie are highly mobile. It is very easy to change how services are “glued” together by changing the medium they communicate on and/or the format of their communication.

A project in this direction would:

  • explore how containers and microservices interact with each other. E.g., we want to launch a task that returns some aggregate data. To do that, we write an orchestrator that “knows” i) the location of the data repositories and ii) the algorithms needed to manipulate the data and produce the result. When launched, the orchestrator deploys in each location a container with the services that handle the data and waits for them to finish their computation, receive the (partial) results and elaborate the (global) solution;

  • containers also allow services to migrate and replicate from a computational platform to another. On this direction, we can investigate how Jolie services can be stopped and resumed and how this can fit into dynamic plans for load-balancing, DMZs, etc.

The Jocker (Jolie Docker orchestrator) project is a first step towards the integration of Jolie microservices with containers. Jocker maps the Docker APIs within Jolie, so that Jolie microservices can control Docker to deploy, move, scale, and, more in general, orchestrate a fleet of containerised microservices.


Choreographies, container, and big data

Choreographies give a general overlook on the interaction in a distributed system. A project in this direction can explore the concept of choreographic deployment. Some of the questions to answer are:

  • Can choreographies ease the specification of container deployment?
  • Can choreographies specify how the services in a container interact with each other (within the same container and with services of other containers)?
  • What guarantees can we give on top of choreographic deployment specifications? E.g., static check on the typing of the interaction, inferring properties for checking correctness at runtime through monitoring.

AWS Lambda, Jolie, and Choreographies

One of the latest and most interesting services of Amazon Web Services is AWS Lambda. In a few words, AWS Lambda introduces the serverless architecture. In practice, with AWS Lambda the administrator deploys an application as a set of loosely coupled functionalities, each in its own container, without setting up a platform — a server — that is always on to run it.

AWS Lambda has tree main benefits with respect to traditional server-based configurations: i) pay-per-use pricing, because Amazon charges only when Lambda functions are run and ii) containers of Lambdas automatically scale when called concurrently and thus there is no need to plan scaling/managing policies.

AWS Lambda promises a new, agile, and cost-effective way of building application, yet it requires tools and techniques to harness the complexity of developing highly-distributed applications. Serverless is an example of development framework that provides structure and enforces best practices for the development of AWS Lambda applications.

A very interesting research direction would be to investigate how Jolie and/or Choreographies can be used to give structure and avoid errors when programming AWS Lambdas.


Hybrid Microservice-Serverless Architecture

Explore which problems and structural/interaction patterns better fit within a microservice architecture and, (contrarily?) which better fit within a Serveless architecture. A brief example of this review could be: if I need to model the state of a session of a user, I need microservices because of the continuous access/synchronisation over many programs involved in the same session; contrarily, if I need to filter email messages, I can separately analyse protocol headers, text, links, and possible included files, I merge all the results processed in parallel to feed an anti-spam filter, hence, serverless seems more fitting for bursting, cascading, filtering processes.

Next, the work on this subject can build on the previous, empirical review to model a tool (language/framework) where programmers specify the interactions in the architecture they have in mind, then the tool analyses the patterns extracted from the specification and synthesises the programs following the architectural style that best fits the specification. Besides the best-fitting approach, the tool has two main advantages. First, it automatises reasoning and decision-making on architectural patterns, which would otherwise require developers to have a deep knowledge and experience on both styles of architectures. Second, it lowers economic barriers to enter the microservice/serverless market, helping developers in implementing the desired system, synthesising the programs (or at least their skeletal structure) following the selected style and related best practices.

Finally, on the contributions above, the tool can be evolved to automatically cluster the programs in the specification of the developers into sub-architectures, following the best-fitting analysis presented above. In this way, the final system synthesised by the tool is an optimised, hybrid architecture where serverless programs and microservices interact.


A step forward: moving Jolie processes between nodes

Starting processes in different nodes of a network is a desirable feature for resource management (wrt the previous paragraphs, to save bandwidth, load- balancing, etc.). In literature [4], the ability to launch new processes (computations) is called weak mobility. In languages/frameworks that support to weak mobility, a process can move (send) some executable code to a location. At reception, the code is executed by either the receiving process, which dynamically integrates it, or by a new thread/process, created on received code. Strong mobility builds on weak mobility by allowing processes to migrate in the network: the code moves along the state of the running processes, which, at reception, can resume their computation.

Some work has been already done on Jolie to support weak mobility [5,6] but supporting stop, move, and resume operations on running processes is an almost unexplored thread of research.

This topic is very open and spans from i) enhancing the Jolie interpreter with the primitives need to support strong mobility, to ii) implementing frameworks that support strong mobility in Jolie, to iii) studying the theoretical implications of supporting strong mobility in the calculus behind the Jolie language [7].


A (further) step forward: strong mobility in Choreographies

This topic builds on the previous one. How can we support strong mobility in choreographies? What properties can we guarantee on processes that move in a choreography? This is a bleeding-edge research topic and requires a good grasping on the theoretical model behind choreographies [8].