Skip to main content

GlassFish V2 and Phobos

Posted by robc on September 18, 2007 at 2:17 PM PDT

Once you have installed the new, awesome GlassFish V2 application server, you can download and install Phobos with just a few mouse clicks, using the included updatetool. Upon installation of the Phobos module, you'll find a newly created phobos directory under the root server directory, containing the Phobos framework, the libraries and some sample applications. Each sample comes with an ant script that can be used to build a regular war file, which you can then deploy to GlassFish using the asadmin deploy command.

The version of Phobos available from the GlassFish Update Center is 0.5.11, matching the one available as a set of NetBeans modules.

The first thing you'll notice about this release is that it's quite a bit smaller. This is due to the upgrade to Mozilla Rhino 1.6R7, which implements E4X on top of the DOM API, allowing us to stop shipping XML Beans. This shaves a good 2MB off the download.

Additionally, Rhino 1.6R7 adds support for JavaScript 1.5 language features, such as the const keyword and property get/set methods. See the Rhino documentation for more details.

In Phobos proper, in addition to some bug fixes, the major new functionality we added is an actor library (please refer to the Phobos jsdocs for the details of the API). We also enabled debugging of background threads in NetBeans, so that you can put breakpoints in and step through code executed by an actor.

Clearly inspired by Erlang and Scala, the actor library allows the creation of "actors" in JavaScript, defined as named functions which asynchronously process messages sent to them. Upon reception of a message, the function is executed in a separate thread, so it doesn't have access to the usual request and response objects. Much like Google Gears tasks, actors can only communicate by sending messages to each other or by making changes to shared resources, like a database or (not too often, hopefully) a global variable. Every actor has its own mailbox; messages sent to an actor are processed in strict sequential order. All messages are JSON-encoded, which makes them look like regular objects to JavaScript code.

Overall, it looks like a pleasant programming model for asynchronous activities. There is a lot of functionality which is missing when compared to Erlang, like the ability to pattern-match on messages and to make nested calls to the receive primitive, temporarily changing the behavior of an actor (or process in Erlang terms). On the other hand, much of this functionality can be emulated, albeit less elegantly, using regular JavaScript constructs. In principle, it should be possible to use something like Narrative JavaScript, whose compiler runs fine on Phobos, to compile an actor with nested receives to a "flat" one, but this would required some detailed investigation.

The interesting thing about the model I just described (actors as JavaScript functions, named by strings and exchanging JSON-encoded messages) is that it could be applied cross-tier. It should be possible to implement a similar API on top of Google Gears and have actor proxies on the client forward messages over HTTP to the server. Since actors are identified by a symbolic name and messages are by definition in JSON format, it would be easy to move an actor to a remote location without affecting other code on the same tier. I wonder if anyone has prototyped such a system...

Related Topics >>