For the uninitiated, Raspberry Pi is a credit-card-sized single-board computer, very popular amongst tinkerers and hobbyists for it’s ease of use and low cost.

We’ve made number of changes in recent releases to allow Resin to run on a Raspberry Pi. These included both Java fixes and compilation of Resin’s native libraries. Both Resin Pro and Resin GPL Servlet Container will run with native optimizations enabled on Raspberry Pi.

More information including minor required configuration change is available on Caucho’s Resin 4 Wiki: Resi On Raspberry Pi

Resin can generate two slightly different PDF health reports: Snapshot and Watchdog reports. A Snapshot Report captures a “snapshot” of Resin at the current point in time. A Watchdog Report aggregates as much information as available about Resin at a “previous” point in time. Watchdog reports can also be thought of as a “post-mortem” or “restart” report, as they usually are generated immediately after an unexpected server restart.

Snapshot reports can be generated on the command-line:

via REST:

or via Resin-Admin on the PDF Page:

Watchdog report are usually generated automatically after any unexpected server restart. Check your logs directory for Watchdog-*.pdf files. However you can always regenerate a Watchdog report from Resin-Admin on the Watchdog Page:

The Resin Administration Console video on YouTube provides an excellent overview of Resin-Admin and PDF Health Report content.

• traits

  <?php
  
  trait T0 {
    function foo()
    {
      echo "inside T0->foo()\n";
    }
  }
  
  class A {
    use T0;
  }
  
  $a = new A();
  $a->foo();
  
  ?>
  

• short array syntax

  <?php
  
  $a = ["a" => 123, "b" => 456];
  
  ?>
  

• function array dereferencing

  <?php
  
  $a[0]();
  
  ?>
  

• $this use in closures

  <?php
  
  class A {
    var $foo = 123;
  
    function test() {
      $fun = function() {
        var_dump($this->foo);
      };
  
      $fun();
    }
  }
  
  $a = new A();
  $a->test();
  
  ?>
  

• <?= short open tag is now always on

  <?php
  
    $hello = "hello world";
  
  ?>
  <b><?= $hello ?></b>
  

• class member access on instantiation

  <?php
  
  class A
  {
    function foo()
    {
      echo "inside A->foo()\n";
    }
  }
  
  (new A())->foo();
  
  ?>
  

• Class::{expr}() syntax

  <?php
  
  class A
  {
    static function foo()
    {
      echo "inside A::foo()\n";
    }
  }
  
  $name = "foo";
  A::{$name}();
  
  ?>
  

• binary number format: 0b001001101

  <?php
  
  // int(7)
  var_dump(0b111);
  
  ?>
  

• $_SERVER['REQUEST_TIME_FLOAT'] is populated

  <?php
  
  // returns a float (i.e. float(1356829982.6495))
  var_dump($_SERVER['REQUEST_TIME_FLOAT']);
  
  ?>
  

And for those that are still with me, I’m aiming to have PHP 5.5 support in our 4.0.35 release :).

– Nam

Nam Nguyen is a Software Engineer at Caucho Technology in San Diego/San Francisco. He is currently the lead for the Quercus project.

It’s been a 3.5 years ago to this day since I last wrote about running Quercus on Google App Engine (GAE). The article detailed a crazy experiment to get a PHP application, Wordpress, running on GAE. I still remember it being a painful experience because of number of changes I had to make to Wordpress to get it working. It was all due to the GAE Java environment being so drastically different from what Java developers were used to. It was heavily sandboxed and had no SQL support. You couldn’t launch new Threads. You couldn’t write to the file system. But those were the tradeoffs you had to live with if you wanted to deploy your application to the all-wonderful Cloud.

Fast-forward to 2012 and GAE has come a long way. GAE now allows you to spawn new Threads (currently in beta). You still cannot write to the file system, but for all it’s worth there is a new GAE Files API that gives you file-like concepts. And you can run your very own MySQL instances on Google’s infrastructure (albeit Google’s customized version of MySQL).

What hasn’t changed over the years is that you’re still expected to hit major roadblocks as you migrate your existing web applications over to GAE. And you’ll have to make heavy modifications to your application to 1) make it work and 2) be performant on GAE.

So this is where Quercus comes into the picture. At Caucho, we spent a lot of time getting Quercus to work seamlessly with GAE. Our goal was to abstract the GAE details away so that developers don’t have to worry about the fact that the application is running on GAE. Things just work transparently behind the scenes for PHP applications. For example,

• PHP file_*() functions work just like they do before (including writing to files!)
• PHP mysql_*() functions and PDO work just like they do before

What this means is that we can run existing PHP applications on GAE without any modifications! Say hello to “Wordpress on Google App Engine” 2.0! But first, let’s start with some formalities.

I. Introduction to Quercus

Quercus is Caucho’s 100% Java implementation of the PHP language runtime and libraries. Currently, Quercus supports PHP 5.3 language features and contains a multitude of libraries developed in-house including but not limited to apc, bcmath, curl, date, dom, filter, gettext, json, mail, mbstring, mcrypt, pdf, pdo, postgres, reflection, regexp, spl, zip, and zlib.

Quercus can run as a servlet or on the command line. For our case, we’re interested in running it as a servlet:

1. Download Resin Java Application Server and it’ll come with Quercus enabled by default and ready to go.
2. Uncompress the archive and start up Resin with:

       ./bin/resin.sh console

3. Then create a webapps/ROOT/test.php file with the following contents:

   <?php
   
     phpinfo();
   
   ?>

4. Browse to http://localhost:8080/test.php and you should see the following:

   

Congrats! You have PHP running natively on a Java server.

II. Running Quercus on Tomcat

Okay, so you want to use Tomcat instead of Resin? No worries.

1. Copy lib/resin.jar from the Resin download above to Tomcat’s webapps/ROOT/WEB-INF/lib directory.
2. Add QuercusServlet to Tomcat’s webapps/ROOT/WEB-INF/web.xml file:

   <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">
     <servlet>
       <servlet-name>Quercus Servlet</servlet-name>
       <servlet-class>com.caucho.quercus.servlet.GoogleQuercusServlet</servlet-class>
       <init-param>
         <param-name>ini-file</param-name>
         <param-value>WEB-INF/php.ini</param-value>
       </init-param>
     </servlet>
   
     <servlet-mapping>
       <servlet-name>Quercus Servlet</servlet-name>
       <url-pattern>*.php</url-pattern>
     </servlet-mapping>
   
     <welcome-file-list>
       <welcome-file>index.php</welcome-file>
     </welcome-file-list>
   </web-app>

Quercus should now be handling all php HTTP requests.

III. Running Quercus on GAE

Quercus runs on top of the GAE Java SDK, so we configure it just like any other servlet. Before continuing, please read and work through Google’s Getting Started: Java – Google App Engine.

1. Create a new GAE project by creating the following directories on your local drive:

       quercusproject
       quercusproject/src
       quercusproject/war
       quercusproject/war/WEB-INF
       quercusproject/war/WEB-INF/lib

2. Copy lib/resin.jar from the Resin download above to quercusproject/war/WEB-INF/lib. Note: I’ve created a special pre-release Quercus snapshot just this article. Please download it here on GitHub and use the included jars instead. The snapshot exposes functionality unique to GAE that we originally had hidden.
3. Create a quercusproject/war/WEB-INF/web.xml file for GoogleQuercusServlet:

   <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">
     <servlet>
       <servlet-name>Quercus Servlet</servlet-name>
       <servlet-class>com.caucho.quercus.servlet.GoogleQuercusServlet</servlet-class>
   
       <init-param>
         <param-name>ini-file</param-name>
         <param-value>WEB-INF/php.ini</param-value>
       </init-param>
     </servlet>
   
     <servlet-mapping>
       <servlet-name>Quercus Servlet</servlet-name>
       <url-pattern>*.php</url-pattern>
     </servlet-mapping>
   
     <welcome-file-list>
       <welcome-file>index.php</welcome-file>
     </welcome-file-list>
   </web-app>

4. Create a quercusproject/war/WEB-INF/appengine-web.xml file:

   <?xml version="1.0" encoding="utf-8"?>
   <appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
     <application>your_app_id_here</application>
     <version>1</version>
   
     <threadsafe>true</threadsafe>
   
     <static-files>
       <exclude path="/**.php" />
     </static-files>
   </appengine-web-app>

   Note: remember to change “your_app_id_here” to your actual appspot application ID when deploying to GAE.

