Interview: JOLIE and Service-Oriented Computing Explained

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!