Category Archives: Google

Restlet Framework 2.1 M4 and 2.0.7 released

In order to adress several pressing issues, we are releasing those new versions one month after the previous release cycle. The good news is that we had time to add a couple of nice features to the 2.1 development branch!

Bug fixed

First, the 2.0.7 version fixes a couple of issues on the stable branch including:

  • Dormant threads in some IO operations due to excessive thread pool instantiation (via TaskService). Now a single temporary thread is used when an existing TaskService can’t be found.
  • Broken Amazon S3 authentication due to new AWS domain naming strategy
  • Cookies management interference when using the Apache HTTP client extension
  • Performance issue with JAXB serialization when used by the JAX-RS extension
  • Equality testing between Role instances wasn’t properly done (object identity testing)

Those fixes are of course also available in the new 2.1 release.

Major changes

In addition, version 2.1 Milestone 4 contains several major enhancements and new features summarized below.

  • The ClientResource#entityBuffering property now buffers non transient representations of unknown size. This change was necessary to fully prevent HTTP chunking when talking to a GAE backend (which forbids chunk encoding).
  • Refactoring of the SSL support to reduce the “org.restlet.jar” size by moving all SSL logic to the “org.restlet.ext.ssl” extension. Now other HTTP extensions including Jetty, Simple and Apache HTTP Client need to add this dependency. The SSL extension also includes an experimental HTTPS client that will be stabilized and completed with a HTTPS server in next milestone.
  • The simplified logging format (one line per log entry) used by default in the Java SE edition has now been disabled from the Java EE edition by default as it could interfer with logging behavior of some containers such as Tomcat
  • Throwing ResourceExceptions in ServerResource subclasses now properly preserves the given status code back to the client
  • The SDC protocol support added in 2.1 M3 via the “org.restlet.ext.sdc” extension is now available in the GAE edition via the “org.restlet.ext.net” extension, with the same syntax for better code portability between cloud platforms (Protocol.SDC and ChallengeScheme.SDC constants also added)
  • New “org.restlet.ext.gae” extension added to the GAE edition that supports authentication and enrolement based on the GAE users service
  • ClientResource now respects any change to the default client preferences when using dynamic proxies (via wrap() for example), such as change in preferred media types.

Recent contributors

  • Avi Flax
  • Bo Xing
  • Christoph Dietze
  • John Logsdon
  • Julien Landuré
  • Kristoffer Gronowski
  • Martin Svensson
  • Matt Kennedy
  • Michael Guiral
  • Rhett Sutphin
  • Tal Liron
  • Tim Peierls

Thanks to all others who helped us in various ways for this fourth milestone.

Additional resources

Changes log:
http://www.restlet.org/documentation/2.0/jse/changes
http://www.restlet.org/documentation/2.1/jse/changes

Download links:

http://www.restlet.org/downloads/

Maven repositories:
http://maven.restlet.org

Leveraging SDC beyond Google cloud with Restlet

Introduction

When Google announced Secure Data Connector in 2009, it was welcomed with interest as it addressed people concerns regarding public cloud security and especially integration with their private information system.

SDC solves this cloud integration dilemma without requiring to open new ports on your firewall by establishing a reverse web proxy, called SDC Agent, that connects to an SDC Tunnel Server located in Google cloud infrastructure. Once established, the secure tunnel can be used in the opposite direction, from the Google cloud to your secure intranet by Google Sites, Google App Engine applications and Google Docs spreadsheets.

Missing features

While Google SDC is great if you fully live in the Google Apps ecosystem, it comes with several limitations:

  • SDC Agent is available as an open source project, but not the SDC Tunnel Server part
  • Google App Engine SDK doesn’t provide a way to test SDC locally without deploying your application
  • Can’t be used with other cloud platforms such as Amazon EC2 and Microsoft Azure
  • You can’t easily port a GAE application using SDC to another platform, private cloud or public cloud

As one of the Restlet Framework goals is to ensure a maximum portability across various Java based platforms such as GAE, GWT, Android and Java SE/EE those SDC challenges were compelling.

Restlet SDC connector

At the end of 2010, RunMyProcess, a long time Restlet user offering a cloud workflow solution as a cloud computing service, offered us to co-develop a Restlet SDC connector that would emulate Google SDC Tunnel Server and expose it like an HTTP client connector.

Thanks to the SDC Agent being available as open source, we could dive inside the implementation and understand the SDC protocol design which heavily relies on Google Protocol Buffer to implement a multiplexing tunnel (frames going both ways without constraint) over a TLS socket.

In the picture above, we illustrated how the Google SDC Agent software can be configured to connect to Restlet SDC Tunnel Server in the same way that you would do it for your Google Apps domain.

All the missing features are now supported by this Restlet extension which has just been released with version 2.1 M3 today! Thanks to RunMyProcess for co-developing this feature with Noelios Technologies.