5. Create a quercusproject/war/test.php file:

   <?php phpinfo(); ?>

6. Start up the GAE development server with Eclipse or with ant:

   ant runserver

7. Browse to http://localhost:8080/test.php
   and you should reach the PHP info page titled “Quercus”.

At this point, the test project should be complete and deployable to GAE.

IV. Writing to files on GAE

GAE does not allow applications to write to the local file system. However, Google recently added a files-like API (com.google.appengine.api.files) that applications can use to write streams to GAE DataStore or Google Cloud Storage. Quercus leverages this API to grant write capability to PHP file functions. In addition, Quercus goes a step further and merges the local and network file systems together to create a unified view. For example, consider the following script:

<pre>
<?php

  $filename = 'test.txt';
  var_dump(file_get_contents($filename));

  file_put_contents($filename, 'modified at time ' . date('Y-m-d H:i:s O'));
  var_dump(file_get_contents($filename));

?>

Suppose the file test.txt exists on the local file system. The first file_get_contents() call retrieves it. Then we try to overwrite that file. But since GAE does not allow writes to the local file system, Quercus writes to Google Cloud Storage instead. The next file_get_contents() call retrieves the newly-written file with the new data, not the old local file. And if the network file is cached in memcache, Quercus will serve that instead. This is all done transparently behind-the-scenes and at no point is the application aware that it’s not reading/writing to the local file system.

A. Setting up Quercus to use Google Cloud Storage

Google Cloud Storage is structured around uniquely-named buckets, which are very similar to mounted disk drives. As with regular drives, buckets can hold a hierarchical list of files and directories. To start things off, we need to enable Google Cloud Storage, create a bucket, and grant our application access to Google Cloud Storage.

1. Activate Google Cloud Storageand enable billing.Google Cloud Storage is free for the first 5GB of storage.
2. Go to your Google API Console=> Google Cloud Storage => Google Cloud Storage Manager. Create a new bucket named “quercusbucket0”.If you cannot create a new bucket, then it’s very likely your billing is not enabled or is still pending.
3. Go to your Google App Engine Overview => select or create your application => Application Settings. Make a note of the application’s “Service Account Name”. Then go to Google API Console=> Team. Create a new teammate with the “Service Account Name”.Note: if you had just created a new application, remember to update your
   quercusproject/war/WEB-INF/appengine-web.xml with the actual application ID.
4. Your GAE application should now has access to most of your Google APIs including Google Cloud Storage (but not Google Cloud SQL unfortunately). We now need to give Quercus the name of the bucket we just created. We do so by setting a servlet init-param in the web.xml file:

   <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">
     <servlet>
       <servlet-name>Quercus Servlet</servlet-name>
       <servlet-class>com.caucho.quercus.servlet.GoogleQuercusServlet</servlet-class>
   
       <init-param>
         <param-name>ini-file</param-name>
         <param-value>WEB-INF/php.ini</param-value>
       </init-param>
   
       <init-param>
         <param-name>cloud-storage-bucket</param-name>
         <param-value>quercusbucket0</param-value>
       </init-param>
     </servlet>
   
     <servlet-mapping>
       <servlet-name>Quercus Servlet</servlet-name>
       <url-pattern>*.php</url-pattern>
     </servlet-mapping>
   
     <welcome-file-list>
       <welcome-file>index.php</welcome-file>
     </welcome-file-list>
   </web-app>

   Note: the bucket name can also be set in a php.ini file, but that capability is broken at the moment.

   Note: you do not need to enable Google Cloud Storage and billing in order to test on the development server, but you do need to set <cloud-storage-bucket>.

5. Create a quercusproject/war/vfs.php file with the following:

   <pre>
   <?php
   
     $filename = 'test.txt';
     var_dump(file_get_contents($filename));
   
     file_put_contents($filename, 'modified at time ' . date('Y-m-d H:i:s O'));
     var_dump(file_get_contents($filename));
   
   ?>

6. Launch the development server or deploy to GAE. Browse to the vfs.php page. Refresh a few times. You should see something like the following:

   string(42) "modified at time 2012-12-05 22:04:21 +0000"
   string(42) "modified at time 2012-12-05 22:25:28 +0000”

V. Executing SQL queries on GAE

