Mark Baker wrote:
> On 6/28/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>>The returned InputStream is actually an Serializable object which connects
>>back
>>to the server using data provided in the serialized form. The client then
>>calls
>>read et.al. on the InputStream which is intern forwarded to the Socket that
>>goes
>>back to the server. Presto, you have socket based streaming in an RMI call.
Please pardon my yping mistakes... The wording above is horribly broken...
>>The performance is great and I didn't have to break the programming model to
>>meet the performance needs of the client. I did it all with mobile code that
>>the service architect decided on the implementation of.
>
> Sounds interesting, but I'd bet you $100 that an HTTP based solution
> would kick its ass performance-wise. 8-)
>
> HTTP, and many client and server implementations, are optimized
> primarily for data transfer performance. Neither the RMI protocol,
> nor the implementation, is.
Mark, I probably wasn't clear enough. The RMI method call returns an object of
type InputStream. In Java InputStream is a class, not an interface. However,
all methods can be overridden, and it can be subclassed and that subclass
tagged
as Serializable. Here is an example of this classes definition.
public class RemoteSocketStream extends InputStream implements Serializable {
String addr;
int port;
Uuid key;
transient InputStream instr;
transient Socket sock;
// Constructor used on server to create the object that will
// be returned by the remote call.
public RemoteSocketStream( String addr, int port, Uuid key ) {
this.addr = addr;
this.port = port;
this.key = key;
}
// This is called by the Serialization implementation associated
// with the JVM implementation. When this object is received on
// a remote JVM, this method is called to create the state of
// the object for that JVM.
private void readObject( ObjectInputStream is ) throws IOException,
ClassNotFoundException {
// Read the object state that was serialized
is.defaultReadObject();
sock = new Socket( addr, port );
instr = sock.getInputStream();
// Write the key that identifies us to the server, simple
// authentication, could use SSL or something better as needed.
sock.getOutputStream().write( keyToBuffer( key ) );
sock.getOutputStream().flush();
}
public int read( byte[]data, int off, int cnt ) {
return instr.read( data, off, cnt );
}
// Allow a subclass access to the socket if the need to
// perform writes down it etc.
protected Socket getSocket() {
return sock;
}
... other methods for InputStream overrides to delegate to instr ...
}
So, in the end, I have a TCP stream. The initial RMI exchange to get the
socket
will be very similar to the initial HTTP request to open the socket. For
extremely small transfers, you might find that HTTP would be slightly better
because of the extra socket open not occuring. But, for large scale transfers,
where the use of a streaming socket connection is and advantage, I don't think
you'd find there to be any particular advantage to using HTTP.
The first use of this was for a remote logging monitoring. I subclassed this
class and translated the API for configuring the java.util.logging.Handler on
the server end into writes down the socket. The operations were all void
returns, so I could asynchronously write the operations down the socket and not
wait for a reply.
In an early post I talked about the use of HTTP and how there are turn around
points in the protocol which segment the use an HTTP session into specific
direction (client->server, server->client). In the use of a socket in the
above
fashion, I don't have to deal with this. I'm not sure how I would use a single
HTTP session to continuously monitor a logging session on a remote server, and
send configuration changes back down that socket asynchronously. I'm not sure
that I could do it synchronously without reopening the session.
Gregg Wonderly
------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
