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.

Training

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

Hacking

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.
It'

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

Solid, UPnP and Jolie

Lately there's been a lot of interest about UPnP and its application in KDE.
These days I'm speaking a lot about these things with Kévin "ervin" Ottens w.r.t. the Solid project. Even at Akademy 2008, Kévin suggested to me that it would be nice to have a UPnP protocol implementation in Jolie. There's been some discussion since there, but we just couldn't afford to implement it because of lack of resources (people/time). GSOC is approaching and this item is among the ideas for KDE, so some explanation is probably a good thing to offer. The aim of this post is to offer such an explanation, but given that I'm so familiar with Jolie I could miss some points of interest... so please *ask* if *you*'ve got doubts about this (like "I didn't understand why that point would be better than doing this other thing...", or "Did you think about using this and/or this?..").

Jolie is currently being integrated in KDE and will become a runtime dependency for activating Plasma on the network (making plasmoids in different machines communicating with each other, or with external services, etc.). Enabling Jolie to use UPnP would mean to re-use this dependency and all the technology developed until now (QtSodep, service composition, easy data manipulation etc.) for giving Solid (capital S) a solid backend (lower-case s ... yes, it's a pun! ha ha... *cough cough*) to exploit all the UPnP devices out there. Add to this the service-oriented programming capabilities of Jolie and you obtain a complete framework for making powerful orchestrators out of your UPnP network and even making Solid itself a UPnP service provider.

A note about the implementation: nowadays Jolie offers two ways for implementing a new protocol: you can write it in Java or write it in Jolie itself. We offer these two possibilities because it's useful to distinguish between low-level and high-level protocols, and to use the right tool for the right job.
The first kind deals with low-level byte streams manipulations, e.g. binary protocols, and Jolie is not suited to do that; good examples are any binary protocol, or even HTTP.
The second kind is more about manipulating data structures in an abstract manner; for example, suppose that you need to implement a new protocol on top of XML: being able to exploit Jolie's syntax for XML manipulation is usually a winner.

openSUSE package for Jolie

The title of this blog post really leaves a trail of mistery.

Today, under a not-so-excellent-but-still-not-too-bad weather, I've decided to enter the dark school of packaging. The results can be found here: http://download.opensuse.org/repositories/home:/fmontesi/openSUSE_11.1/

This means that now we've got a one-click installer for Jolie in openSUSE 11.1. Enjoy!

P.S.: in the website official download page there's a better looking button ;)

Update: andred in #plasma made me notice that many people are still using openSUSE 11.0. Jolie should work flawlessly even there, but I've got no mean to test it. Anyway, my repository now contains packages for openSUSE 11.0 and openSUSE factory, too. I must say that openSUSE build service is one fantastic piece of software!

Major distribution bug in Java support for unix sockets?

If you're trying to use local unix sockets using libmatthew with a Java program (as it's the case for JOLIE and thus MetaService), you might get a similar error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/libunix-java.so: /usr/lib/libunix-java.so: undefined symbol: __stack_chk_fail_local

I get it using the libmatthew-java package from openSUSE 11.1. It looks like Ubuntu users are suffering of the same problem (there causing a bug in dbus-java). If you read their bug thread, you'll find that they appoint the problem to a compilation flag. I've tried to simply download libmatthew sources from here and compiling them: they just work (except that you have to fix the Makefile by substituting the java compiler flag -source 5.0 with -source 1.5).

This problem really looks worth going into some official update repository for each bugged distro. I have already filed a bug for openSUSE, but I cannot confirm it for other distros. Could *you* (dear reader) check for it and send an appropriate bug report? =)

UPDATE: the bug has been fixed! Thanks to all the people involved! =) If you're using openSUSE 11.1, you can fetch a backport from the Java repository (http://download.opensuse.org/repositories/Java:/packages/openSUSE_11.1/).

MetaService enters the main source tree

Today I have moved MetaService from JOLIE's playground source tree to the main source tree, the one that gets installed when you type ant install.

A short description for people that do not know what MetaService is: MetaService is a JOLIE service that allows you to dynamically bridge applications that speak different protocols (sodep, soap, http, etc.) or use different communication transports/mechanisms (sockets, local sockets, Java RMI, etc.). It has been developed as an answer to the Plasma project's needs to have a transparent means to introduce Plasma to the Service-oriented world. The project turned out to be so useful that I have built a Java library for interacting with and dynamically loading it (metaservice-java, to be found in trunk/support/metaservice-java) which we, as italianaSoftware, have already used in the scope of web application development (I can not say much more on this topic... yet ;).

As a bonus, *nix users get a launcher script for MetaService when installing JOLIE with ant install. Just type metaservice -h and a help screen will welcome you.

The script supports passing MetaService's input port location and protocol as parameters. This means that for KDE launching MetaService just became a matter of executing something like:

metaservice localsocket:/tmp/ksocket-$USER/metaservice

Hooray for simplicity!

Jolie Jobs (now with Plasma)

The Jolie web site now sponsors a "Jobs List", which can be found from the Contribute page, also known as "What we lack for world domination". The list features some Junior Jobs, so it's a good starting point for people that are looking for ways to start contributing to Jolie. We are continuously filling in new jobs (there's *always* something to do, as in every project ;), so be sure to refresh it if you're interested. If you don't find anything that interests you, remember that you can always post to the mailing list. =)

Now that JOLIE supports message types, it is feasible (and not too hard) to make automatic generators for Plasma::Service description files. These jobs are listed, so if someone wants some cool tool for automatic type-safe code generation between Plasma and JOLIE sooner rather than later and to learn something more about how Plasma and JOLIE communicate, this is a good occasion to jump on the JOLIE<->Plasma revolution train. ;)

Compiling JOLIE from sources in Windows now easier

For everyone using Windows out there: compiling JOLIE from sources in Windows is not a pain anymore!

I've patched the build system so that it recognizes the running operating system and installs the appropriate launcher script (a shell script in *nix and a .bat script in Windows), so now having a working environment is far less "manual" than before. You can find the updated guide here (Windows -> From sources).