One of the top trending topics at Devoxx BE 2014 (and indeed on Voxxed itself, where we’ve already amassed a small library of resources), microservices will continue to loom large on the radar for 2015. And on that note, today we’re going to take a look at Jolie – billed as the “first” language for microservices.
Jolie is project-lead by Claudio Guidi and Fabrizio Montesi. According to Claudio, the fundamental idea behind Jolie is the aim of simplifying (micro)service oriented programming and, more in general, distributed programming – solidifying SOA principles in a specific domain languages.
Montesi, who currently works as key Jolie developer and maintainer, stepped in to start the open source project some years ago. The Jolie community is, at present, a small group of developers who are implementing it in their own projects, but it’s hoped that the project will grow. Claudio tells Voxxed that Jolie “implements the (micro)service-oriented programming paradigm by proposing a unique linguistic domain (a language) for dealing with all the aspects of service-orientation. In this scenario the main novelty introduced by Jolie is that developers can directly rely on a language for building both architectures and functionalities.”
Whilst Farbrizio commented on Reddit earlier today that in some aspects Jolie does share commonalities with the Enterprise Service Bus, for example, stating that integration is a “central piece” of the puzzle, and it can be used inside an ESB, you shouldn’t regard it as the ESB 2.0.
In our interview, Claudio outlines the following use cases for the technology:
- Fast prototyping: Java developers with a focus architecture design who don’t want to risk losing familiar methodologies can use Jolie for rapidly addressing scenarios where it is not possible to deploy heavy infrastructures for building services, or they could use it for fast prototyping part (or all) a system.
- Distribution by design: Developers who are unfamiliar with distributed architectures could start using Jolie from the start for a full immersion from the outset, continuing to use it for future systems deployments.
- Teaching: Teachers could use Jolie as a sort of reference for dealing with distributed architecture programming and provide students with an easy tool for exercises and tests.
With Jolie, developers can build orchestrators and simple services without changing technology because, as he Claudio puts it, “both orchestrators and simple services are just services… A lot of beginners in programming can immediately start to develop their own distributed architecture without investing too much time in understanding technologies and languages. Just one language.”
It’s interpreted through a Java based system, selected due to the large community, cross-platform nature of the language, and huge repository of easily accessible libraries and tools. The team also liked the way that the Javasphere is “tightly coupled” to their application domains “because it usually deals with services in general and we could benefit from their contribution.”
Claudio is well aware of the monster task he’s set himself with getting Jolie off the ground, and still has a good many aspects of the service to deal with – however, the technology is now at the point where it’s ripe enough to be shared with the wider developer community, and hopefully, attract some extra hands to the initiative.
With its roots in Service Oriented Architectural concepts, Jolie employs both the design concepts of SOA and the lightweight nature of microservices. For example, with Jolie you can find primitives as correlation sets which are inspired from WS-BPEL. Moreover, Claudio explains, there are strong primitives for dealing with fault handling, termination handling and compensation handling which are usually adopted for dealing with failures in a distributed environments.
In Jolie, the programming is inherently distributed, thus developers don’t need to worry about how they deploy their services. Claudio adds that, “You can decide how to deploy them later dependent on the load they must deal with, the network latency you have, and so on. Thanks to the embedding primitive, you can also deploy everything as a monolithic application if you need, just re-bind your services and you are done. You could postpone deployment decisions after the development phase, that is interesting from my point of view.”
Looking at Jolie, it’s still very much an academic exercise in many respects, but Claudio is confident that the project will ultimately make the leap to the enterprise. His reasoning for this is twofold. Firstly, the team is starting-up a company that is bringing Jolie in enterprise scenarios. In particular, he states, they are at the present focusing on “systems for integrating third party applications with SAP. Indeed, we are able to interact with SAP as it is a microservice. “SAP As a microservice” could be a funny slogan for this approach but it is just the usage of a new word for saying SAP “connector”. The fundamental thing is that it is (micro)service oriented, it is distributed and it works fine, this is what it counts.”
Second, he cites “the long life collaboration between academy and industry through the language over the time. The language indeed, has been developed starting from an operational semantics defined with a process calculus.” This lends Jolie “coherence and elegance” and, he says, “paves the way for research both from an academic point of view and an industrial point of view. We are in the middle between academy and industry so we can see positive and negative points from both sides, we are trying to get these two “worlds” more connected as possible in order to take advantages, in terms of knowledge and innovation, from both sides.”
If you’re interested in having a play with Jolie and seeing what it can do for you, you can download it here.