For the longest time, Google’s distributed key-value store was GAE’s only persistent store option. However not all use cases can be boxed into key-values, so Google Cloud SQL was a welcome addition to GAE. It does come at a price because Cloud SQL has no free quota and you’re forced to pay from the start.

Update: as of 2012-11-08, Google is offering a free 6-month trial for a tiny D0 instance.

As with the PHP file functions, Quercus transparently maps PHP mysql and PDO functions to Cloud SQL. The only caveat is that the host url must begin with “jdbc:google:rdbms://” instead of localhost or a remote IP or domain name. Quercus will recognize the following and connect to Cloud SQL appropriately:

<?php

  $db = mysql_connect('jdbc:google:rdbms://foo:bar');

?>

A. Setting up the Development Server to use local MySQL

To do testing, we need to set up the development server to use the local
MySQL instance.

1. Download the MySQL JDBC driver at http://dev.mysql.com/downloads/connector/j/. Uncompress mysql-connector-java-5.1.22.tar.gz and place mysql-connector-java-5.1.22-bin.jar into your
   <appengine-sdk>/lib/impl directory.
2. Follow the instructions at Google’s Using a Local MySQL Instance During Development.If you’re using ant, then all you need to do is add the following to your build.xml:

     <target name="runserver" depends="datanucleusenhance"
         description="Starts the development server.">
       <dev_appserver war="war">
         <options>
           <arg value="--jvm_flag=-Drdbms.server=local"/>
           <arg value="--jvm_flag=-Drdbms.driver=com.mysql.jdbc.Driver"/>
           <arg value="--jvm_flag=-Drdbms.url=jdbc:mysql://127.0.0.1:3306/wordpress0?user=root"/>
         </options>
       </dev_appserver>
     </target>

   For the development server only, any dummy JDBC url string that begins with
   jdbc:google:rdbms// gets redirected to the local MySQL instance. But you still need to pass in the correct credentials to the mysql functions for both the development server and GAE:

     // $user and $pass must be valid
     // Google Cloud SQL default user is "root" with an empty password
     $db = mysql_connect('jdbc:google:rdbms://foo:bar', $user, $pass);

B. Setting up Google Cloud SQL

If we wish to deploy to GAE, we also need to enable Google Cloud SQL and billing.

1. Activate Google Cloud SQLand turn on billing. Create a new Cloud SQL instance.Google Cloud SQL is priced at two levels: a per-month or a per-use plan. There is currently no free trial quota.
2. Grant your application access to the newly-created Cloud SQL instance.
3. Create a quercusproject/war/mysql.php file with the following:

   <pre>
   <?php
   
     $jdbc_url = 'jdbc:google:rdbms//project_name:instance_name';
     $db = mysql_connect($jdbc_url);
   
     $result = mysql_query('SHOW DATABASES', $db);
   
     while (($row = mysql_fetch_assoc($result))) {
       var_dump($row);
     }
   
   ?>

   Note: remember to update $jdbc_url with the actual JDBC url for your MySQL instance.

   Note: Google Cloud SQL’s “root” user has an empty default password.

4. Deploy the application to GAE and browse to mysql.php. You should see a list of database names from your MySQL instance.

VI. Putting it all together – Running Wordpress on GAE

We now have all the pieces to install a stock Wordpress onto GAE.

1. Download Wordpress at http://wordpress.org/download/.
2. Uncompress the archive into your quercusproject/war directory.
3. Make sure the bucket name is set in web.xml.
4. Create a new MySQL database for Wordpress:

       CREATE DATABASE wordpress0;

5. Deploy your application to GAE.
6. Browse to wordpress/ and follow the prompts to install Wordpress. The default database user should be “root” with an empty password. Your Google Cloud SQL instance’s base JDBC URL should go into the “Database Host” field. Wordpress will automatically create a custom config file and populate the database with initial data.

   

7. Wordpress will then prompt you to configure an admin account:

   

8. And then you’re done!

   

Congrats! Your blog is installed and lives in the Cloud.

Here is a sample Wordpress site running on GAE: http://wordpress-on-quercus-2.appspot.com/

VII. Source Code

The source code for the examples are available on GitHub.

http://wiki4.caucho.com/Cloud:_Cluster-Wide_Configuration_Using_HTTP

