fmontesi's blog

Plasma crashing upon login after updating the system clock

2010-11-02T09:52:00.001+01:00

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? ;-) )

Web Services for human beings

2010-05-13T15:37:00.007+02:00

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 {
        .GetPrimeNumbersResult?:string
}

type GetPrimeNumbers:void {
        .max:int
}

interface PrimeNumbersHttpPost {
RequestResponse:
        GetPrimeNumbers(string)(string)
}

interface PrimeNumbersHttpGet {
RequestResponse:
        GetPrimeNumbers(string)(string)
}

interface PrimeNumbersSoap {
RequestResponse:
        GetPrimeNumbers(GetPrimeNumbers)(GetPrimeNumbersResponse)
}

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"

main
{
        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!

Discovering Jolie... in italian!

2009-11-24T17:00:00.000+01:00

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!

Service-Oriented Computing: a new programming paradigm?

2009-10-20T18:19:00.006+02:00

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!

Jolie and ARM

2009-09-29T09:48:00.001+02:00

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.

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

2009-09-09T16:26:00.009+02:00

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!

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

2009-02-24T13:20:00.008+01:00

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

2009-02-20T09:15:00.002+01:00

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

2009-02-11T14:08:00.003+01:00

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?

2009-01-23T11:28:00.006+01:00

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

2009-01-21T12:21:00.004+01:00

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)

2009-01-20T12:05:00.005+01:00

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

2009-01-19T15:33:00.006+01:00

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).

JOLIE meets Message Typing!

2009-01-14T19:00:00.006+01:00

I've just finished to adapt and merge into Jolie's SVN the awesome work derived from Elvis Ciotti's thesis. The job required some time, but we are definitely improving our development process with people that decide to make a thesis on JOLIE (it required much more than a day in the past); I think that we can improve even more, but that's another story. Elvis made some testing scripts, too, so I'm pretty sure that my refactoring did not introduce any regression and testing the result was a painless process. Way to go, Elvis. =)

So, message typing: what's that? Let's have a preface and then look at an example!

The problem

In a service-oriented world applications communicate with each other. An application (say, A) can communicate with another one (say, B) by using the interface exposed by the latter. An example of an interface is "I accept messages for an operation called sum. You shall send me two numbers and I will return their sum to you.".
The problem here is that A and B are completely separated applications. They could even have been made with different programming languages. What does assure us that A is gonna respect the interface specs of B? Unfortunately, nothing does. We do not have any means to do that, as A is a black box to our eyes: we can not peek inside. We can only hope A has been statically checked against our interface before being run, or that A hasn't been purposefully made wrong to mess B up.

So what can we do?

When B receives a message, it could check at run-time that it conforms to the interface. If not, it should discard it immediately. That way we are sure to be safe, and that B's internal program doesn't get unexpected data.

Example

Let us implement B with Jolie's syntax for message types. The code would look as the following:


type SumRequest:void {
   .x:int
   .y:int
}

inputPort B {
Location: "socket://localhost:8000"
Protocol: sodep
RequestResponse:
   sum(SumRequest)(int)
}

main {
   sum( request )( result ) {
       result = request.x + request.y
   }
}

In the example B accepts messages containing two sub-nodes, x and y. An XML representation of a valid message is the following:


<request>
   <x>5</x>
   <y>10</y>
</request>

Jolie will take care that B doesn't receive anything that doesn't conform to SumRequestType. Clients sending a malformed message would receive a "TypeMismatch" fault in return.

Jolie types are pretty expressive, you can also play with the number of occurrencies. An example of a more complex type:


// A type describing an article
type Article {

// We want at least one author, but no upper limit
   .author[1,*]:void {
       .name:string
       .surname:string
       .age:int
   }

// We accept from 5 to 15 pages
   .page[5,15]:string

// ? is a shortcut for [0,1], i.e. giving a summary is optional
   .summary?:string

/* .metadata is left completely free,
 * type checking is not performed on it
 */
   .metadata:any { ? }
}

The code has just entered so it still may have some bugs, but it works already with some advanced tests I've conducted with current SVN.

Enjoy! =)

Jolie's new website is up!

2009-01-12T17:47:00.003+01:00

JOLIE has a new and shiny website: www.jolie-lang.org

The new site has a wiki which we are filling in with a lot of information, minute by minute. Some tutorials are already final and we are preparing demos and packages of source code examples.

This step required some effort and time, but we now have a serious and stable basis to build our knowledge base upon (the backend of the website is quite powerful and allows for easy administration and data versioning).

The mailing list and IRC channel are already active since some time, respectively jolie-devel@lists.sourceforge.net and #jolie on freenode, providing the means for asking about anything related to JOLIE and getting the attention of the JOLIE team.

