Posted by Jerome Louvel in : Ecosystem, Microsoft, Noelios, REST, Restlet, Restlet General, User interface
- no comment
After a long investment in WS-*/SOAP initiatives, Microsoft has recognized the value of REST. But they didn’t adopt REST only on the surface, they have put in place a comprehensive offer and are actively working to demonstrate and facilitate the interoperability with other platforms such as Java.
Facing a strong competition in the Rich Internet Application area, from Google with GWT, from Adobe with Flex/AIR/Flash and more recently from Sun with JavaFX/Applets, Microsoft has finally reacted with the introduction of their Silverlight 2 technology.
Silverlight requires a browser plug-in (ActiveX available for IE, Firefox and Safari) and provides you with a subset of the .NET Framework. Microsoft supports Windows and Mac while Novell has a Linux version called Moonlight. For the user interface it relies on a declarative language called XAML, not too different from Flex MXML or JavaFX scripts.
Regarding communication, it relies on WCF and offers direct support for HTTP/REST, RSS and Atom, POX/JSON and XML/LINQ. A description of the full architecture is available here.
Now, if you follow this blog, you are probably wondering how Silverlight interoperates with Java on the server-side. Even if its support for HTTP has a few limitations (partially due to its nature of browser plugin), Silverlight allows you to communicate easily with a REST back-end.
To demonstrates this, Microsoft has leveraged our Restlet framework and illustrated this interoperability with several detailled posts in their Silverlight plus Java blog written by Stève Sfartz from Microsoft. Other examples are available on Blog in the Cloud and Cloud it up.
If you are a traditional Microsoft developer, you would naturally turn to Visual Studio to develop your Silverlight applications, but what if you are a Java developer?
Well, Microsoft has done an unusual move by supporting the development of a Silverlight IDE for Eclipse! It’s called eclipse4SL and is co-developped with Soyatec, a French software editor specialized in Eclipse products development.
REST interoperability is also covered in eclipse4SL’s user documentation, illustrated by the usage of Restlet on the server-side. See this page for Restlet guidance. This is currently based on Restlet 1.0 and a Tomcat deployment, but work is underway to upgrade to Restlet 1.1.
The eclipse4SL project has even been submitted to the Eclipse foundation. See this post from the executive director of the Eclipse foundation.
After meeting with Stève Sfartz, who very enthusiastically introduced us to Microsoft projects for REST, cloud computing and RIA, we worked on a join presentation for the Microsoft TechDays in Paris.
The goal was to present interoperability scenarios around REST. Thierry Boileau did the presentation for Noelios Technologies. A detailled summary (in French) has been posted by Stève Sfartz on his blog.
This presentation gave us the opportunity to show case our recent support for the Shared Key HTTP authentication scheme. This protocol is similar to the one defined for Amazon S3 and allows you to access to Microsoft Azure Data Services from a Restlet Java client.
This new feature is available in recent snapshots of our future Restlet 1.2 release!
Update 1: article from BetaNews covering Eclipse4SL and mentioning Restlet
Update 2: Stève Sfartz has posted a complete article on MSDN detailling the example showcased at the TechDays (in French), including downloadable source code.
Posted by Jerome Louvel in : GWT, Restlet General, User interface
- no comment
Google Web Toolkit is a very successful technology that brings Java right inside Web browsers. It could be compared to traditional Applets but without requiring any extra plugin and with a more natural integration with the browser artifacts.
Now, how can you leverage REST in GWT? By default, they propose an opaque GWT-RPC mechanism that is closer to SOAP than to REST. It gives a feeling of transparent distribution but actually introduces tight coupling between client and server code and prevents you from leveraging existing RESTful back-ends. There is an HTTP request builder class that you can use, but it requires knowledge of lower HTTP levels like the exact headers syntax.
Wouldn’t it be nice to use the Restlet API instead, which provides a higher level mapping of HTTP semantics to a clean Java API ? Thanks to the support for generics added in GWT 1.5, we were able to achieve this port with reduced efforts and limited troubles. We had to get rid of the server-side features that don’t make sense in a browser, and of the APIs like NIO and logging that aren’t emulated by GWT. The major impact was the adaptation of the API to the asynchronous communication imposed by AJAX and GWT.
The port, named “Restlet edition for GWT”, is available since Restlet 1.1 and its usage is documented in our Wiki. There is a discussion comparing the GWT-RPC and Restlet edition for GWT architectures and much more! The testing, most of the documentation as well as the back-end integration (see the server-side GWT extension) was contributed by Rob Heittman. I would like to thank him as well for the numerous design discussions while working on this port.
Rob Heittman is Chief Technology Officer at Solertium. Using prototypes of the Restlet edition for GWT, Solertium has been building large enterprise applications with Restlet and GWT for the past year, for worldwide customers like IUCN and Conservation International. “I love GWT, but I prefer RESTful web services to RPC,” says Rob. “GWT backed by Restlet has been great for us. Now, GWT 1.5 and the new Restlet edition for GWT will make our client-side code as simple and elegant as our server code.”
Finally, if you want to follow the latest news about GWT, I recommend the onGWT blog. It is maintained by Didier Girard, a good friend who introduced me to the joys of GWT!
Posted by Jerome Louvel in : OSGi, Restlet General, User interface
- no comment
Since 2004, NASA Jet Propulsion Laboratory has become a forefront user of Eclipse RCP (Rich Client Platform). As explained by Jeff Norris in the foreword of the “Eclipse RCP” book, this choice was driven by the UI-level features as well as the modularity offered by Eclipse’s plug-in architecture : Equinox.
The usage of Eclipse RCP started within the JET’s Maestro team and is now shared with other teams at NASA via a framework named ‘Ensemble’. You can read the whole story in this case study.
As Equinox is in fact a full OSGi run-time, it is possible to use it for server-side applications as well. For EclipseCon 2008, Khawaja S Shams and Jeff Norris have given a great presentation on the integration between Equinox and REST, leveraging the Restlet API. The slides are available online.
They introduce the ‘Ensemble REST Framework’, providing a convenient definition of new Restlet Resources via Equinox extension points. This integration nicely uses Eclipse wizards to define those Equinox extension points. Just note that extension points are not yet part of the standard OSGi speciciations.
This initiative, as well as constant interest in OSGi from our users has led us to improve the support for OSGi in the upcoming Restlet 1.1 M4 release. Each JAR in the Restlet distribution is now a full OSGi bundle. An internal activator automatically registers the Noelios Restlet Engine (NRE) with the Restlet API, or the pluggable connectors with the NRE.
You can get more details about the current and planned support for OSGi in Restlet in this RFE. We are also looking forward to playing with Ensemble REST framework which will be released in open source by NASA.
Posted by Jerome Louvel in : Restlet General, User interface
- no comment
In a previous post, I’ve introduced you to frevvo, a start-up that provides Web 2.0 visual forms, with a full WYSIWYG builder based on AJAX.
Recently, they have been playing with Restlet and implemented one of the REST design pattern (“View and Entity resources”) that was discussed by the Restlet community. It is a very compelling illustration that REST applications are perfectly capable of handling complex Web forms without compromising with the REST principles.
What is also cool is the fact that the Entity Resources can be either stored locally along with the View Resources (and accessed by a simple Restlet method call), or remotely and accessed by HTTP. This illustrates the power of uniform interfaces in REST/Restlet.
Congrats Ashish and Yuri, I look forward to reading the next blog entry in the series!
Update: two follow-up posts are available:
- Visual REST apps: Part 2 – documents
- Ajax+REST: the next killer app?
Posted by Jerome Louvel in : Java, Restlet General, User interface, XML
- no comment
I would like to encourage you to have a look at frevvo, a Web start-up launched by some friends, that provides a full solution to handle complex Web 2.0 forms, right from your browser. One of their strong selling points is the great form designer available as a Web application (AJAX based).
Also, the form can be directly mapped to an XML Schema that you have imported. Their server component will directly generate valid XML instances when you submit the form to it. Currently it is based on a Servlet container but they are experimenting with Restlet (and already provided key feed-back), so I’m hoping that they will migrate when our final 1.0 version comes out
You can see screenshots and sign up for a live test. Congratulations Ashish, Leandro, Nancy and Yuri, and keep up the great work!!
Posted by Jerome Louvel in : Java, User interface
- no comment
Have you noticed all the recent pessimism around Java and the hype pushing concurrent platforms like Ruby on Rails? A domain which frequently receives critics is the Swing GUI framework, supposed to be old, slow and badly designed. I’ve worked with it since the beta releases and still follow its evolution closely.
The release of Tiger (Java 5.0) provided a much needed update of the look and feels, the default one and the Windows XP one ; speed was also significantly improved. Meanwhile the concurrent SWT framework was aggressively pushed via the Eclipse platform. This pressure was probably needed to provoke a strong reaction and it seems to me that Mustang (Java 6.0) will hold on its promises.
Take a look at the 160 slides long presentation by Romain Guy and Alexis Moussine-Pouchkine (in English except for the first two slides). It’s comprehensive and truly exciting: congratulations! Here are some interesting facts:
- The size of the JRE 1.5 is 7.1 MB and the size of the .NET Framework 2.0 is 23 MB
- Better desktop integration (icons, Windows system tray, Mac dock integration, slash screens)
- Perfect native look and feels. Also see directory.
- SwingLabs hosts several interesting projects like the standard SwingX components suite (date picker, login panel, table improvements like column selection, sorting, task panel similar to Windows explorer panels, etc.)
- Great third-party components complete the features like JFreeChart, JGraph, JGoodies. Also see directory.
That’s great to see a strong and active community around GUI frameworks in Java (see Java Desktop and Client Java) and that Swing is alive…and doing well.