You can find more technical details about this new feature in Restlet User Guide including sample usage code. Improvements are planned for a future release in order to increase the scalability of the connector by leveraging non blocking NIO/SSL connections or allowing load-balancing between a set of SDC Agent within the same intranet.

Update: RunMyProcess has now officially announced the support for this feature, see also press release

Restlet Framework 2.1 M3 and 2.0.6 released

Past months have been very intense for Noelios in a positive way and we are pleased to release those two new versions today. Our long running effort to develop our own non-blocking NIO connector into Restlet core, comparable in performance to Jetty/Netty/Grizzly but simpler and directly aligned to HTTP/SIP transport semantics is starting to give great results.

First, the 2.0.6 version fixes a couple of issues on the stable branch. In addition, version 2.1 Milestone 3 contains several major enhancements and new features summarized below.

Main changes

  • Support for GWT 2.2 has been added, but due to breaking changes inside GWT core API, we couldn’t maintain compatibility with previous versions of GWT. If you can’t upgrade your GWT version, you can still rely on the 2.0 branch of Restlet.
  • Stabilized the built-in SIP and HTTP client and server connectors based on our non-blocking NIO core layer, refactoring the previous design and fixing many bugs. This should solve most issues related to blocked connections and infinite loops that were encountered. See this blog post for an official announce.
  • Added a new SDC extension providing a client connector for the Google Secure Data Connector protocol compatible with the official SDC agent. This allows usage of this feature during development phases as well as for deployment to private clouds and other public clouds such as Amazon EC2 and Microsoft Azure. See this blog post for an official announce.
  • Improved ClientResource class by adding several properties
    • requestEntityBuffering, responseEntityBuffering properties to make transient entities reusable (retry attempts, chunk encoding issues with GAE, response entity reuse)
    • maxRedirects property to prevent infinite redirects, in addition to the existing infinite loop detection.
  • Added an easy to listener mechanism that facilitates the support of asynchronous representation consumption. We tested this feature successfully by consuming live feeds from CouchDB.
  • Updated several dependencies including Jetty to version 7.3.0 and Jackson to version 1.7.1

Recent contributors

  • Andreas Taube
  • Carolyn Duby
  • Charlie Mason
  • Henry Story
  • Guido Schmidt
  • John Logsdon
  • Kristoffer Gronowski
  • Leandro Oliveira
  • Olivier Miel
  • Phil Dunks
  • Sebastien Gaide

Thanks to all others who helped us in various ways for this third milestone.

Additional resources

Changes log:
http://www.restlet.org/documentation/2.0/jse/changes
http://www.restlet.org/documentation/2.1/jse/changes

Download links:

http://www.restlet.org/downloads/

Maven repositories:
http://maven.restlet.org

GSoC and Restlet integration with Equinox

Two years ago, we announced that NASA launched Restlet on the OSGi orbit by developing an integration of Restlet 1.1 with OSGi, based on Equinox extension points. This effort was presented at EclipseCon 2008 & 2009, and the code was contributed to the Ensemble project under a special license as explained by Bryan Hunt in this post. Also, listening to feed-back on OSGi from Restlet community, version 2.0 of the Restlet Framework was enhanced to ensure that all its modules and dependencies were available as good OSGi bundles.

However, even though deploying Restlet components and applications in an OSGi environment is already possible and explained in the user guide, it doesn’t take advantage of the dynamic and extensible nature of OSGi. Today, Bryan Hunt pointed me to a great tutorial written by Wolfgang Werner that nicely describes the Restlet Framework, covers its usage with Eclipse’s Plugin Development Environment (PDE) and explains how to leverage Equinox’s extension points to dynamically register Restlet components, applications and resources. See the series of posts titled “Building web services on Equinox and Restlet”:  part #1, part #2 and part #3.

But wait, there is more good news as a Google Summer of Code 2010 project “Restlet integration with Equinox” was proposed by the Eclipse Foundation and just accepted by Google! Thanks to Bryan Hunt for initiating the effort, to Equinox’s development team for supporting it, including Jeff McAffer, Simon Kaegi and Scott Lewis. We also received a positive review from Benjamin Cabé, an Eclipse contributor. Thanks also to all supporters including Jeff Norris and Khawaja S Shams from NASA, Rob Heittman from Solertium and Thierry Templier.

Two students proposals were submitted, one from Rajeev Sampath and another one from Samrat Dhillon. The first one was finally selected but Samrat has offered to contribute to the project. Rajeev is a Computer Science undergraduate student from University of Moratuwa, Sri Lanka, with good Java and distributed system experience as illustrated by his participation to the Epzilla project on Complex Event Processing (CEP).

I’m very happy to see this project, initiated by the Restlet community, taking shape and wish it full success. At Noelios Technologies, we will support it as co-mentor and encourage other interested parties to join and contribute. The project web site at Google Code is here… stay tuned!

Updates:

Restlet supports OData, the Open Data Protocol

OData adoption

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.

Towards standardization

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.

Updates: