Peter & Folks,
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/
Below is the proposal for this new Commons application. It is basically a speedier, more flexible, less cumbersome transport for method invocations.
At the moment it generates java source that must be compiled before use (use at the same points as rmic). In time we could shift this to BCEL using that would make the whole thing completely dynamic.
What this might give *us* is something that Phoenix could use internally for connecting blocks (inside or outside of SARs).
Regards,
- Paul H
-------------------------------------------------------------------------- JAKARTA COMMONS - ALTERNATE (TO) REMOTE METHOD INVOCATION - "ARMI" --------------------------------------------------------------------------
Abstract:
The ARMI package provides an alternative to Java's RMI. Apart from simply being an alternative it provides the following features:
1) Any interface publishing
- no forcing of extension of java.rmi.Remote - no forced declarations of "throws RemoteException"
2) Multiple transports
- Plain Sockets / ObjectStream - via RMI - Piped with same VM / ObjectStream - Direct within same VM - SOAP (planned) - CORBA (planned) - Plain sockets / custom messaging (planned) - JMS (planned)
3) Speed
- Using the ARMI over RMI transport as a baseline. Measuring 100,000 method invocations after discarding the first for the purposes of timing, ObjStream over sockets is three times faster, ObjStream over Pipe is eleven times faster, Direct is a thousand times faster. Granted there could be less of an advantage if compared to a proper RMI solution (not layered), or one that is in the same VM with different threads.
4) Interface/Impl separated design.
- ARMI can be build easily into any application or application framework. Individual aspects can be reimplemented (overridden) as the need arises.
Limitations:
1) Pass by value only.
- Unlike proper RMI, ARMI only currently supports "pass by value". If
an argument or return type were another ARMI published service, then
it could not currently be handled by ARMI. (to fix).
2) Generated "stubs" have to be in the client VM.
- Later we will allow server to pass forward implementation class
definitions as opposed to just newInstance() them as at present.
3) This is not of any use for EJB Home/Remote interfaces. The container
maker chooses the transport for use that container, not the bean coder.
This is intended for other client server solutions.
Initial commiters:
Paul Hammant (hammant)
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
