Tuesday, November 2, 2010

Plasma crashing upon login after updating the system clock

Many people have just recently switched from DST to standard time, putting their clocks an hour back. This can possibly cause a nasty behaviour in Plasma, due to a bug in KSharedDataCache: the application simply crashes just after logging in.
The bug has already been reported and corrected at the speed of light (kudos to Michael Pyne for the instantaneous reaction), so it will be fixed in KDE SC 4.5.3 and 4.6. If you are running KDE SC 4.5.2 and you do not want to apply the patch in the bug report, you can simply empty your user's cache directory.
Simply go in the directory pointed by cache-$HOSTNAME inside your user's kde configuration directory and remove every file that is located inside.
In openSUSE such directory is /var/tmp/kdecache-$USER, and your kde configuration directory is $HOME/.kde4.

Happy Plasmaing! (or would that word be Plasming? ;-) )

Thursday, May 13, 2010

Web Services for human beings

No, this is not related to *buntu. But this is looong... and now I've got your attention. :-)

Interacting with Web Services usually implies reading some WSDL (Web Service Description Language) document. Unfortunately, WSDL documents are written in XML and can be pretty complicated, leaving the user with no other choice than to use some graphical development tool in order to understand them.

Lately at italianaSoftware we had to handle a lot of Web Services stuff, equipped with long WSDL documents and complex data types. Jolie already had support for the SOAP protocol, but one had to code the interface and data types of the Web Service to invoke by hand. So we started a new project aiming to enable Jolie for the automatic usage of WSDL documents, mainly composed by two parts: a tool and an improvement to the Jolie SOAP protocol. Of course both things are open source and available in the trunk branch in the Jolie svn repository!

wsdl2jolie (whose executable is now installed by default if you install Jolie from trunk) is the newly developed tool in question. It simply takes a URL to a WSDL document and automatically downloads all the related files (e.g., referred XML schemas), parses them and outputs the corresponding Jolie port/interface/data type definitions.
Let us see an example. See this WSDL document for a service that calculates prime numbers: http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl. Reading the raw XML is not so easy, or at least requires some time.
Let us see what we get if we execute wsdl2jolie http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl :

