During Akademy 2008, we sat down with Fabrizio Montesi who's working on
JOLIE integration in KDE (and Plasma in particular). He
explained the mechanics of the technology and what it can do for KDE. Read on for the
interview.
Hi Fabrizio! Can you introduce yourself?
Hi! My name is Fabrizio Montesi, I'm Italian and I work as a computer professional. Recently I
have founded (together with my colleague Claudio Guidi), italianaSoftware s.r.l., a company that centers its
business around service-oriented software solutions made with JOLIE.
At Akademy you gave a talk about JOLIE, the technology you are working on. Can you
explain the purpose of JOLIE?
Well, JOLIE is a programming language for
service-oriented computing. It is mostly about communication between applications. Usually,
applications have communication mechanisms within themselves - in Qt this is done with the
signal-slot mechanism. What it does is essentially this: suppose you have a button, and you click
it. That button then tells a part of the application to start doing "its thing", e.g. display an
image. Simple.
Now, you might want to have something happen in another applicaton if you hit that
button; that's covered in the software world as well, e.g. on Linux/UNIX by DCOP and D-Bus, on
Windows by DCOM. The problem is that these technologies are pretty specific and each one has its
own set of limitations (among which the most prominent is that some don't work over networks).
JOLIE tries to overcome all these limitations and offer a very simple solution for doing what
should indeed be simple: "just send this message to that application in that computer".
So JOLIE is like a network-enabled D-Bus?
Well, no, it's more than that. D-Bus is a framework designed to enable application integration in
the desktop. JOLIE is a fully-fledged programming language for managing service-oriented
architectures and technologies. With JOLIE, you can write flexible service "orchestrators" and
compose other services, independently of their technology, in order to gain sophisticated
functionality.
Now that sounds interesting, "orchestrators" and composition of services, but what does
it mean?
Let me explain this by giving an example. Say that you want to write an application which allows
you to buy stuff at stores. You already have services for accessing your bank and said stores,
but you lack the application that actually composes these services to make the money transfer and
make the store order for you. Then you write an "orchestrator" to combine the services, which
would coordinate the services in order to do what you wanted. Note that a JOLIE orchestrator is
very easy to write and can make use of any store and bank service that are based on a technology
supported by JOLIE (like, for instance, Web Services, REST, and so on).
Which is what JOLIE is all about - a generic programming language for programming any kind of
service or service-oriented architecture, independent of the underlying protocols (JOLIE
abstracts the communication away, e.g. D-Bus apps can communicate with a SOAP-based service
through JOLIE). And of course, this is incredibly easy to use. In most other languages you'd find
it is very hard to write service-oriented code, but JOLIE is all about services. Of course it
also provides the normal flow control functions (like the if-else, if-then, while, for, foreach
statements), and it adds some specific and powerful tools to handle distributed workflows. The
latter help in compensating for network lag and help the programmer to handle complex
asynchronous communications. And finally, JOLIE is very safe while doing this, due to the
academic work being done.
So people can quickly write orchestrators to let any number of services work together in
any way they want. Now you mentioned academic work, can you tell us a bit more about that? This
is actually a research project, right?
Yes, it is. Writing distributed apps is very difficult to get right. JOLIE is based on SOCK, a
process algebra for service-oriented computing, so you can make mathematical proofs on JOLIE
applications. For example, we are currently developing a tool for checking distributed systems
for possible deadlocks. Another advantage is that you can be sure your application does what it
is supposed to do if something goes wrong in some part of your distributed workflow.
Let me give an example of that last point as well. Say, in the previous example, you're ready to
order the bank to transfer the money and receive the store receipt. You want this to go fast, so
you do two things at once: start the money transaction and wait for the store receipt. Say that
the waiting-for-receipt activity receives an error. In that case, the money transaction must be
cancelled: you don't want to lose your money for a product that will not be sent to you, right?
But you don't want to cancel it at some unknown point. You want to ensure nothing
happened to your money at all. So you add a little "revert when an error comes in" thing to the
money transaction code. Now, in case of an error from the store, JOLIE will guarantee three
things:
- if no money has been transferred yet, the transaction won't begin at all;
- if the transfer has already started, JOLIE will allow it to finish, then start the reverting
action;
- if the transaction has finished already, JOLIE will revert it right away.
All this is based on lots of mathematical work to ensure and prove that this works properly. This
is a good example of how SOCK is useful in our development process. When we face a very
complicated and general problem, we can first build a mathematical framework for solving that
problem in SOCK.
After developing the whole theoretical framework and proving that it works, we transfer the
results into JOLIE.
Interesting. So this is an implementation of sound, theoretical work. But why in
KDE?
Well, I wanted to bring the benefits of service-oriented computing to desktop users. There are
many services out there on the web and in user computers (every D-Bus-enabled application can
indeed be seen as a service), but they don't communicate with each other. JOLIE can help with
this. There are a few commercial frameworks which do comparable things, but nothing free, nor
very good and complete. Now for this to work, I needed to find an organization which would be
interested to work on it. I needed a real, open community to work with, so Vista and Mac OS X
were off the list... Vista wouldn't have been very good from a technological standpoint either. I
further needed the community to be flexible, interested and pro-active.
I was following the evolution of open desktop technologies since a long time. KDE has some
amazing, cutting-edge technology, and you don't write that kind of stuff without many open
discussions. And from reading the blogs I was convinced this community works great, is open and
flexible, exactly what I was looking for. For me, GNOME seemed much less flexible, both in terms
of people and technology. More importantly, KDE showed with the KDE4 series that the project is
not afraid to take a step towards innovation, regardless of the hardships that you can meet along
the way.
And with Plasma, I was sold: it felt like a natural choice. JOLIE is based upon a philosophy
which emphasizes generic solutions over specific ones in order to create something as flexible
and powerful as possible. The same applies to Plasma, and as i've seen in KDE development, it is
the vibe you see in pretty much all of KDE.
OK, so you decide to work with us. How did that go?
Well, I sent an email to Aaron Seigo and he answered back enthusiastically. He happened to have
been thinking on very similar topics, but he bumped into the issues JOLIE is built to solve -
it's hard to write, compose and communicate with services. On top of that, there are a lot of
different communication mechanisms currently used by services all around the world: how to be
able to use all of them? These issues are far from trivial, so Aaron was happy to work with us to
take advantage of JOLIE. He invited me to come to Tokamak, the Plasma meeting, which I and
Claudio did. There we (JOLIE and Plasma teams) found that we clearly had matching ideas. JOLIE
and Plasma looked like the perfect match to offer users a flexible and powerful service-oriented
experience. So we started a twofold collaboration, aimed to unite the pragmatic world of KDE and
the academic world from which JOLIE comes.
Cool. And now you're at Akademy... How did you end up here, and what do you think about
it?
Well, Aaron and Kevin Ottens invited me to send a talk proposal for Akademy, which I did. I must
say Akademy is very interesting, though also very tiring. You find so many great people to speak
with here, and I actually did that for the whole time. I've never had so many well informed
questions before, too... before and after the presentation! Actually, I think the majority of
questions I had during all the presentations I ever gave were asked at Akademy. Of course, this
is because there are so many knowledgeable, interested developers here. Many people here will (or
already have) actually put some of these ideas to work, so they have questions about it. Getting
so much relevant feedback in an academic conference would be unusual: it is more difficult to
reach technological collaboration between many different and separated projects. So this has been
really great, i've gathered many ideas and issues i'm going to take with me, think about, and
work on. And i've left something to think about for others, too.
From what I understood, there is already some code?
Yes, that's true. We are already writing a Plasma::Service layer which acts as a bridge to
MetaService (a JOLIE orchestrator) on the JOLIE side. This means you can access all services
supported by JOLIE in Plasma. You would have to write an orchestrator to compose services, like
in the previous e-commerce example. But as you can read in my blog, there are some cool code examples. One of them is
Vision, a
tool which can distribute presentations real-time over several computers. That way several people
can view the presentation on their screens synchronized with one another. This even works in a
peer-to-peer way, where each of the PC's can distribute it even further. Look in my blog for
a screencast!
Something else, not available already but we're working on, is exporting data engines from one
system to another. So, for example, the "Time" engine on one computer can be queried as a JOLIE
system from a remote PC. All of this is difficult to do right in terms of security, but opens a
huge number of opportunities. Think about how easy it will become to start writing remote control
Plasmoids, or getting access to a huge amount of information (that of services on the internet)
from your desktop.
Do you have any concluding words for the KDE community?
Yes. i'd like to thank (and praise) the KDE community for its openness. I felt at ease from the
start, met enthusiasm and innovative ideas, and discovered that the people behind the project are
friendly, open-minded and a lot of fun to pass your time with.
During these months I have seen that the KDE project is truly innovation-driven. Open-source and
community openness are what make this possible, and KDE is showing that it is capable of handling
all this (with the KDE e.V., the meetings, and so on). Keep rocking!
Thank you for the interview!
Thank you for interviewing me. And who knows... see you at next Akademy!
Recommandations
)
and reject those that you are not interested in
(
)