Jolie meets JavaScript

2008-12-15T18:26:00.005+01:00

Starting today, JOLIE services can exploit the JavaScript language!
As usual we are not speaking of mixing JOLIE code with another language, which would result in incomprehensible JOLIE programs. We are instead speaking of the insertion of another language in JOLIE's service-oriented paradigm, by means of the embedding mechanism (which we are detailing in our new, shiny tutorials, to be published really soon).

Embedding a JavaScript service goes like this:

// main.ol

include "console.iol"

// Standard JOLIE service declaration
outputPort Math {
RequestResponse: sum
}

embedded {
// We load our JavaScript file as the JS service
JavaScript:
    "mathservice.js" in Math
}

main
{
 // Now we can call JS as every other service type supported by JOLIE
    with( request ) {
        .addend[0] = 2;
        .addend[1] = 4;
        .addend[2] = 1;
        .addend[3] = 3
    };
    sum@Math( request )( response );
    println@Console( response ) // Will print 10
}

The JavaScript API for accessing structured JOLIE data is the same as the one for Java. Let us see how the Math service is implemented:


// mathservice.js

function sum( request )
{
    var addends = request.getChildren( "addend" );
    var total = 0;
    for( var i = 0; i < addends.size(); i++ ) {
        total += addends.get( i ).intValue();
    }
    return total;
}

Voilà! Simple, isn't it?
Support for other scripting programming languages will be introduced in the future, stay tuned! =)

Today, in JOLIE...

2008-11-05T18:09:00.004+01:00

Build system
JOLIE's SVN contains now an ant-powered build system that compiles all the protocols, extensions and libraries and then is able to install the resulting runtime environment in your computer in a painless way. Painless like "just type sudo ant install in trunk/ and you're done".
The system is still beta-ish, but it's been tested by some people other than me. So now installing JOLIE from SVN is just:

svn co https://jolie.svn.sourceforge.net/svnroot/jolie/trunk
sudo ant install

Warning: I still have to implement ant uninstall, so you'll have to delete /opt/jolie and /usr/local/bin/jolie by hand for uninstalling it.

If you want to control the install directories, just edit the buildconfig/config.properties file, it's short and easy. Suggestions and reports on the build system topic are very welcome, so please tell me of anything comes up to your mind / bugs you find.

You'll notice a couple jars in the SVN, they're there because you probably don't have them in your system and they're usually not packaged by distros (e.g. Google Web Toolkit servlet jar, relaxngDatatype). It's Java, so recompiling them is useless. But if you want to use _your_ jar anyway, just change the library paths in config.properties.

Program checker upgrades
The JOLIE pre-execution program checker now punches you (emits an error) whenever you're trying to use the wrong communication pattern (you send a message, but you don't wait for a response when you're supposed to, or vice versa, etc.).

Concurrent request-response pattern performing in persistent channels
Whoa, this paragraph title is so long and confusing. Let's look at the problem by using an example: if you use the same, persistent socket with multiple threads (say, 2 threads) for performing a request-response pattern (i.e. you send a request and you receive a response back, like in HTTP), the messages risk to get messed up, because now when you get the first response you aren't sure which thread is expecting it.
HTTP pipelining solves that problem for you by sending the responses in the same order as you sent the requests. That implies that you must first send all your requests and then wait for all the responses. But in a true asynchronous system, you'd want simply to be able to send and receive things without introducing such slowing factors.
How does JOLIE solve that? We tag each request with an identifier and we require the response to equip the same tag. That way we can relate responses to their requesting threads. The internal handling of this is complicated, but it's all abstracted away at the language level... the programmer doesn't even need to know this mechanism.
In-memory communications, Java<->JOLIE channels and the SODEP protocol already support this new feature. We're currently thinking about possible solutions to introduce this on other protocols.

Website and documentation progress
The new website works are on schedule (i.e. we should publish it by this month or at least december, no later). We have tutorials (Claudio already made a lot of work.. my schedule fixes next week for full diving in user documentation writing), examples (I'll problably publish some of them in advance on the blog) and so on.
A lot of in-code documentation has been polished up (especially in the support libraries for external programs interacting with JOLIE).

Mmmh I estimate a 50% rate of things I forgot to report... I should probably post more. ;)

Opening MetaService to Java: the MetaService-Java API layer.

2008-10-10T12:57:00.013+02:00

Today, MetaService-java hit Jolie's SVN. You can find it in /trunk/support/metaservice-java. Basically, MetaService-java is a Java API abstraction layer for interacting with MetaService, so that you can use it as if it were a Java object.

