Hi,
Yesterday I came up with a wild though concerning async object
serialization, and I'm interested in feedback on the usefulness /
feasibility of the idea...
While sending objects back and forth over an ObjectOutputStream wrapping
a (classical non NIO) socket's outputstream, I was wondering whether it
would be possible to make a nonblocking implementation of what I was
doing... JAVA's implementation of Object streams is inherently
synchronous, forcing both the reading and writing end to block upon any
read/write operation. It would be possible to create a (pseudo-)
nonblocking alternative if it was possible to determine the size of a
completely serialized object beforehand, and then sending the size
before you actually transmit the object. That way, the receiving end
will know how many bytes are needed before the Object can be
deserialized again in one go... (so no more socket operations are needed
to deserialize the object)...
As I said, yesterday I came up with the idea that it is (at least
theoretically) possible to make an asynchronous implementation of the
serialization process! Indeed, as the serialized data conforms to a
`grammar' of some sort (I'm not sure whether this is the right term to
use here), it is perfectly possible to process a few bytes, yielding a
state containing a partially constructed object, and then continuing
object reconstruction when more data comes available.
Such implementation would make it possible to accept socket connections,
and to start reading whole objects from these connections, in an
asynchronous matter, as there is now no need to read whole objects in
one blow. This eliminates the need of a dedicated thread looping over
calls to objectOutputStream.readObject() ...
As my explanation is probably unclear, let's write some pseudo-code
interface ObjectHandler {
/**
* Process a newly deserialized object
* E.g. put object in some sort of queue, ...
* @param object
*/
void handle( Object object );
}
public interface ObjectDeserializer {
/**
* Called from the asynchronous socket API to offer new bytes
* to the deserializer
* If one or more complete object are read during the processing
* of the buffer, they are passed on to the registered object
* handler...
* @param buffer
*/
void offer( byte[] buffer );
/**
* Register a handler with this deserializer
* @param handler
*/
void setHandler( ObjectHandler handler );
}
So the class ObjectDeserializer will form the link between the low-level
socket API and a (sort-of) asynchronous object producing API...
In my view, an implementation of ObjectDeserializer for the Hessian
binary web protocol is certainly possible, on top of that, I suppose
plain old java Object streams can have an asynchronous implementation,
although it will be quite tedious to implement ;-)
I see applications for such a solution in software where lots of Object
communication between many endpoints, in a send-and-forget manner. I
came up with the idea while experimenting and thinking about
point-to-point object communications within a (larger) computer cluster.
The reason I post this, is to poll whether there would be interest in
such an implementation, and to communicate my idea to the wider world ;)
Kind Regards,
Wouter