It looks like. Naviquan.com is running now on Restlet framework. This project started when I decided to get rid of "dynamic" URLs (the one that have question marks following by request parameters - something like …?id=xyz&month=mm&year=yyyy) and replace them with what some people call RESTful URLs (or "user friendly" URLs).

Naviquan.com is still in its beta phase with multiple problems to solve (most of them are non-technical), and I thought that it's about time to make the site more visible to search engines. Not being happy with several frameworks that I could use to this end (among them Struts 2, Rails and Grails - I will talk later more about this), I just googled a couple of months ago the Web for "restful urls" in a hope that I would find other emerging technologies capable of doing what I wanted - quite quickly I came across the Restlet Web site.

Restlet framework turned out to be a lot more than just an API to use URLs I wanted. In a nutshell, it's a full blown REST engine. Now, if you do not know what is REST, go and read the Roy Fielding's dissertation, Architectural Styles and the Design of Network-based Software Architectures. Or, at least this Wikipedia article on Representational State Transfer (that's what REST stands for).

Since the World Wide Web is the key example of a RESTful design, and Restlet framework is the REST engine, obviously, it represents an alternative to Servlet API - essentially the only (up until recently) option for Web development using Java platform. I am not going to debate here the issue of Servlets vs. Restlets. All I can say is that my experienced showed to me that Restlet API (currently at level 1.0.4) is a very viable substitute to Servlets. Things have changed.

Things in Restlet Framework That Helped My Project

In this section title I could say "Things in Restlet framework that I like" or even "Things in Restlet framework that are good." But I do not want to pretend that I have learned Restlets to a degree where I can start making bold statements; instead, I would like to refer to the actual experience. So, what happened is:

1. Restlet API turned out to be very conducive to OOP. I suspect that the reason for that is its foundation - a very sound academic research by Roy Fielding on REST (see above) where Restlet framework is a very loyal and consistent implementation of the REST architecture. Essentially, this research turned out to be a very good OOA/OOD at the foundation of the Restlet framework. Consequently, the port of Naviquan.com from Struts 1.2 to Restlet was very easy. I could reuse a lot of coding; however, the overall design turned out to be more OO than anything else I have done so far as a Web developer.

2. Restlet framework is not a Web development framework. Restlet authors call it a framework because together with Restlet API it contains a reference implementation (called Noelios Restlet Engine, NRE), and a set of extensions. My point is simple, Restlet is not something like Struts - Restlet foundation is the Restlet API which is akin to Servlet API. As such, it gives a clean slate for Web development. I found that combined with its conduciveness to OOP, it gives you a much better chance to focus on requirements instead of trying to marry requirements with the maze of Web development frameworks, APIs and configuration items/files.

3. If you talk to Groovy or JRuby folks, you will hear a lot about preserving your investment in Java. Well, Restlets are Java. If you have an experience with Java OOP, you can start being productive immediately - that's what happened with my project. The port from Struts to Restlet API was very quick and easy as I said above.

4. The combination of Restlet API and Freemarker templates turned out to be a very lucky one. It was very refreshing to forget about JSP quirks and enjoy the simplicity and power of Freemarker for which the Restlet framework provides an extension. This is just another reason to reiterate what I said above in #1 and #2.

5. Restlet framework includes so-called connectors. Jetty connector (which is a server connector) is among them. This simplifies significantly the deployment process - simplifies to a point where there is none. You just start your Java application and, voila, you are done. This is not to deny advantages resulting from the JEE deployment process. However, the point is that the way Restlet framework support connectors may open a way for Java to spread more from the select club of "enterprise" applications to the mainstream of Web development where people prefer the pain of Rails deployment over dealing with Java Web containers. And, there is a WAR packaging support in the working for Restlet 1.1.

6. I may be guilty of violating some development practices, but I really feet liberating with having zero configuration files. Partially, this is also due to the fact that I opted for a more OO solution as a back-end engine (hence, thanks God, no ORM). But opposite to the convention over configuration approach (where a convention becomes like a configuration item itself) in Rails with RDBMS' as your only option (as well as with Grails), Restlets do not care what you use for back-end - use flat files if you want. But back to configuration - yes, I have some configuration items that relate to my domain but they are all in one place in my code. After setting up everything I need, I do not expect their frequent changes with Naviquan.com. And if I have them, it takes less time to implement changes with regular Java way than with JEE way of doing things. I mean, you compile your classes; you stop your java application, and you start it again - everyting happens instantly.

7. My quick and successful port would not be possible without help I got on the Restlet discussion board/mail list and, in particular, help from Jérôme Louvel, who answered all my questions (who is also the main architect and driving force behind the Restlet framework and the owner of Noelios Consulting in Paris, France)

Things in Restlet Framework That Did Not Help My Project

There is one - available documentation is not adequate for serious development. This relates to both, javadocs and examples. As I mentioned above, I got help on the discussion board, and that saved a lot of time in my attempts to solve some problems. The only alternative would be to go through the source code to understand the logic implemented.

However, while the Restlet community is growing (and it is growing!), with all desire to help, Restlet architects and developers will not be capable of responding to all questions. It is critical for the success of the framework to provide those who are interested in this new technology with enough insights on ways of using it to develop applications.

Things That I Think Should Be Added in the Restlet Framework.

One thing noticeably missing from Restlet API is anything that would resemble a user session. In fact, framework authors say that the "direct mapping of REST concepts to Java interfaces (Resource, Representation, Connector, Component, etc.); their resource-oriented design removes the need for in-memory sessions, a major scalability issue with Servlets." Again, I would not like to debate here this statement - it's quite possible that with little experience in pure REST development and, in particular, in using Restlet API, I simply do not see how mentioned above interfaces can make up for the absence of something like RestletSession. Anyway, HTTP sessions are not real ones - it's always an attempt to mimic sessions. The only difference is in how robust this imitation is, and how it can withstand any more or less serious security vulnerability scans.

I certainly understand that for REST architects it is very difficult to accept anything even remotely like a session API. But as an application developer, I see advantages of having a Session - I am talking about cases where some way of maintaining state is absolutely necessary. I also think that sooner or later, if sessions are not implemented in Restlet framework, someone will create a Web development framework on top of the Restlet framework which will include all the support needed for using the concept of a session. Interestingly, Restlet API includes a Cookie class ("provided by a client" as its javadoc states).

Benchmarking

When I decided to port the Naviquan.com Struts based application to the Restlet framework, I thought that it would be interesting to use this opportunity to evaluate performance characteristics of both applications. Of course, any comparison between the two can be valid only by considering accurately what exactly is compared. In particular, any benchmarking of the kind cannot be interpreted as Restlets vs. Servlets - many other things are involved. For example, Servlets are run in a container; obviously different containers would show different results. Same can be said about Restlets and connectors. Because of this, I would never try to use what I did as a basis for performance judgments regarding Restlet framework itself.

However, a comparison I was up to makes perfect sense from a practical standpoint. Here we have one real life Web site implemented and deployed using a particular (and proven) technology, and here is the same Web site on the same hardware and network implemented with another technology (which is new). Benchmarking can attest the viability of this new offering and its usefulness as a Web development platform. Basically, the question is - is this new set of tools, components, libraries, etc. good enough to keep using it?

At this point some technical details about Naviquan.com are due. It's deployed on two-processor (dual core each) dedicated machine on Windows 2003 Server OS with 4GB memory. In both cases, Java 1.5 JRE was used. Old implementation was coded using Struts 1.2 and deployed on Tomcat 5.5.23. I used Restlet 1.0.4 to benchmark the new site with Jetty connector offered in Restlet 1.0.4 (which I believe is Jetty 6.1.5).

I used JMeter 2.3 RC3 to load servers with requests and take performance measurements. In both cases, the client was on the same machine (different from the server) on the same LAN node. All outside requests to the Web site/server were blocked. I used the same JMeter test plan (requests for identical resources - obviously URLs for sampling were modified as needed for the new application). Test plan included two thread groups with measurements taken for a number of runs for a given number of users in thread groups created. Sampling included about 40 resources.

Again, I would avoid any deep conclusions regarding Restlet performance itself based on this study. But as a site owner and its webmaster, I am pleased with the results that I am getting from this new technology. They tell me that the Restlet entire offering in the configuration deployed is a viable alternative to Servlets. Second, in the load range I am particularly interested in it scales better than Struts/Tomcat offering. I am going to keep this site on Restlets.

My blog section at this moment does not have comments functionality. If you have questions or comments, please use Contact Us form to submit them - they will be published on this page. Also, stay tuned. As soon as a stable Grizzly connector is available, I will use the same test plan to benchmark this configuration as well.