adam bien's blog

Would be Glassfish v3 a better Darkstar? 📎

I reviewed last week the Sun Gaming Server, also called Darkstar. The architecture is interesting. The server supports "ManagedObjects" which are controlled by the server. A ManagedObject is thread safe (from the developer perspective it looks like a monothreaded instance) and has access to resources like Channels (for Pub/Sub communication), and almost POJO-based persistence. The Darkstar Server is also transactional, and provides support for user-sessions. Actually from the conceptual point of view Darkstar is very similar to an Java EE Server, even the programming model and the best practices are almost identical. It seems like Darkstar was developed from scratch, so it does not reuse the Grizzly framework from Glassfish and it doesn't come with monitoring capabilities. Darkstar supports  the  client-server, as well as a publish-subscribe programming model. In both cases asynchronous communication takes place between the client and the server. Basically a byte-array can be send with invocation of the method "send". Both communication style are very similar to JMS. The point to point style can be easily realized with javax.jms.Queues, the publish-subscribe with javax.jms.Topics. For sending byte arrays the javax.jms.BytesMessage could be used. One benefit of darkstar ist the ordering of messages - this cannot be easily implemented with Java EE.
The Client-Session is a classic sample for Stateful Session Bean - it's exaclty the same 1:1 communication model. The next "added" value of Darkstar are singletons, which are not a part of the EJB 3.0 specification, but will probably come with EJB 3.1. Singletons little bit problematic in a Java EE environment, because the semantic of this pattern just does not work in multiple VMs.

The Darkstar's persistence is neither so simple, nor powerful and cannot be compared with JPA. It seems like Darkstar uses serialization for the persisting the object. The developer has to use special reference objects to connect persistent objects together. From my perspective the JPA framework, perhaps with own "darkstar-provider",  would do  a much better job, than a home-grown solution.

Also darkstar's TimedTask facility could be easily replaced with EJB's timers.

Darkstar is very interesting projects which already works well. The best proof of concept is the Wonderland project (a private second life :-)), which uses Darkstar as back-end.
Although Darkstar seems to scale, it would be better to use the synergies with Glassfish and rely on a common infrastructure. From my perspective it would be better to provide a lean, domain specific, layer on top of Glassfish (perhaps with real time extensions), than building a whole server from scratch. Glassfish already comes with some facilities like Shoal (clustering solution), Grizzly and HK2.