Coming back from Jazoon, a conference that some people see as the European version of Java One. Since this conference is for me a nice concentrate of what’s coming in the Java/OO/Business software world, I wanted to report a little on what I’ve seen there and what this implies/offers in a Web of Things context.
Let’s be modular
As last year, modularity was a BIG keyword. The Java community has acknowledged the success of OSGi and is looking for a somewhat closer integration of these concepts. The Language Support for Modular Programming (JSR 294) will be part of Java 7 and will pave the way towards truly re-usable software components. In the WoT community and in our personal projects here at ETH and SAP research, we started using OSGi a little while ago. The physical world is definitely not homogeneous in terms of protocols, thus the need to create device adapters or drivers, understanding a particular device and providing its functionality as a Web API. OSGi helps there as it enables us to package these drivers and inject them, at run-time, on different platforms such as “smart gateways”.
But using OSGi also complexifies the whole developement cyle and thus a seamless integration to Java of the modularity concepts might help simplifying it! Wait and see…
REST rules
REST ohhhh REST core of the Web of Things! REST was already pretty strongly represented at Jazoon last year but it now seems to have gone beyond the hype and is in the process of being “tool-supported” in lots of ways in the serious world of Java Enterprise. The most prevalent example of this is the number of Java frameworks offering to help you implementing your RESTful API both on the server and client sides.
When we began our exploration of REST we basically had the choice between RESTlet and …. RESTlet (in the Java world). To me RESTlet has always been a great tool with a great community however, as a developer with Java Enterprise background I always felt not totally at ease with the level of abstraction used by RESTlet (which are really close toFielding’s thesis) and with the relative lack of tight integration with the enterprise tool-box such as JAXB.
The JAX-RS standard changed the deal. It offers abstraction levels which are more familiary to the Java developer and its implementations a tight integration with the Java enterprise tools (JAXB) and techniques (annotations, etc.).
Two implementations of JAX-RS were dominating at Jazoon, Jersey and RESTeasy. Jersey is the reference implementation from Sun (ohhhh sorry Oracle). We’ve been using it in two of our latest projects (that I shall present here soon) and I must say and really really like it. It was presented in several talks but I especially liked this one.
I can only advise you to have a look at Jersey and especially it’s integration to Grizzly, a embedded Web server to follow being only because of its very fast integration of bleeding edge technologies (e.g. Comet) and scalability!
The second framework I had the chance to discover was RESTeasy, a full implementation of JAX-RS as well. I did not have the chance to test RESTeasy yet but I was impressed by the presentation. I especially liked its out of the box support for lots of representations (e.g. RSS, XML, ATOM, JSON, YAML, etc.) and its out of the box support for caching, which is extremely valuable in a WoT.
One of the big problems Java WoT developers will now face is choosing the right framework because these are just three amongst the many poping up every month, the graph below is a hype-meter of the four major REST frameworks for Java:
It was created by a colleague at SAP who also made a great benchmarking of these frameworks (and others). I should soon be able to publish it here…
[to be continued]…
