commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: AltRMI - Proposal & request for help
Date Fri, 11 Jan 2002 08:11:47 GMT
Donnie,

Very Interesting suggestion.  I''ve clicked on the URLs and read quite a 
bit.  I had reservations about it until I realised it generates standard 
Java bytecode.  I'd like to find out more about the 'interceptor' idea 
you have but can't find info on the site.  Could you point me to a 
snipped of example code (I am an example orientated person - EOP ;).

- Paul

>This is likely ***way*** out of scope, but for those who have followed
>"aspect-oriented programming" (AOP) at all, check out http://aspectj.org,
>especially: http://aspectj.org/doc/dist/progguide/ch01.html.
>
>How does this possibly apply to AltRMI, you ask? Using AOP techniques, you
>can define interceptors (aspects) for arbitrary method invocations on
>arbitrary classes/interfaces. In those, you can catch exceptions, add code,
>examine parameters, etc. The point is you can overcome the interface
>extension and RemoteException problems of RMI without needing an alternate
>transport.
>
>Of course, this is a general solution to what an application-specific
>dynamic proxy can also accomplish. I'm using that type of technique (a
>dynamic proxy) in a current application to insulate the client from
>RemoteExceptions, log all call entries/exits, etc.
>
>I'm not trying to "dis" AltRMI at all, just pointing out the availability of
>other solutions if those are your primary objections to RMI.
>
>FWIW...
>
>Donnie
>
>
>>-----Original Message-----
>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>Sent: Thursday, January 10, 2002 1:12 PM
>>To: commons-dev@jakarta.apache.org
>>Subject: AltRMI - Proposal & request for help
>>
>>
>>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>
>>
>>
>
>
>--
>To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>
>




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


Mime
View raw message