Posted by Jerome Louvel in : GWT, NIO, OData, Restlet Releases
- no comment
We are still on track for the 2.1 RC1 release in September, but so many enhancements and bug fixes were added since 2.1 M5 that we thought it would be useful to many users to have this intermediary milestone.
First, the 2.0.9 version fixes 10 issues on the stable branch including:
- Inappropriate warning message about child contexts
- IO flushing issue that could create troubles with writer based representations such as JsonRepresentation
- Conversion of representations to instances of primitive type using the default converter
- Handling of binary data in OData extension
- Default converter took precedence over specialized converters when converting incoming representations
- Lack of warning message when an unexpected error happen during the invocation of an asynchronous callback
Those fixes are of course also available in the new 2.1 release.
In addition, version 2.1 Milestone 6 contains several major enhancements and new features summarized below.
- Improved Restlet annotation value syntax to support alternate variants using ‘|’ and combination of several metadata for a single variant using ‘+’ separator. Also, all metadata are now supported, not just media types. In addition, support for URI query constraints was added to allow annotations such as @Get(“form:json?light”) or @Get(“?level=2″), working on both client and server side
- Added org.restlet.ext.html extension supporting writing HTML forms in either URL encoded format or multipart form data, with the same FormDataSet class. Parsing of multipart form data isn’t supported yet.
- Added CookieAuthenticator in the org.restlet.ext.crypto extension to provide customizable and secure authentication via cookies, in a way that is as compatible as possible with HTTP challenge based authentication
- Added ConnegService providing a way to control the content negotiation behavior at the application level. It offers two modes: strict and flexible (default) but additional algorithms can be implemented.
- Added org.restlet.ext.emf extension supporting the conversion between EMF generated beans and XML or XMI representations. It can also automatically write simple HTML representations for navigating your web API.
- Added HTTPS server connector based on the internal non-blocking NIO connector. Co-developed with NetDev.
- Many minor enhancement to the Restlet API for conveniency purpose such as a new Representation.append(Appendable) method.
API breaking change
When retrieving or updating the raw headers in the Request or Response attributes, the type should now be Series<Header> instead of Series<Parameter>
- Bryan Hunt
- Cyril Lakech
- David Bordoley
- David Hamilton
- Glenn Bruns
- Jean-Pascal Boignard
- Jeroen Goubert
- John Logdson
- Konstantin Pelykh
- Martin Svensson
- Nikhil Purushe
- Ray Waldin
- Remi Dewitte
- Scott S. McCoy
- Tim Peierls
- Thomas Eskenazi
Thanks to all others who helped us in various ways for this milestone.
Posted by Jerome Louvel in : GData, OData, RDF, Restlet
- no comment
Since the release of our Restlet extension for ADO.NET Data Services in September 2009, many changes happened on this front. Microsoft has been busy enhancing their technology, splitting it into an open specification for the REST API called OData, for Open Data Protocol, and using WCF Data Services for the server-side framework. This article gives an overview of the technology, and this page the full specifications of the protocol.
The OData protocol has also been embraced by IBM in its Java-based WebSphere eXtreme Scale product and Microsoft has leveraged it in several of its products like Excel PowerPivot, SharePoint Server, Windows Azure Table Storage and SQL Server Reporting. Other recent initiatives are the project code-named “Dallas“, which offers a market place for data services with full support for access control and billing, and the OData visualizer part of Visual Studio 2010.
In addition, public OData services are starting to pop-up, like the one to access Netflix’s media catalog. Microsoft has been providing examples via the OGDI initiative and for the MIX’10 conference. Here is a longer list of producers.
Enhanced Restlet extension
While preparing our recent Restlet Framework 2.0 RC1 release, we enhanced our Restlet extension for OData, moving it from the “org.restlet.ext.dataservices” to the “org.restlet.ext.odata” package and adding support for those advanced features:
- Projections, similar to database views
- Transparent server-side paging
- Blobs, to expose media resources
- Row counts retrieval
- Customizable Atom feeds
- Version headers
- Operations, to expose stored procedures
The extension is also available on the Restlet edition for Android, allowing you to directly access OData services, for example hosted on Azure cloud computing platform, from a smart phone.
The diagram above illustrates how useful the Restlet extension for OData is becoming, as a high-level client for data services powered by a growing number of server-side technologies. For explanation on how to use this extension, read the Restlet user guide page for the extension as well as a detailed tutorial.
All those initiatives have caught attention with articles and posts like:
An interesting thing to watch going forward is how this technology will be compared with Google Data Protocol (GData) alternative. In his OData Q&A page, Microsoft hopes for a collaboration with Google on an official set of extension to the Atom suite of standards.
Yahoo! has also worked on a similar technology called DataRSS, and finally the W3C is pushing the Linked Data, an application of the Semantic Web, as a way to transform the Web of documents into a Web of data, with technologies like RDF and SPARQL.
Posted by Jerome Louvel in : Android, Ecosystem, GAE, Google, GWT, Microsoft, REST, Restlet, Restlet General
- no comment
The Web is taking multiple shapes with the Mobile Web, Cloud Computing and RIA being hot topics recently. If you follow this blog frequently, you are certainly aware that the Restlet Framework, the first RESTful web framework for Java developers, is available in five consistent editions since version 2.0 M4. Each edition targets a special development environment:
- Google Web Toolkit (GWT) for AJAX applications deployed in desktop browsers, without any plugin required
- Google App Engine (GAE/J) for deployment on Google’s cloud computing infrastructure
- Android for deployment on compatible smartphones
- Java SE for standalone deployments in regular Java Virtual Machines
- Java EE for deployment in Servlet engines
Each edition is offering the same Restlet Framework, with restrictions and adjustments based on the target environment. For example, the GWT edition only supports the client-side usage of Restlet, while the GAE edition only provides compatible extensions and ensures that we don’t break the security sandbox or use unsupported JRE classes.
As a result, you can easily develop a unified Restlet application with a server-side deployed in GAE, a client version available for Android smartphones and another available for desktop browsers with GWT, fully leveraging the most innovative technologies available from Google for Java developers.
You might wonder what exact value does Restlet brings in the middle of those technologies? The Restlet Framework is all about REST, supporting advanced HTTP features such as content negotiation, caching and conditional processing, allowing for the same URI-addressable resource to expose various representations. Each representation renders the same information in various languages or formats such as JSON, XML or anything else that makes sense for your clients such as binary pictures.
Supporting content negotiation allows your Restlet cloud server to expose the same resources to all its clients, including an Android smartphone client, a GWT desktop client, a Flex client, a programmatic Java SE robot or a basic HTML browser. One Java API and one unified code base gets you covered in all those scenarios, even if you need to serve static files: a Restlet Application truly merges the notion of Web Site, Web App and Web Service!
So, using Restlet as a cloud server gets you much further than a regular Servlet application. Usually, you would use GWT-RPC to communicate between your GWT client and your GAE back-end, and the low-level HTTP client provided by Android to communicate with your GAE custom Servlets. Obviously, the result wouldn’t be very RESTful as GWT-RPC is introducing some strong coupling. You could use the low-level HTTP client provided by GWT as well, but then you would loose the big benefit of using Java proxies in GWT, with transparent serialization of parameters and result object.
This is where the Restlet Framework comes to rescue! For GWT, we provide both a high-level HTTP client, removing the need to manually parse and format HTTP headers thanks to its Restlet API but also a proxy generation mechanism based on GWT deferred binding very similar to GWT-RPC but truly RESTful! Migration of existing GWT-RPC code is straightforward as we also support GWT-RPC AsyncCallback interface in addition to our equivalent Result interface. For our serialization format, we reused the one of GWT-RPC, a special JSON variant, therefore it is fully featured and as robust as GWT-RPC ! In your Restlet cloud server, you just need to add our server-side GWT extension to transparently support this serialization format, thanks to content negotiation.
If you are a Google fan, you should be happily developing with the recent GWT 2.0, Android 2.0 and GAE 1.3.0 releases and the RESTful solution described above should gives you a big smile and to get started, we have written a complete tutorial, with full source code, illustrating a unified Restlet application for GAE, GWT and Android.
But even in this scenario, you wouldn’t be restricted to Google technologies, you could chose to support alternative clients such as regular HTML browsers, Flex or Silverlight clients, or any other HTTP client. On the server-side, you could take the same Restlet application and deploy it locally, or on Amazon EC2 or Microsoft Azure, thanks to our Restlet editions for Java SE and Java EE which can be installed on those major cloud platforms!
In the end, the Restlet Framework offers you, for free, the first comprehensive RESTful middleware for Google technologies and beyond! As a last word, I would like to thank again my friend Didier Girard, for sharing his insights that led us to this post (and a lot of work!)
Posted by Jerome Louvel in : Microsoft, Restlet, Restlet General
- no comment
After a successful collaboration in February with Microsoft, we continued to explore the interoperability opportunities between Microsoft and Java technologies, leveraging REST and Restlet. Today, we are happy to announce the result of several months of hard work: a new interoperability bridge between Java and ADO.NET Data Services!
In order to understand how central the Web and REST are becoming for Microsoft, it is enlightening to discover their new strategy elaborated by Ray Ozzie, Microsoft’s Chief Software Architect. It is called Software + Services and recognizes the ubiquity of the Web and the need to mix both locally running software and cloud computing services in a unified way.
From vision to reality, there is often a long way to go, but this time Microsoft is serious about the Web and genuinely embracing REST. For a few years now, they have been progressively building on their strategy, through Windows Azure, a comprehensive cloud computing platform, and through online extensions to their classic products like Office Live, XBox Live or Windows Live.
ADO.NET Data Services
One of the key technologies they leverage to achieve their plans was launched in 2007 under the code name “Astoria”. It drew much attention in the REST community at this time as it was, with Ruby on Rails’s Active Resource technology, the sole way to automatically expose a data models as RESTful Web services.
Since then, it has matured and became an actively maintained technology called ADO.NET Data Services. You can read an overview paper on MSDN and browse their extensive technical documentation for details about their REST API which leverages AtomPub.
Interoperability with Java
As RESTful Web services, you could use any HTTP toolkit to access them, to the exception of the authentication step which relies on a custom scheme, quite similar to the one used by Amazon for its Web services. However, you are not very productive this way, especially when you know that ADO.NET Data Services describe themselves through extensive metadata.
So far, beside client toolkits for Microsoft technologies such as .NET and Silverlight, only the PHP language had an easy solution to interact with those services. Today, with the release of Restlet 2.0 M5, we are proud to announce a similar offer for Java developers, cleanly leveraging the Restlet Framework.
With the support from Microsoft and especially Stève Sfartz, Architect Lead at Microsoft France, we built a high level client that is able to generate client Java classes from exposed metadata and to easily manipulate the remote entities as if they were local. The current feature scope covers most of the use cases, but keep in mind that we don’t cover all the available features available yet.
This new Restlet extension has been extensively covered by Jean-Christophe Cimetiere, Sr. Technical Evangelist from Microsoft Corp Interoperability team, in this new blog post.
In order to briefly illustrate how the extension works, you can read the dedicated extension page in the Restlet user guide. It shows some simple code to access to a data service, one provided for the Open Government Data Initiative (OGDI), a recent effort launched by Microsoft to expose government data sources as RESTful Web services.
In addition, to the regular Javadocs of the extension, a complete tutorial is also available on the wiki to get you started in minutes with a detailed example. Now, if you have a .NET developer friend, you could ping him and set-up a plug scenario!
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.