So, a couple of things jump out at me initially. the first is that it is a very interesting choice to put the iterator-like API beneath the stream API. the rmiio library has a remote iterator API which is built on top of the streaming API. the choice made in the remoting impls leads to some performance consequences. every remote retrieval operation for inputstream requires two remote calls (hasNext and next). additionally, for the collection based impls (IteratorObjectSource), every object retrieval requires two remote calls! since rmiio implements the iterator api on top of the streaming api (arguably more complicated), multiple objects can be retrieved in one call. and, there is no remote "hasNext" equivalent, just "read" which merely returns null when EOD is reached. lastly, since rmiiio uses streams, over-the-wire compression can be utilized to dramatically reduce the data transmission. the other big thing that stuck out to me is the lack of any idempotent guarantees. it's possible this is provided by the underlying framework, but, if not, it's a significant weakness. when systems get burdened, it's not unlikely for a given call to fail. looking at these implementations alone, that means lost data. the rmiio implementations allow the current read/write operation to be infinitely retried. another problem that's more related to remoting as a whole (at least in previous remoting versions), is the lack of an interface similar to java.rmi.server.Unreferenced. this becomes more important for things like streams which can be holding system resources which are relatively scarce (open file handles, database connections, etc). it's not uncommon for a client to die unexpectedly before the "close" method is invoked on the server. this will leave the stream resource open indefinitely. the rmiio implementations utilize the Unreferenced API so that when used with RMI proper, server resources will eventually be reclaimed if clients die before calling the remote "close". one last minor point is that i see no support for duplicate close calls (again, this could be managed elsewhere by the underlying framework). often, with appropriate usage of finally blocks, you may attempt to close a remote source multiple times. since the first successful call often shuts down the remote server, this can result in lots of annoying exceptions on the client side (because the source no longer exists when the second call goes through). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101920#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...