Hi Paul Sorry this mail is really late - I've been offline. I just wanted to day that AltRMI sounds very interesting, I'm keen to help out - particularly adding JMS bindings, that sounds right up my street.
+1 from me. James ----- Original Message ----- From: "Paul Hammant" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 10, 2002 6:12 PM 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:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
