The Loop

How many times have you been using Facebook and received the “Sorry, an error has occurred. We’re working on getting this fixed as soon as we can.” message?

This appears to happen fairly often (relativly speaking) from what I can see. I wonder if this lowers peoples expectations of what uptime they should expect from the big web 2.0 platforms? For instance, I dont ever remember getting such a message on YouTube… but then again a whole lot more people use facebook than use YouTube…

I guess my question is this… Is it acceptable to be having public downtime on such sites/services that are becoming such a part of everyday society? I would say no, its not. Were told that facebook has somewhere in the region of 10,000 servers! So goodness knows why with 10K servers they cant get a decent amount of uptime for most users.

Its been in the wings for some time now but the announcement has finally been made public. This is great news as it means that when were coding in Scala the classes in your web container will automatically be updated without the need to restart the container and redeploy the WAR.

For more on this check out the announcement

I recently read this article and realised that I had never blogged about the resin plugin that works perfectly with lift for development and deployment.

Heres what you need to add to your pom.xml

<build>
   ...
   <finalName>${project.name}</finalName>
   ...
    <!-- resin plugin -->
      <plugin>
        <groupId>com.caucho</groupId>
        <artifactId>resin-maven-plugin</artifactId>
        <version>3.1.6</version>
        <configuration>
          <contextPath>/</contextPath>
        </configuration>
      </plugin>
    ...
</build>

<pluginRepositories>
...
<pluginRepository>
  <id>caucho</id>
  <name>Caucho</name>
  <url>http://caucho.com/m2</url>
</pluginRepository>
...
</pluginRepositories>

Note, the final name var is important, as thats what resin uses to point at. Dont worry tho, as lift already has a name element so provided you haven’t deleted it, your laughing.

Next, to boot the server, just do:

mvn resin:run

That should be it! Enjoy!

Right, as you know, I use the lift framework a lot these days. I also use Resin as my choice container. So, i recently got to thinking, wouldn’t it be cool if i could just bosh together a simple way to expose controllers in lift via the groovy protocols made available by Resin – well, I have here an example of just such a thing.

Lift Side

Ok, before anyone has a poke at this code… it was a very quick and dirty example, so its not ideal, and obviously your code would be a whole lot more complex, but this article is just about proving concept.

I set up the object that I want to expose via remoting. Critically, there would be nothing stopping me using the persistance built into lift, or anything else available to java or scala for that matter. The key is the traits… as they are like java interfaces (broadly speaking), they let resin know what methods it can call.

package com.timperrett.resin.example.controller

trait HelloTrait {
  def hello: String
}
class HelloWorld extends Object with HelloTrait {
  def hello = "Hello from lift" 
}

Resin Configuration

Next, we add a bit of config to resin so that it knows how/where to expose the service. Critically, we could have used Hessian, Burlap or CXF (for SOAP) and all by being pushed out of the container with zero extra effort.

<web-app id="/lift-remoting-example" 
   root-directory="webapps/lift-remoting-example">
  <servlet-mapping 
   url-pattern="/api/hello-world" 
   servlet-class="com.timperrett.resin.example.controller.HelloWorld">
    <protocol uri="hessian:"/>
  </servlet-mapping>
</web-app>

Client Side (in another language!)

To proove the point, I thought I would just make a simple client in another language (namely ruby):

require 'rubygems'
require 'hessian'

url = http://127.0.0.1:8080/lift-remoting-example/api/hello-world
client = Hessian::HessianClient.new(url)
puts client.hello

Again, a very simple example, but one that proves the point. You should then see “Hello from lift” output in the terminal window.

Project Files

You can download my example from here

If you found this article interesting, or have played with this yourself also, then by all means leave a comment or get in touch.

Web Services for API? Mehhh, haven’t we heard all this before?

Well, frankly, yes, you probably have. But you might not have had the full story. Im not talking about SOAP or other such protocols that require a serious amount of time at remoting-protacol-fat-camp… Today I would like to take some time to talk about the Burlap and Hessian protocols. For the astute readers, yes, those are the same ones that I was banging on about in a previous post when talking about hot technology for 2008. They are both slick remoting systems that run on Resin (they probably can be run on other JEE servers too, but frankly I haven’t tried), and according the chaps at Caucho:

“Hessian and Burlap are compact binary and XML protocols for applications needing performance without protocol complexity. Hessian is a small binary protocol. Burlap is a matching XML protocol. Providing a web service is as simple as creating a servlet.”

Sounds pretty cool doesn’t it? Well they are. I have been playing with Resin running these protocols and evaluating them as methods for creating robust API which 3rd parties can easily integrate with. Before reflecting on what I have experienced during these trials with Burlap/Hessian I would have instantly said that Hessian was better, but then I got to reflecting on use in the world: is it really practical to use binary remoting protocols for services that the 3rd party user does not know well? I think about the times in which I have been developing clients to services I don’t know (or didnt build for that matter) and I do usually end up looking at the message body when trying to troubleshoot any issues that might arise – and Hessian would be totally unworkable in that instance.

Anyway, to conclude, if you or a partner company are working in tandem and have a good working relationship then sure, its got to be Hessian all the way; its fast, its light weight… its all good. However if your exposing services for developers at a 3rd party, then you should really consider Burlap, as it could make someone else’s life so much easier. On the other hand, you could just be greedy and use Resin to expose Hessian, Burlap and SOAP!

It appears that flash has finally gone open source – craziness all round from Adobe at the moment.

http://aralbalkan.com/1332