Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3C3DD98D.2050402@yahoo.com>
Date: Thu, 10 Jan 2002 18:12:29 +0000
From: Paul Hammant <Paul_Hammant@yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.7) Gecko/20011221
MIME-Version: 1.0
To: commons-dev@jakarta.apache.org
Subject: AltRMI - Proposal & request for help
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Folks,

Here is the proposal.  The audience for this tool is those that dislike 
RMI in that it needs special interfaces (must extend Remote, must 
specify RemoteException).  Those people that dislike RMI may have come 
across Glue ( http://www.themindelectric.com/products/glue/glue.html ) 
and its unhindered interface publication scheme.  People that dabble 
with .NET claim that it has a similar unencumbered method publication 
scheme.  

AltRMI is the same idea as Glue but not over SOAP.  Again, this is not 
for people that think there is nothing wrong with RMI as is.  The first 
alpha version has been used by Avalon-Cornerstone as a XML configurable 
'block' that other blocks can depend on.  That block has already been 
used by AvalonDB - a full RDBMS being built by a few of us in 
Avalon-Cornerstone's CVS.  Incidentally, AltRMI was code ripped out of 
AvalonDB and generalized.

There are a few differences with Glue :

1) Not over SOAP.  In this respect Glue is a very accomplished bit of work.

2) AltRMI can be instrcted as to what is pass by value and what is pass 
by reference (Glue can't).

3) Glue does not generate client side proxy code, AltRMI does.  The Glue 
solution is compatible with JDK1.1, 1.2, 1.3, 1.4 (according to Graham 
Glass) and therefore very flexible.  The secret solution Glue uses does 
not support introspection on the client side.  AltRMI does generate 
proxy classes for client side use.  As such it is introspectable.  This 
is of most use to scripting languages/envs (Rhino, Beanshell etc).  At 
the bottom of this email is a example generated proxy class.

We (I) need to build a community around AltRMI.  There are quite a few 
things to do.  Please take a few minutes to read the following proposal. 
 If you are interested in running AltRMI, its CVS dir contains a README 
file for instructions.  Alt positive ideas/patches very welcome.

Regards,

- Paul H

--------------------------------------------------------------------------
 JAKARTA COMMONS  -  ALTERNATIVE (TO) REMOTE METHOD INVOCATION - "AltRMI"
--------------------------------------------------------------------------

Abstract:

The AltRMI 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"
 
  * These two features are part of the reason why Graham Glass's 'Glue'
    product is so successful. His API goes several stages futher in that
    it pubishes APIs via SOAP so that any language in any location can
    use Glue published Java services.
 
2) Multiple transports

  - Plain Sockets / ObjectStream
  - via RMI
  - Piped with same VM / ObjectStream
  - Direct within same VM
  - SOAP (planned)
      - Might require additional undynamic "toWSDL()" step.
  - CORBA (planned)
      - Might require additional undynamic "toIDL()" step.
  - Plain sockets / custom messaging (planned)
  - JMS (planned)
 
3) Speed 

  - Using the AltRMI 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.

  - AltRMI can be build easily into any application or application 
framework. 
    Individual aspects can be reimplemented (or overridden) as the need
    arises.

5) Choice of location of generated Proxy class.

  - Classes providing client side implementation of the transported
    interface(s) can be either on the client side or the server side (and
    duly transported) at time of lookup.
   
6) Choice of castability of generated proxy class.

  - To suit remote facilities that are happy with refection and do
    not need to cast to an interface to use a bean (I am thinking of
    beanshell) the proxy class can be generated without specifying
    that it implements the interface(s).

7) Suspendable/Resumable service.

  - The Server supports suspend() and resume().  With the current impl this
    replies in a timely fashion to the client that the client should try
    later.  The client waits for the notified amount of time and seamlessly
    trys the requets again.  A server could cycle through suspended and back
    to resumed will not affect the client except for the a delay.

8) Recovering transport

  - AltRMI tries to recover its transports should they fail.  The recovery
    is pluggable in that the developer can choose when/how/if the connection
    handler tries to recover the connection.  Any inprogress, but
    disconnected method invocation will attempt to be recoved and just 
return
    as normal, albeit after a longer than normal delay.
 
9) Event API

  - For suspensions, abnormal ends of connection etc, there is a listener
    that can be set that will allow actions to be taken.  Abnormally
    terminated connections will by default try to be reconnected, the
    listener can decide if, how many, and how often the retries occur.

10) Unpublishable and republishable API
 
  - The server is able to unpublish a service.  In conjuction with
    suspend()/resume() a service can be republished, upgraded etc
    whilst in use, or just offlined.

11) Startable API for Server

  - The server implements and acts upon start() and stop() methods.

12) No just pass by value.

  - AltRMI started life as 'pass by value' only.  In now supports return
    types and parameters wrapped in another AltRMI Facade.
   
13) No duplicate instances.

  - If you call Person p = getPerson("Fred") twice you will get the same
    instance on the client side is it is the same instance on the server 
side.

Limitations:
 
1) Use in EJB

  - 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.  Beside RMI over 
IIOP
    is Sun specified.

Todo:

1) Other transports
 
  - SOAP, CORBA (with WDSL & IDL generation steps)
  - Other RMI (over IIOP, over HTTP)
  - Custom, socket protocol
  - JMS

2) BCEL for generated proxy class.

  - The current impl writes java source then compiles it.  We could do this
    inline with BCEL.  This as an heavier, but more design perfect
    alternative to the current server side impl.
   
  - BCEL is really difficult to use if you are not skilled in it!!

    
3) Client and Server code for secure conversations.

4) Authentication and Authorisation on lookup(..).

Initial committers:

Paul Hammant (hammant)

--------------------------------------------------------------------------
Example Generated Proxy class.  Not for editing, not normally
 for user viewing.  A step similar to rmic.
--------------------------------------------------------------------------

public final class AltrmiGeneratedHello_Main implements 
org.apache.commons.altrmi.test.TestInterface {
  private transient 
org.apache.commons.altrmi.client.impl.BaseServedObject mBaseServedObject;
  public AltrmiGeneratedHello_Main 
(org.apache.commons.altrmi.client.impl.BaseServedObject baseServedObject) {
      mBaseServedObject = baseServedObject;
  }
  public void hello (java.lang.String v0) {
    Object[] args = new Object[1];
    args[0] = v0;
    try {
      
mBaseServedObject.altrmiProcessVoidRequest("hello(java.lang.String)",args);
    } catch (Throwable t) {
      if (t instanceof RuntimeException) {
        throw (RuntimeException) t;
      } else if (t instanceof Error) {
        throw (Error) t;
      } else {
        throw new 
org.apache.commons.altrmi.common.AltrmiInvocationException("Should never 
get here" + t.getMessage());
      }
    }
  }
  public boolean hello3 (short v0) throws 
java.beans.PropertyVetoException, java.io.IOException{
    Object[] args = new Object[1];
    args[0] = new Short(v0);
    try {
      Object retVal = 
mBaseServedObject.altrmiProcessObjectRequest("hello3(short)",args);
      return ((Boolean) retVal).booleanValue();
    } catch (Throwable t) {
      if (t instanceof java.beans.PropertyVetoException) {
        throw (java.beans.PropertyVetoException) t;
      } else if (t instanceof java.io.IOException) {
        throw (java.io.IOException) t;
      } else      if (t instanceof RuntimeException) {
        throw (RuntimeException) t;
      } else if (t instanceof Error) {
        throw (Error) t;
      } else {
        throw new 
org.apache.commons.altrmi.common.AltrmiInvocationException("Should never 
get here" + t.getMessage());
      }
    }
  }
}


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>