Proposals

Overview

Proposed projects are divided into the following main categories:

  • Tuple Based coordination , where students may contribute in several ways to our software artifacts concerning the tuple based coordination, i.e.:

  • Logic Programming as a Service (LPaaS) , where students may contribute in several ways to our software artifacts concerning the LPaaS ecosystem

  • Blockchain , where students may contribute in several ways in order to improve their (and our) understanding of the Blockchain model and technology

  • [Byzantine] Fault Tolerance ([B]FT) & State Machine Replication (SMR) , where students may contribute in several ways in order to improve our understanding of the BFT & SMR models and technologies

  • Language and frameworks for Distributed Systems (DS) or Agent Oriented Programming (AOP) , where students may contribute in several ways in order to create or improve new languages or toolkits within the scopes of DS, Coordination, and AOP

    • Projects in this category may rely on one or more of the following frameworks:

  • Simulation of situated agents : where students may contribute by creating novel incarnations for the Alchemist simulator

  • Technology Know-How : where students may contribute exploring the functioning (and possibly the internal structure) of one or more real-world technologies

The "Tuple Based coordination" category

This cathegory comprehends the following projects

  1. Designing and implementing a RBAC access control feature for TuSoW, to be enforced by means of an authentication and authorization layer to be injected into the current model and implementation

    • The implementation should rely on standard technologies such as SSO or OAuth

  2. Designing and implementing a variant of TuSoW supporting the replication of tuple spaces on several distributed machines

    • This may also mean creating/looking for a Storage Layer for TuSoW to be injected into the current model & implementation

  3. Designing and implementing a variant of TuSoW supporting the sharding of tuple spaces on several distributed machines

    • This may also mean creating/looking for a Storage Layer for TuSoW to be injected into the current model & implementation

  4. Designing and implementing a server-side interface for LINDA (or TuSoW core) to be wrapped within some IoT ready interface base on:

    1. gRPC ,
    2. or MQTT ,
    3. or AMQP

    (notice that these are actually three different projects)

  5. Designing and implementing a client-side interface for TuSoW supporting two or more of the follwing platforms:

    1. JVM (Java, Kotlin, Scala, etc)
    2. .NET (C#, F#, VbNET <-- please don't)
    3. JavaScript
    4. Python

    (notice that these are actually different projects)

  6. Designing and implementing an observability module for TuSoW enabling the implementation of a Web-based monitoring (graphical) interface

  7. Designing and implementing an Android -based porting of TuSoW supporting replication of tuple spaces among several devices, possibly interconnected by means of Bluetooth or Wifi-Direct

  8. Designing and implementing an Android -based porting of TuSoW supporting federation of tuple spaces à la LIME among several devices, possibly interconnected by means of Bluetooth or Wifi-Direct

  9. Understanding, implementing, and injecting the notion of tuple centre into TuSoW, possibly creating a novel implementation of the ReSpecT language

The "LPaaS" category

  1. Completely rewriting the current Java EE based source code using Vert.x or some other lightweight, micro-service oriented library or framework. The novel implementation should include at least:

    • an improved modularization of the Knowledge-Base Layer
    • a suite of fine grained unit tests

    Notice that the novel implementation should anyway adhere to the LPaaS Swagger Specification

  2. Designing and implementing an observability module for LPaaS enabling the implementation of a Web-based graphical interface

  3. Designing and implementing a client-side interface for LPaaS supporting one of the follwing platforms:

    1. .NET (C#, F#, VbNET <-- please don't)
    2. Python

    (notice that these are actually different projects)

Furthermore, we are also interested in students designing and developing an unbiased and non-trivial usage scenario for LPaaS. You can propose some.

The "Blockchain" category

No specific project here, but just some ideas you can use as a starting point when proposing a project of yours.

We have four different rearch interestes concerning blockchains:

The "BFT & SMR" category

Projects in this category follow a common pattern:

  1. Students choose a consensus algorithm from the list below,
  2. They study the corresponding paper / reference and try to understand the consensus algorithm's functioning
  3. They create a proof of concept implementation it using a technology of choice
  4. They test the consensus algorithm's robustness agains crash and byzantine faults

There is an implic step hidden into the procedure above: consensus algorithms are usually aimed at implementing some sort of SMR system (e.g. a replicated DB). Even if the goal of a project in this category is to study & implement a consensus algorithm, students may need to actually use it in order to test it. To do so they will have to create a simple SMR system, like, e.g. a replicated Key-Value store supporting at least two operations: put and get .

Students may choose any of the following consensus algorithms:

Overviews and surveys are available in order to perform a quick evaluation and comparison among the protocols above:

Finally, the following readings may of interest for who is interest in understanding the many impossiblity results affecting the distributed consensus:

The "Language & frameworks for DS or AOP" category

  1. Design and implement a plugin for Swagger's Codegen aimed at generating Vert.x stubs starting from a Swagger specification file. Differently from phiz71 's plugin (which may be used as an example or starting poing) the novel plugin should also support Web Sockets and JWT authentication, other than building stubs adhering to the style proposed in Labs 6-8

  2. Design and implement a Domain Specific Language aimed at easing the development of agents adhering to the AOP framework developed in Labs 9-10

    • It is possible to use any one among the following DSL engineering technologies: Xtext, MPS, ANTLR
    • Notice that this project may require some reactoring effort affecting the code provided in Lab 10

  3. Improving and extending Lab 10's AOP framework, making it support all FIPA protocols , similarly to JADE

The "Simulation of situated agents" category

  1. Design and implement an Alchemist incarnation aimed at simulating situated tuple spaces and, possibly, the Spatial Tuples model
  2. Design and implement an Alchemist incarnation aimed at simulating situated tuple centres
  3. Design and implement an Alchemist incarnation aimed at simulating situated Agents

The "Technology Know-How" cathegory

Projects in this category follow a common pattern:

  1. Students choose a technology from the list below,

  2. They must study it and understand its purpose & functioning, possibly looking for scientific paper describing it

  3. They must undestand how the technology setup works and it is deployed in a real-world scenario

    • Docker Swarm may be useful in some cases
    • Such information must be included into the final report

  4. They must test it, possibly creating some non-trivial testbed scenario

    • It is not sufficient to just copy & past examples from the Web
    • The test bed scenario must be propertly designed in order to reveal the technology pros and cons

  5. They must stress it, possibly creating some testbed pushing the technology out of its comfort zone

  6. They must produce a detailed report describing

    • the technology,
    • its reference model (if any),
    • the assumption it relies upon,
    • the tests performed and their rationale,
    • the problems it solves
    • the problems it DOES NOT solve
    • etc

aboutllowing technologies: about

Notice that projects in this category are quite different. Here, we only expect students to produce some non-trivial testbed + some other code examples as software artifacts. The real goal of this sort of projects is to condensate into some useful and written form the knowledge related to a particular technology. Because of this, the final repor must be very detailed and properly written, without assuming the reader have any prior knowledge concerning the technology presented into the report . For this reason final report have no page limitation in this category .

Notice that technicalities are not the only thing that matters . This is why we ask you to reason about a technology, and think about:

  • why should people use it?
  • why people should NOT use it?
  • does it scale?
  • etc.

As a rule of thumb consider the following statement:

if your report does not present any problem of the target technology, you are probably missing something