1. Why rewrite RMI? What are the original RMI problems?
When you make a remote method call through RMI nothing can guarantees the way or how RMI will transport it at the communication layer. And when you lose control over this, maybe your application cannot work correctly in all enviroments you would like.
The optimized scenario when the application user is connecting through the Internet is: the communication latency must be minimal; and user must be able to connect without changing anything in it's network's topology to use the application.
With Java RMI we lose in both points: the communication comes with high cost (using so much bandwidth - and sometimes causing an unwanted latency) and requires the user has a valid Internet IP with some ports opened and free to others connect to (and maybe our user would need to make some changes in it's network's topology for guarantees this).
Of these two problems, high bandwidth usage isn't the worst, but can be optimized.
The major problem comes when user needs to reconfigure it's network to use your application that uses RMI - and the consequence for this can be obvious: the abandonment and not usage of application.
The problem at RMI communication layer is: for pratically one method invocation, a new socket is created; and the socket's connection do not follow a unidirecional way, in such a way client and server can try connect one to other.
When we use callback's with RMI we need to export a object in client's application, which creates a listening ServerSocket in client. If your client is through a local network, router, NAT or firewall, this ServerSocket probabilly will never be reached - and remote callback calls will not be made.
Resuming, if you developed an application targeted to final user which need callback usage, everytime a new user wants to use your application he will must ask his local network administrator to configure rules for allow/redirect incoming Internet connections. Impracticable for a desktop application, isn't?
All this issues happens for only reason - a well known reason, by the way - RMI originally wasn't developed to be used in Internet enviroment.
LipeRMI comes to resolve this things ;o)
2. Sun's doesn't already allow us to rewrite SocketFactorys?
The Java RMI allow us to rewrite it's SocketFactory's. At first time, sounds good enough to solve the whole problem, but in fact is not. RMI, through this factorys, let us to modify socket's stream and some other propertys. But what continues deciding until a socket must be active or when create new sockets still being RMI.
3. What you mean with 'callback'?
RMI callbacks
occurs
when you register a remote listener (i.e., the client
exports an object to receive
asynchronous
messages).
4. Okay, so what is the LipeRMI proposal?
The main goal of LipeRMI is to rewrite Java RMI in such a way it allow calls can be made through Internet (without any change in user network enviroment) and minimize bandwidth usage.
Also, this new implementation must offer a RMI-like API, demanding just few adjusts to any RMI-ready application can quickly start using LipeRMI.
Most popular Internet applications uses a very simple concept to comunicate over the Internet: always any client needs to send data to a server, the client (and always only the client) must establish the connection, if there's none. And is through this same connection the server send data back do client.
The server must only be listening some specific port. With this well known fixed ports we can create, if necessary, any rule in server network enviroment to allow clients connect to.
After the client already connected, this connection must remain active and open along all the time which we need to transfer data between client and server; or until the application explicit closes it. This way the server won't need open connections to the clients because there is a connected one already. Without this needing of reach clients, the clients won't need to worry about firewalls or it network's topology - solving the major RMI problem.
5. How closer LipeRMI will be from original Java RMI?
I don't see any advantage to use exactly the same API which Sun uses. This new reimplementation must be a little for ahead and must improve anything is possible, including API.
By the way, let's see an example. Another RMI problem is how to know along the application session which remote clients remains active. And with Java RMI the only way to know this is testing the client; ie. invocating some dummy-ping-test-method and catching exceptions - which costs some precious bandwidth.
Now, with LipeRMI API you can use listeners to know at realtime when a new connection was established or closed; saving your bandwidth and making your application more clean and readable.
6. You said LipeRMI is quickly than RMI, how much?
It's hard to measure. But i am inviting you to test LipeRMI with your application.
Since LipeRMI compress all data transfered, the bandwidth usage is lower than the used by RMI. Also, as LipeRMI already have its socket opens no handshake is required, making the calls in realtime.
7. How much it costs?
LipeRMI is free, man. FREE!
what is
