Christopher, > You're not the only coder who thinks that way.
:-) > When I first started working with RMI, RE's really disappointed me, > because my goal was to develop code that could work equally well > whether it was going to run remotely or locally, allowing me to > dynamically switch from distributed to single-machine behaviour. The > way RMI is set up, however, I either have to write 2 versions, or > accept crufted code if I am running on a single machine. > > I really like the armi proposal, but have one major problem with it, > which is that EJB is developed around RMI and RE's, and I don't see > anything in the spec that would make switching over possible, although > I am open to the idea that I am missing something here. It's no longer a proposal. It is very nearly complete. I've coded a Piped transport (as well as socket) so we (Avalon team) could use it for in-VM transport for very complex classloading cases. WRT to EJB, I think the latest specs allow the dropping of the RemoteException on the method signatures (or was that not extending the Remote interface?). To be honest this is more useful to us that J2EE coders (who put up with loads of cr*p). If you were coding a general server (FTP, HTTP, Gopher. POP3 or SMTP etc) and wanted a remote admin capability then you would automatically use RMI these days. I am influenced greatly by SOAP. Or more particularly Glue which will publish any interface remotely without RE. If the esteemed Graham Glass can do it, then we can to. The transport is open, so bizarrely we could implement an RMI, SOAP or CORBA transport for ARMI too. The Server impl is open so that it can be replaced with a non factory version for bigger projects (like Avalon). There are some limitations, in that it wants to be limited to Serializable objects and primitives for return values and params, but hey the coder could be quite happy with that. I also does not mean that that could not be fixed later. > Just my 1/4 byte And quite welcome. Regards, - Paul H -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
