avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Armi - Alternate to RMI (Commons-scratchpad)
Date Sat, 29 Dec 2001 10:45:56 GMT
Peter & Folks,


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).


- Paul H



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 
    Individual aspects can be reimplemented (overridden) as the need arises.


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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message