This project was born for two reasons:
- it will be part of a solution for the integration of Java enterprise web applications with Service-Oriented Computing;
- it is a good example of how to implement an API abstraction layer to MetaService from an Object-oriented language, so its source code could be a useful reading for the Plasma::Service developers.

I'll let the code (and its comments) and a simple example speak for themselves. They're in Java, but they should be pretty easy to understand even for people non-proficient with it. Example follows.

MetaService metaService = new EmbeddedMetaService(); // Create a MetaService instance.

// Set up access to a SOAP Web Service.
MetaServiceChannel myWebService = metaService.addRedirection(
"MyWebService", // Resource name to assign
"socket://www.mywebservice.com:80/", // Service location
Value.create( "soap" ), // Protocol to use
Value.create( "My metadata" ) // Descriptive metadata
);

// Done! Let's communicate with it.
myWebService.send( "getNameById", Value.create( 4 ) );
Value response = myWebService.recv();
System.out.println( response.strValue() ); // Will print the name.

The API is still to be refined, but pretty much usable already. =)

Local socket support in JOLIE

2008-10-02T15:12:00.006+02:00

This fall looks good so far! A lot of JOLIE sub-projects are taking shape, and are going better than anticipated. But I'm blogging about something which has just landed on JOLIE's svn.

JOLIE now supports local sockets (a.k.a. unix sockets). How to use them? Let's see it by comparison; a communication interface over tcp/ip sockets is exposed like the following:

inputPort MyInputPort {
Location: "socket://localhost:9000"
Protocol: soap
Interfaces: MyInterface
}

Let's switch that to a local socket:

inputPort MyInputPort {
Location: "localsocket:/tmp/mylocalsocket"
Protocol: soap
Interfaces: MyInterface
}

That's it! Use the localsocket scheme in the Location URI, and supply the right path to it.

I'm (almost) back

2008-09-09T15:01:00.006+02:00

After three weeks full of time eating monsters (scary!) here and there, here I am back to posting.

Sorry to people who mailed me in this period, some mails I could not answer to or I missed because my life kept me really busy during last weeks. I'll try to reply asap.

Fortunately, this week looks good so far, so I'll be back blogging JOLIE news soon!

Meanwhile, if someone has ideas for cool plasmoids making use of open collaboration services (apart those already listed in the specs draft of course) and/or knows something about how this work is proceeding, please let us know.

Open collaboration services have been Jolied!

2008-08-12T13:20:00.004+02:00

Frank's talk was great: bringing the community into the KDE desktop is actually a great idea.
Even better, he's building up REST services for accessing the data! Of course, as we're speaking of services, my mind went directly to "Hey, these things are Joliable".

I've already started collaborating with Frank in order to discuss the API and a set of specifications for publishing a machine-readable format for reaching said services.

While I'm at it, someone could wonder "Just how difficult is to use these things with JOLIE?". The answer, of course, is "damn easy" (screencast). ;)

So, once we're finished with the JOLIE<->Plasma integration, expect nice graphical frontends to pop up. =)

Are we converging to a service-oriented experience?

2008-08-09T11:21:00.004+02:00

The more I speak with people at Akademy, the more I'm convinced that contacting KDE to start the JOLIE<->Plasma integration thing has been the right decision.

It looks like the whole KDE community (users and developers) is a perfect match to start "porting service-oriented computing to the masses". There is an incredible need for integration, communication, sharing and service accessibility. And when I see talks like the one given by Frank Karlitschek (KDE Community websites: The past, the present and a vision for the future) I get the feeling that we are all trying to converge to a service-oriented experience. We have the right tools, let's make that happen!

I do really hope to clarify what this means and how we can do it with my presentation this afternoon, so... here I am checking that the demos are still working. Murphy's law, begone! ;)

Going to Akademy... with a battery that lasts longer

2008-08-09T11:18:00.002+02:00

I'm flying to Akademy as I'm writing this post (but I'll be able to post it only when I'll be there).
Just turned on my laptop to have a look at my presentation, and.. surprise surprise, with KDE 4.1 my battery actually can last 20 minutes longer than with KDE 3.5. Plasma drains almost no power. Hooray for KDE 4!

On the other side, my flight switch in Munich was not so easy... did it ever occur to you that your flying company "does not really know if your flight has been cancelled or not" ? =)

Before Akademy

2008-08-06T10:22:00.003+02:00

Phew, the temperature is so high here in Bologna that it's difficult even to think.
Nevertheless, this month is gonna be even hotter! So, here are some quickies of the current things that are happening.