Retrieving document at 'http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl'.
type GetPrimeNumbersResponse:void {

type GetPrimeNumbers:void {

interface PrimeNumbersHttpPost {

interface PrimeNumbersHttpGet {

interface PrimeNumbersSoap {

outputPort PrimeNumbersHttpPost {
Location: "socket://www50.brinkster.com:80/vbfacileinpt/np.asmx"
Protocol: http
Interfaces: PrimeNumbersHttpPost

outputPort PrimeNumbersHttpGet {
Location: "socket://www50.brinkster.com:80/vbfacileinpt/np.asmx"
Protocol: http
Interfaces: PrimeNumbersHttpGet

outputPort PrimeNumbersSoap {
Location: "socket://www50.brinkster.com:80/vbfacileinpt/np.asmx"
Protocol: soap {
        .wsdl = "http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl";
        .wsdl.port = "PrimeNumbersSoap"
Interfaces: PrimeNumbersSoap

which is the Jolie equivalent of the WSDL document. Those ".wsdl" and ".wsdl.port" parameters are the aforementioned improvement to the SOAP protocol: when the output port is used for the first time, Jolie will read the WSDL document for processing information about the correct configuration for interacting with the service instead of forcing the user to insert it by hand.
Now we can just put this into a file, say "PrimeNumbers.iol", and use the output ports we discovered from Jolie code. As in the following:

include "PrimeNumbers.iol"
include "console.iol"

        request.max = 27;
        GetPrimeNumbers@PrimeNumbersSoap( request )( response );
        println@Console( response.GetPrimeNumbersResult )()

That little program will output "1,3,5,7,11,13,17,19,23". The example can be downloaded from this link (remember, it requires Jolie from trunk).

wsdl2jolie acts as a nice tool for being able to use the typed interface of a Web Service from Jolie and for getting a more human-readable form of a WSDL document (its Jolie form).

Another nice feature we get for free from the SOAP protocol improvement is that now MetaService can act as a transparent bridge towards Web Services. Simply call the addRedirection operation with the right protocol configuration (in this case, the ".wsdl" and ".wsdl.port" parameters) and MetaService will automatically download the WSDL document (we also have a cache system for them already in trunk!) and make it callable by clients.
This is a huge step forward for client libraries such as QtJolie: just tell where the WSDL document is and you can already place calls to the Web Service of interest.
Also, by using wsdl2jolie first and then tools such as jolie2plasma one could use the Jolie intermediate representation for transforming a Web Service interface definition into a (KDE) Plasma::Service XML one. With the same trick, one could also write C++ generators for QtJolie and introduce ease and type-safeness to Web Services invocations. I and Kévin sure have things to think about now. ;-)

Beware that the code is still in its early stages. It already works with a lot of Web Services, but we're still improving it. For instance, we currently support only the SOAP document format (which is the one people advise to use, anyway). Patches, comments and reports are welcome in jolie-devel @ lists.sourceforge.net!

Tuesday, November 24, 2009

Discovering Jolie... in italian!

I have just discovered that Simone (Demo) Gentili is documenting his journey about the Jolie language on his blog! As a matter of fact, he's practically translating the Jolie language tutorials in italian!
See his blog here if you are interested in some Jolie lessons in italian.

This is obviously a very nice surprise for us and an important form of contribution, so thank you Simone for your work!

Tuesday, October 20, 2009

Service-Oriented Computing: a new programming paradigm?

The point of this post is to introduce a paper that explains service-oriented computing that can be read by anyone, without requiring too much previous knowledge. The link is in the last paragraph of the post. If you were interested in knowing more about what service-oriented computing is, it could be a good starting point.

The concepts of online service and distributed programming exist since quite some time now, to the point that they evolved into a huge research topic both for academia and the industry. Huge as it is, a lot of different results from different research areas appeared; conferences on Service-Oriented Computing (SOC) were opened; a lot of investments were made.
In the last decade or so it became apparent that new foundations were need in order to build truly inter-operable distributed applications and that ad-hoc technologies were not good enough for the job. Moreover, it was clear how much SOC could benefit from theoretical research for handling its complex inherent problems. New concepts were forged and new languages were made, the most notable result being the set of languages, specifications and technologies that falls under the name of "Web Services".

Today, we reached the point in which we can look back and see that "services" follow common principles (e.g. public interface, protocol descriptions...) and must necessarily address certain problems (e.g. session handling, structured data description and manipulation, interoperability...). The whole thing grew up so much in detail that we may be looking at a new programming paradigm: the service-oriented one. A paradigm that has the concept of "service" as a native element, much like object-oriented programming has the native concept of "object" or functional programming of "function".
This is not something that we just imagined. We see this every day at italianaSoftware, programming solutions for our customers with the JOLIE language. Having a language that allows you to make lightweight services in a matter of minutes and to exploit local communications between them in order to maintain performance can change your point of view: services are not mere bridges between different applications anymore, they can be used (and reused) as the building blocks of a single application.

We tried to express our definition and experience on this new paradigm on a concept paper at YR-SOC'09, which is publicly available online. Here is the link (on the upper right area of the linked page you can find links for the pdf or postscript versions). It is an introduction to service-oriented computing that considers what has been made so far, so you will find links to a lot of existing works inside it. Some concepts may be pretty new to some readers (after all, it was originally meant for an academic audience and contains references to theoretical works), but we are currently interested in enhancing the paper to make it more readable by the casual developer (probably with less references to theoretical works and more comparisons with existing languages and technologies) and put the new version online in the JOLIE website. So, if you read the paper and find some concepts too obscure or you have some doubts or comments (apart what I have already said) or some arguments that you wish would be addressed, please let us know!

Tuesday, September 29, 2009

Jolie and ARM

Last year (yeah, this is one of those "I should have posted this long ago" posts, but better late than never) I received a precious delivery:

Oh, yes! KDE sent me bubble wrap, woohoo! I played with it until its exhaustion, so thank you KDE (and Claudia for handling the delivery, and Nokia for providing the materials)!

After playing with the bubble wrap I discovered that there was something inside it: a shining Nokia N810. My very first ARM device to experiment with. The ARM world is indeed very interesting not only for KDE, but also for the Jolie language; so I started to try installing a working execution environment for Jolie in this little device.

The first try wasn't easy. I needed a working Java environment before trying to install Jolie. Fortunately, the Jalimo project out there has already made all the important steps. So I made contact with them in IRC and I've found people willing to help. Many thanks in particular to xranby, who provided me an almost-ready binary package for getting me started. The result?
Jolie has been tested on ARM, and it just works! The whole process has produced some patches for Jolie too, in terms of performance improvements (loading protocol extensions is now faster than before) and memory consumption.

Wednesday, September 9, 2009

Random thoughts: getting ready for Jolie 1.0 and remote services inclusion in KDE

Jolie is getting into shape for the 1.0 release. This is requiring a lot of work, and whenever we reach our current objectives we feel like improving things even further (every developer likes perfection, the problem is it requires too much time)! Nevertheless, the line for a good 1.0 release has been placed and is getting very near. The two major points we need to address are SSL support (both in SODEP an HTTP) and documentation. By documentation I'm not just referring to the language documentation but also to the source code documentation of the interpreter; the aim is to make the Jolie interpreter more approachable by hackers who want to improve it or want to write an extension (protocols, specifications, hardware support, ...). The 1.0 release will also contain experimental support for XML-RPC.

SSL support is already working and waiting for inclusion (rough edges need to be investigated) in the main source tree. SSL support will particularly benefit B2B applications, which until
now had to get security by wrapping Jolie in SSL containers, and the KDE project, which has just included support for remote services in trunk using Jolie and MetaService as backend technologies. SSL support in Jolie would allow KDE remote Plasma services to encrypt their data exchanges, an essential feature when dealing with sensitive data (though the initial handshake part is already made secure by using Qt).
I must say that the KDE inclusion was pretty quick: it was just one year ago when the Jolie and the Plasma teams met at the first Tokamak and now we already have a first functioning version in trunk. This process required quite a lot of work and skill, from writing a service orchestrator that could dynamically create bridges from Plasma to services using different protocols and technologies onward to the QtJolie gluing layer and the final implementation in the Plasma library. Now we have the basis for constructing even more complex frameworks and applications, and all of this will benefit from the future Jolie static analysis tools that we (the Jolie team) are planning to implement. All of this to say that it really is a pleasure to work with the KDE team: I will be sure to keep in touch as much as possible.

I'm now focusing heavily on source code documentation and polishing (for which I've just made some pretty big commits). Regarding code polishing, I got some help from the FindBugs static analysis tool; you can just ask it to read some Java bytecode and it comes up with a lot of good hints for performance improvements and bug removals. It is really easy to use and it even considers correct resource locking and releasing. Pretty useful if you have old code to maintain or for checking new extensions before merging them.

Ah yes, I should also blog about a lot of other features and the porting of Jolie to ARM-based devices thanks to the Jalimo project... but that's for other blog posts!

Tuesday, February 24, 2009

RFC: Service-oriented Training & Hacking session at Akademy 2009

It is some time that I'm thinking about Akademy 2009, and how to make people aware of the potential the integration of Plasma and Jolie are going to bring. The following is what I came up with, and from some early discussions it really looks like something worth doing. Please share your thoughts and comments on this.

The idea is to make a (workshop-like) session about the service-oriented world, with pragmatism in mind. aseigo and ervin have been coerced into helping. It'd be composed by two parts, training and hacking.


The training part would touch these topics (not necessarily in order):
- the Service-Oriented Computing paradigm: what is it, and how can we use it?
- how to exploit the service-oriented paradigm through the Jolie language.
- bridging Jolie and Qt with kevin's latest cool library
- the Plasma::Service+MetaService API explained. Service-oriented plasmoids!
- how to make powerful service compositors/orchestrators in Jolie, and use them as backends for plasmoids or $insert_your_app_here.
- use cases and surprises (?)
- questions and answers


Everyone starts his editor of choice and starts hacking on some service-oriented UI/Plasmoid/etc, getting help and sharing ideas.
It will be an excellent occasion to improve the framework too (not only the C++ libraries but even the Jolie framework itself, as I'll be there), as there will probably be necessities that could be implemented as a Jolie protocol or some other extension.

What I'd like to have are ideas and comments about this. Is there any topic you'd like to be covered in particular? Questions to be answered?

Of course it would be nice to have plasma developers attending, along with any other people interested in integrating jolie/service-oriented computing in their application or framework.

So, dear reader, would *you* attend? =)