For the most part we liked the press coverage we got.
Thanks Liam Eagle for covering our press release. Had your comment box worked this blog post might not exist.

Liam wrote the following:

Caucho’s press release references “benchmark tests between Resin and NGINX,” and “numerous and varying tests,” which it says delivered competitive figures, with Resin leading with fewer errors and faster response times. In particular, it says, Resin sustained fast response times under heavy load while NGINX degraded.

The announcement does not describe the testing methodology, however, which raises the obvious question of whether the tests, which appear to have been conducted by Caucho itself, were somehow stacked in favor of the company’s own web server.

Press releases are usually short and light on technical detail. However, all syndication of our press release had a link to the exact testing methodology that we used (linked text was “benchmark tests prove”).

We tried to keep our benchmark fairly simple and fair. We used three files: a 0k (almost empty HTML page), a 1k file, an 8k file and a 64k file. Then we used AutoBench, which uses httperf to test throughput. The benchmark does not raise the obvious question of whether the tests were stacked in our favor as the test was fairly straightforward and done with tools that are industry standards for benchmarking. Benchmarks can be really flawed. We hate flawed benchmarks.

We felt like this benchmark was a good demonstration of the file sizes that most web application servers serve, and we based this on a few studies and our own experience. Let us know how we can improve the test to be more fair.

You may think of us as a vendor. We think of ourselves as a bunch of engineers who sit around and ask questions like: “is NginX faster and if so why?”. Then we come up with a plan to match or beat the speed. Then we devise a benchmark. Then we test. Then we make improvements. It is nice to have a worthy competitor like NginX. Resin has always been really fast, but competition from NginX has made us faster. We love not only the outcome, but the journey and craftsmanship it took to get there. The reason we wouldn’t game the benchmark is that would take all of the fun out of it. We would have to start wearing suits and going to meetings with powerpoint slides. Our souls are intact. We are software developers. We are engineers.

Liam wrote the following:

So it is probably not surprising that up-and-coming web server products would intentionally prompt comparisons to NGINX. In a similar way, NGINX was quick to initiate comparisons to Microsoft’s IIS as it approached the popular web server in market share.

Thank you for the compliment. We think that Resin has a lot of promise of continued success as well.
When a lot of people think of up-and-coming, they might think of new. Resin has been around longer than NginX. In two more years, Resin will be old enough to drive a car in California. Resin’s 14 year success is largely attributed to its performance. Resin’s strong growth is a welcome site for battle-hardened veteran of the web. Leading companies worldwide with demands for reliability and high performance web applications including the Toronto Stock Exchange, Salesforce.com and CNET are powered by Resin.

The NginX form had a post as follows:
http://forum.nginx.org/read.php?2,229872,229873#msg-229873

What nginx configuration was used during the testing? Did they tune it?
Did Resin use an equivalent level of logging? What build options were used
to build nginx? Why did they test on 1k page? I don’t think that the average
size of typical web-page and its elements are about 1 Kb. Does it mean that
the Resin cannot effectively handle files of more size? What about memory
usage? And after all, why did they use the latest version of Resin and
relatively old version of nginx?

All syndication of our press release had a link to the exact testing methodology that we used, which is on our wiki. This page and this blog post will answer all of your questions except for why we used NginX 1.2.0.

The press release was done in August. NginX 1.2.0 was used for the test and it was released in April. NginX 1.2.2 was released on July 3rd. We began benchmarking in June. The latest stable release was 1.2.0 at that time. There are no speedups documented in the release notes for 1.2.2 or 1.2.3 file with regard to HTTP file delivery. We also did benchmarking with an older versin of NginX prior to June and did see an NginX speedup from the earlier version. (We used to be further ahead, but we did not publish that benchmark.)

Feel free to benchmark against 1.2.2 or 1.2.3, and send us the results.

Summary: Using industry standard tool and methodology, Resin Pro web server was put to the test versus Nginx, a popular web server with a reputation for efficiency and performance. Nginx is known to be faster and more reliable under load than the popular Apache HTTPD. Benchmark tests between Resin and Nginx yielded competitive figures, with Resin leading with fewer errors and faster response times. In numerous and varying tests, Resin handled 20% to 25% more load while still outperforming Nginx. In particular, Resin was able to sustain fast response times under extremely heavy load while Nginx performance degraded. (See related press release).