Akademy, Akademy, Akademy...
I'm finishing my preparations for Akademy, and the presentation is coming out nicely. I'm trying to make it understandable even by people who does not know much about Service-oriented Computing. I will also demo a couple of service-oriented applications for KDE (of which you could have seen screencast/shots in the kde blogs), and explain how they work and how easy is to make them with JOLIE.
By the way, if you need/want to talk with me, I'll be at Akademy the 9th, the 10th and the 11th (the 11th only in the morning).

Rising interest
We, as italianaSoftware, are receiving more and more interest in JOLIE by the business world. It looks like this could produce some open-source products. We shall see what comes up. The industry involvement has already produced some good things, like the sponsoring of the Google Web Toolkit integration in JOLIE (we are already using this in the open-source world, too: Echoes is based upon the JOLIE-GWT compatibility).

A lot of features to come in the next months
Some projects from the academic side are taking shape. A student from the University of Bologna, Davide Malagoli, is putting the basis for a complete bi-directional JOLIE<->XML translator. While JOLIE already supports the SOAP protocol, this is a great thing for the integration with tools designed for the Web Services technology. For instance, we will be able to generate automatically a WSDL document of a JOLIE program. As JOLIE supports more than just SOAP and TCP/IP sockets, we are already designing standard compliant WSDL elements to describe that.
We have got other two projects in early development, I will blog about them in the near future.

Looks like this fall and winter I will have a lot of features to put in the source tree, and a lot of screencast/shots to make. =)
As for this coming week-end, see you all at Akademy!

P.S.: welcome back to the blog world, Aaron!

UPDATE! Got the permission from the student to blog his name, so here it is. ;)

Vision: a distributed presentation framework.

2008-07-24T22:48:00.002+02:00

Vision is a proof of concept application (thanks aseigo for the initial suggestion), showing what can be easily obtained by using the service-oriented paradigm together with rich client applications.

What is Vision?
But, more importantly: what's a distributed presentation?

Imagine that you are showing a presentation, and that someone wants to see what you're presenting... in his computer! To do so, he should connect in some way to your presentation. Whenever you change page (or make another relevant action, like changing document), the client should be notified and synchronized automagically.
That is exactly what Vision does. It forms a network between the presenter and the clients, keeping the clients synchronized with the presentation.
A screencast is better than a thousand words: an example usage of vision with the previewer plasmoid and kpdf.

As you can see in the screencast, Vision already supports more than one viewer (there are shown kpdf and the previewer plasmoid, but we also already support okular).

Another nice feature of Vision is that it forms a P2P network. A client acts also as a presentation server. Say that A is watching B's presentation. Now another client (C) can connect to A. Whenever A receives an event from B, it will now also send it to C.
This can be exploited, for example, in order to perform bandwidth load balancing.

Note also that Vision makes use of SODEP, a binary protocol especially designed for service communications (it can, nevertheless, use all of the other JOLIE supported protocols, such as SOAP, HTTP, GWT-RPC...). Thus, the needed bandwidth is very small and the application can handle a lot of clients at the same time.

Exposing Vision to other platforms
A great feature of JOLIE is that it separates the logical interfaces of a service from their deployment. Suppose that we want to extend Vision to support Bluetooth clients. The ideal solution would be to expose the same interface that we expose on the network via sockets to bluetooth. Luckily, doing that in JOLIE is very easy:


service PresenterBluetoothService
{
Location: "btl2cap://localhost:3B9FA89520078C303355AAA694238F07;name=Vision;encrypt=false;authenticate=false"
Protocol: sodep { .charset = "ISO8859-1"; .keepAlive = 1 }
Ports: PresenterInputPort
}

What do these lines mean?
Well, they're telling JOLIE to expose the PresenterInputPort interface (which is the Vision presenter interface) on the pointed bluetooth Location using the SODEP protocol to encode and decode data. You can see the whole presenter service code in the JOLIE SVN repository (/trunk/playground/vision).

Guess what? It just works! (video) And what's better than a mobile phone to test it?

By the way:

just in case you want to see more service-oriented goodness in KDE. =)

Starting up: another blog in the cauldron.

2008-07-24T22:01:00.000+02:00

Hello, readers.
So here I am, another piece in the blogosphere. This blog will be about the development of JOLIE, a language for service-oriented programming, and all of its related works.

As of this first post, this blog is on Planet KDE; the following says why.

If you read the planet, you should have seen JOLIE cited here and there already. Basically I'm on Planet KDE because we, the JOLIE and KDE (Plasma especially) projects, are cooperating in order to bring the power of service-oriented computing (see also: service-oriented architecture, service-oriented programming, etc.) to the desktop.
This blog of mine is here also to explain what this means and will mean for the KDE desktop, and to show the practical results of this effort. Stay tuned with my blog if you want to know more!