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:[EMAIL PROTECTED]] >>Sent: Thursday, January 10, 2002 1:12 PM >>To: [EMAIL PROTECTED] >>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]> >> >> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