Benchmark tools

The benchmark tests used the following tools:

• httperf
• AutoBench

httperf

httperf is tool produced by HP for measuring web server performance. The httperf tool supports HTTP/1.1 keepalives and SSL protocols.

AutoBench

Autobench is a tool for automating the process of performing a comparative benchmark test against two a web servers. Autobench uses httperf. Autobench runs httperf against each host. AutoBench increases the number of requests per seconds on each iteration. AutoBench delivers output in a format that can be easily consumed by spreadsheet tools. AutoBench has a mode where it can drive multiple clients against a set of servers to minimize the possibility of testing your client throughput instead of server throughput. The command autobenchd is used to run a
daemon on client machines. The autobench_admin command drives many clients to run test at same time by communicating with autobenchd.

Setup Overview

Configuration

The only change that was made was the worker_processes were set to 8 for NginX to improve throughput.

Hardware Software Specifications

Client HW/OS specs:

• i7 4 core / 8 HT, 2.8 GHZ, 8Meg Cache, 8 GB RAM.
• Ubuntu 12 / Linux Kernel 3.2.0-26-generic

Server HW specs:

• i7 4 core / 8 HT, 2.8 GHZ, 8Meg Cache, 8 GB RAM.
• Ubuntu 12 / Linux Kernel 3.2.0-26-generic

Test software:

• Autobench 2.1.1
• httperf 0.9.0

Software under test:

• Resin Pro 4.0.29
• nginx 1.2.0

0k test

Command Line Arguments

0k.sh

./admin.sh 300000 2000 20000 1000 0k

admin.sh

autobench_admin
--clients xen:4600,lancre:4600
--uri1 /file_$5.html
--host1 ch_resin --port1 8080
--uri2 /file_$5.html
--host2 ch_nginx --port2 80
--num_conn $1
--num_call 10
--low_rate $2
--high_rate $3
--rate_step $4
--timeout 3
--file out_con$1_start$2_end$3_step$4_$5.tsv

Above is used to setup 300,000 connections at a rate of 20,000 to 200,000 requests per second.
Each iteration increases the rate by 10,000 from 20,000 to 200,000.

0k html file file_0k.html

 <html>
 <body>
 <pre></pre>
 </body>
 </html>

0k full Results for 0K test

1K test

Command line

1k.sh

./admin.sh 200000 1000 10000 250 1k

admin.sh

autobench_admin
--clients xen.caucho.com:4600,lancre.caucho.com:4600
--uri1 /file_$5.html
--host1 ch_resin --port1 8080
--uri2 /file_$5.html
--host2 ch_nginx --port2 80
--num_conn $1
--num_call 10
--low_rate $2
--high_rate $3
--rate_step $4
--timeout 3
--file out_con$1_start$2_end$3_step$4_$5.tsv

1k.html

html>
<body>
<pre>
0 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
1 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
2 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
3 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
4 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
5 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
6 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
7 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
8 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
9 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
</pre>
</body>
</html>

1k full Results for 1K test

8K test

64K test

Hessian (now Hessian 2) predates many other forms of remoting and is a [http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/ wicked fast, binary protocol] (faster than CORBA, RMI, SOAP, XML-RPC, etc). You could think of Hessian as a high performance binary JSON. Hessian has been ported to many languages. Hessian is a remoting framework and a flexible Java serialization framework.

You can expose any bean as a Hessian remote bean quite easily. Hessian has been around for 10 years, and is very solid. (Both Hessian and Resin are development and maintained by Caucho).

Resin 4 documentation does not have Hessian documentation yet, but Hessian usage has not changed in years. You can find a good tutorial on getting started with Hessian from the [http://www.caucho.com/resin-3.0/protocols/hessian.xtp Resin 3 documentation]. I’ve tried these tutorial steps in Resin 4 and the tutorial works as advertised.

Resin 4 is Java EE Web Profile certified as such it does not support CORBA, EJB remoting, etc. However Resin does support Java Dependency Injection (CDI), which allows you to easily find beans with certain annotations. What follows is a simple example that finds all @Stateless beans that have @Remote interfaces and automatically exposes those beans as remote hessian objects.

To learn more go to our wiki for Resin 4 Java EE WebProfile application server.