Choral is a language for the programming of choreographies. A choreography is a multiparty protocol that defines how some roles (the proverbial Alice, Bob, etc.) should coordinate with each other to do something together.
Choral is designed to help developers program distributed authentication protocols, cryptographic protocols, business processes, parallel algorithms, or any other protocol for concurrent and distributed systems. At the press of a button, the Choral compiler translates a choreography into a library for each role. Developers can use the generated libraries to make sure that their programs (like a client, or a service) follow your choreography correctly. Choral makes sure that the generated libraries are compliant implementations of the source choreography, making programmers more productive, and preventing them from writing incompatible implementations of communications.
Choral is currently interoperable with Java (and it is planned to support also other programming languages). Choral is compatible with Java in three ways: 1) its syntax is a direct extension of Java (if you know Java, Choral is just a step away); 2) Choral code can reuse Java libraries; 3) the libraries generated by Choral are in pure Java with APIs that the programmer controls, and that can be used inside of other Java projects directly.
I am part of the Choral team, working on the theory behind the language and its development.
Serverless computing is a Cloud development paradigm where developers write and compose stateless functions, abstracting from their deployment and scaling.
APP is a declarative language of Allocation Priority Policies to specify policies that inform the scheduling of Serverless function execution to optimise their performance against some user-defined goals.
APP is currently implemented as a prototype extension of the Serverless Apache OpenWhisk platform.
I am one of the main contributors in the design of the APP language and helped in the supervision of its development.
It is complex to predict how the usage of a given Virtualisation Technology (VT) implementation (e.g., specific virtual machines, containers, etc.) can impact on the performance of a deployed Cloud application.
VTMark is a semi-automatic open-source benchmarking suite that DevOps can use to orient when looking for the best-performing VT w.r.t their application profile.
VTmark assembles off-the-shelf tools for benchmarking the different resources used by applications (CPU, RAM, etc.); for example, we used VTmark to report the benchmarks of 6 of the most widely-adopted VTs in the Cloud market.
I worked on the inception of the project and contributed to the supervision of its development.
AIOCJ is a choreographic programming language for developing adaptive systems. Distributed programs specified in AIOCJ are programmed from a global point of view and projected to singular entities that, distributed and run in parallel, enact the global behaviour.
Programs written in AIOCJ are deadlock-free by construction and can adapt at runtime. A developer can specify which fragments of the global interaction can change. At runtime the projected entities can substitute (update) marked fragments with new ones provided by compliant repositories. AIOCJ programs always update in a coherent way, which preserves deadlock freedom.
Since AIOCJ choreographies are projected to Jolie programs they can also make use of functions provided by external services.
Jolie is a general-purpose service-oriented programming language. It brings elegance, simplicity, and pragmatism in the development of modular, integrated, distributed, and concurrent applications.
The development of the Jolie language is based on a positive loop between formal theory and practical requirements. One of the strongest values of Jolie is the freedom it gives when designing distributed solutions. Depending on the requirements and the constraints of a specific problem, a programmer can choose whether to build a basic, immediate, yet lightweight solution to integrate applications from different domains or to model the solution by exploiting the language’s advanced composition primitives, forging an highly modular distributed system.
Jolie programs strive for minimality, the same minimality advocated by the microservices architectural style.
The JIoT project aims at integrating IoT-related technologies into the Jolie language.
The Internet of Things (IoT) promotes the communication among heterogeneous entities, from small sensors to Cloud systems. However, this is realized using a wide range of communication media and data protocols, usually incompatible with each other. Thus, IoT systems tend to grow as homogeneous isolated platforms—usually referred as “IoT islands”—, which hardly interact.
To achieve a higher degree of interoperability among disparate IoT platforms, the JIoT project investigates how abstractions suitable for service-oriented and microservice architectures can aid integrating disparate IoT islands.
Jolie supports the main technologies from Service-Oriented Computing, such as TCP/IP, Bluetooth, and RMI at transport level, and HTTP and SOAP at application level. As first technical result of the project, we integrated in Jolie the two most adopted protocols for IoT communication, i.e., CoAP and MQTT.
The integration of IoT-specific protocols into the service-oriented setting of Jolie poses some interesting challenges, the two main being i) the integration of unreliable channels (UDP/CoAP) and ii) bridging the simple request-response communication style of Jolie with the peculiarities of the Publish/Subscribe communication pattern.
I am one of the main contributors both in the design and development of the project.
The Tquery project is a query framework integrated in the Jolie language for the data handling/querying of Jolie trees.
Tquery is based on a tree-based instantiation (language and semantics) of MQuery, a sound variant of the Aggregation Framework, the query language of the most popular document-oriented database: MongoDB.
Tree-shaped documents are the main format in which data flows within modern digital systems—e.g., eHealth, the Internet-of-Things, and Edge Computing.
Tquery is particularly suited to develop real-time, ephemeral scenarios, where data shall not persist in the system.
Key element of Mobility as a Service (MaaS) is that MaaS operators can aggregate solutions of multiple transport companies to deliver dynamic, transparent multi-modal travels to their users, who experience transportation as managed directly by a single operator. To enable MaaS, within the Smart Mobility for All EIT Project, we created SMAll, a platform (and its related wiki) where providers of transport solutions can trade their information as well as other services for mobility, like booking, payment, and travel assistance, on demand. SMAll includes the latests technologies in terms of provision, deployment, scaling, and maintenance of applications: microservices and containerisation. In addition, SMAll supports the creation of a federation-based MaaS market, where a SMAll instance is a hub for local (e.g., city-wide) transport operators and geographically sparse SMAll instances can federate to form a global market for MaaS.
To test SMAll, we also implemented pilots within the platform, collaborating with the Department of Transportation of Emilia-Romagna region, Lepida S.c.p.A., and Foundazione Bruno Kessler.
I am both one of the designers of the SMAll platform and one of the main developers of its prototype.