[dot] Interview: JOLIE and Service-Oriented Computing Explained

[Dot Stories]

URL: http://dot.kde.org/1220789755/

From: Jos Poortvliet <jospoortvliet at gmail.com>
Dept: still-from-Akademy
Date: Sunday07/Sep/2008, @05:15

Interview: JOLIE and Service-Oriented Computing Explained
=========================================================

   During Akademy 2008, we sat down with Fabrizio Montesi who's working
on JOLIE [http://jolie.sourceforge.net] 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.
[http://www.italianasoftware.com/], 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 [http://jolie.sourceforge.net] 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;


     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
[http://fmontesi.blogspot.com/], there are some cool code examples. One
of them is Vision
[http://fmontesi.blogspot.com/2008/07/vision-distributed-presentation.html],
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!
 [http://jolie.sourceforge.net/videos/vision-previewer.avi]
     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!