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, October 20, 2009
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.
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!
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.
It'
So, dear reader, would *you* attend? =)
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? =)
Friday, February 20, 2009
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.
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.
Wednesday, February 11, 2009
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!
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!
Friday, January 23, 2009
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/).
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/).
Subscribe to:
Posts (Atom)
Posts
