During last days i played a little bit with EmberIO another java library trying to manage low-level IO. And before you read on i have to make one thing clear: I’m the lead developer of EJOE and my thoughts on EmberIO may not be as objective as they should be (and as i wish they would be).

As first i’ve to say that EmberIO isn’t that new for me, because before i started development of EJOE found an article at The Serverside.COM: Dispelling NIO myths. The article was written by Mike Spille the creator of EmberIO and contains some hints about the design goals behind EmberIO as well as some of the common mistakes made by the most NIO solutions (at least at the time the article was written). This article as well as the NIO hints on Mr. Spilles homepage have mainly stamped EJOEs architecture.

So the question is: “Are EmberIO and EJOE compareable?”. And after looking at EmberIOs sources i have to say that they aren’t compareable at all. But let’s take a look at the similiarities first:

• They both try to handle all network stuff.
• They offer some adjustable features to tune network IO.
• They both make heavily usage of the java non-blocking IO features.
• They both decouple IO connection accepting, reading and writing to support asynchronous thread and network operations.
• They both allow custom protocoll implementations, like soap, telnet or something proprietary.
• They both allow other client implementations to communicate with the server part as long as these clients are able to support some little special quirks. It’s funny that EmberIO and EJOE are using almost the same header informations between server and client.

So what are the obvious differences?

• EmberIO is fully event based, EJOE isn’t. EJOE is by design limited to a black-boxed request-response-pattern.
• EmberIO uses a abstract service pattern. You have to implement some EmberIO specific Interfaces – respectively abstract parent classes – to get part of EmberIOs event system. So you have to integrate your application into EmberIO respectively create a “EmberIO-Application”. EJOE offers a black-boxed server component. You integrate EJOE into your application and not otherwise.
• EmberIO differentiates between reader threads, processor threads and writer threads. EJOE uses two kinds of threads: combined reader/process threads and writer threads. So EmberIO supports a higher level of asynchronous processing.
• EmberIO doesn’t care about persistent/non-persistent connections, it’s let to you if you want support that or not. As of the time of this writing only EJOE CVS sources do support persistent connections. The last public release (0.3.2) uses a new connection for each client request. This is maybe the most major drawback of EJOE.
• EJOE supports the usage of partial blocking IO, especially to speed up object serialization/deserialization and to improve low-memory consumption when serving large objects. Look at this article for details. EmberIO doesn’t seem to support that. That would be maybe the most major drawback of EmberIO.
• EmberIO doesn’t contain an equivalent of EJOEs remote classloading support. Well, to be fair: remote classloading would be just another EmberIO service and should be easy to implement. In EJOE remote classloading is achieved via a second EJOE server instance which uses a special ServerHandler (EJOEs equivalent of EmberIOs services) and a clientside Classloader which just uses a EJOE client instance internally.
• EmberIO is a good thought API which is hard to understand but very extensible. EJOE isn’t so clean at all but seems to be a little bit easier to understand.
• EmberIO doesn’t seem to be under active development anymore. But maybe the development is done “behind the scenes”…anyway the last public release was EmberIO 0.3_Alpha, released on April, 25 2004. EJOEs development is very active. At the time of this writing the last public version of EJOE is 0.3.2, released on March, 06 2005.
• EmberIO seems to be more widely used than EJOE.

Conclusion:

EmberIO is a well thought, clean network library. It hides allmost all of the network stuff from your applications.
IO and thread handling is done efficiently, clean and very adjustable.
EmberIO isn’t black-boxed, you have to implement some EmberIO specific things (Services, EventPoints, Event Listeners) if you want use it.
EmberIO and the famous article “Dispelling NIO myths” has enlightened many NIO developers during a period where NIO knowledge was a rare thing.

EJOE on the other hand isn’t so clean designed internally. It hides all the network stuff from your applications as well.
IO and thread handling is done efficiently and adjustable. Whereby IO handling is maybe a little bit more adjustable than with EmberIO but EmberIO in turn supports a higher level of asynchronous thread processing.
EJOE is as far as possible black-boxed. Integration can be done with implementing one Interface. The client component is a ready to use black-boxed, bean-like component too: intantiate it, use it.

Comments as well as critism is appreciated and always welcome. Just send your comments to mailto:netseekerATmanskesDOTde.

Leave a Reply

Using Gravatars in the comments - get your own and be recognized!

XHTML: These are some of the tags you can use: <a href=""> <b> <blockquote> <code> <em> <i> <strike> <strong>