You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/12/23 17:39:53 UTC
New tool - armi - 'alternate to RMI'
Folks,
I'm more usually found in the Avalon project at Jakarta. I have
something that I have been writing that might be more at home here than
there. It is a replacement for RMI that delivers on one design goal :
Any interface can be published over the wire. It does not have to
extend Remote or have RemoteException thrown left, right and centre.
I appreciate that as many people love RemoteException as there are those
that hate it. We do of course indicate this serious error state but
with an extension of RuntimeException. The user of armi will have to be
careful in their strategic handler code to have a catch clause for the
exception, but it at least allows the developer how to handle it rather
than forcing it to be handled everywhere (like RemoteException).
The interface is published on the server :
void publish(Object impl, String asName, Class[] interfacesToPublish)
This forces of course a interface/impl seperation, but we're all doing
that in this age right? On the client side, the developer has to do a
lookup:
Object lookup(ArmiHostContext hostContext, String named, Class[]
exposingInterfaces)
Such that the following could be done:
ArmiHostContext arhc = new PlainSocketHostContext("myserver",1234);
Log = (Log) ArmiFactory.getDefaultArmiFactrory().lookup(arhc,
"log-service", Log.class);
The server side is handled automatically by the fact that the publish
method is called. The client side needs some generated classes (that
implement the interfaces) that will be build in a style similar to RMIC.
It is about 70% done. And there will be some limitations (it leans
towards simple, standard, serializable primitives and object types for
params and return codes).
Are you folks interested? Is Commons the best place? How is a decision
made here?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New tool - armi - 'alternate to RMI'
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 28 Dec 2001, Lavandowska wrote:
> Date: Fri, 28 Dec 2001 08:05:50 -0800 (PST)
> From: Lavandowska <fl...@yahoo.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> flanandowska@yahoo.com
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: New tool - armi - 'alternate to RMI'
>
>
> --- Paul Hammant <Pa...@yahoo.com> wrote:
> > I'm still unclear whether I am getting a mandate in Commons or
> > whether I
> > should go back to Avalon with this. It is decidedly client/server -
> > our
> > original raison d'être.
>
> Please keep it at Commons, this may be just the component we need to
> get around a nasty bodge we've made.
>
> That, and, I don't know that you need any mandate to put something into
> Commons-sandbox. Once its proven itself ARMI should easily move into
> Commons proper.
>
According to the Commons charter, it doesn't take a vote to put proposed
code in the sandbox -- any committer on any Jakarta project can do this.
It's a good way to look at some potential code and play with it a little.
Once the package has been proven to be a good idea, it can be voted in to
the standard commons repository (by the committers on COMMONS-DEV).
In practice, it seems to work pretty well ... people get a chance to
evaluate new ideas (and get interested in contributing) in the sandbox, so
a proposed new package can start building a mini-community around it
instead of being a one-man show. Historically, migration to the commons
repository has been approved every time it's been proposed so far, so it's
not like this is really a roadblock.
> Lance
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New tool - armi - 'alternate to RMI'
Posted by Lavandowska <fl...@yahoo.com>.
--- Paul Hammant <Pa...@yahoo.com> wrote:
> I'm still unclear whether I am getting a mandate in Commons or
> whether I
> should go back to Avalon with this. It is decidedly client/server -
> our
> original raison d'�tre.
Please keep it at Commons, this may be just the component we need to
get around a nasty bodge we've made.
That, and, I don't know that you need any mandate to put something into
Commons-sandbox. Once its proven itself ARMI should easily move into
Commons proper.
Lance
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New tool - armi - 'alternate to RMI'
Posted by Paul Hammant <Pa...@yahoo.com>.
James,
>I agree that RemoteException is a PITA; its unfortunate that a checked
>exception was used IMHO.
>
>It might be worth taking a closer look at the JAX-RPC stuff; maybe your ARMI
>idea might make more sense if there is a plugable protocol such that RMI,
>ARMI, JMS or SOAP could be used as the transport mechanism.
>
There are two transports coded at the moment:
1) ObjectStream over plain sockets (same VM, different VMs or
difffernt IP visible machines)
2) ObjectStream over Pipe (same VM)
To do are:
3) RMI transport
4) direct (unmarshaled) transport
4) SOAP transport
5) JMS transport (I add this now you mention it).
I'll do 3 & 4 today, but probably stop there for now.
I'm still unclear whether I am getting a mandate in Commons or whether I
should go back to Avalon with this. It is decidedly client/server - our
original raison d'être.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New tool - armi - 'alternate to RMI'
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
> Juozas,
>
> > I think it is better to use RMIC, generate wrappers for remote methods
> > and handle all Remote Exceptions in single method
> > like "void handle(RemoteExeption re)" or dispatch to error handlers.
> > It will be more portable.
> > Implement alternative RPC is not good idea.
>
> Is this the general concenus?
>
> I am familar with your solution for handling RemoteException (it is a
> well estabilshed pattern). Perhaps I am the only coder that thinks
> RemoteException makes RMI a PITA.
I agree that RemoteException is a PITA; its unfortunate that a checked
exception was used IMHO.
It might be worth taking a closer look at the JAX-RPC stuff; maybe your ARMI
idea might make more sense if there is a plugable protocol such that RMI,
ARMI, JMS or SOAP could be used as the transport mechanism.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New tool - armi - 'alternate to RMI'
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
> I think it is better to use RMIC, generate wrappers for remote methods
> and handle all Remote Exceptions in single method
> like "void handle(RemoteExeption re)" or dispatch to error handlers.
> It will be more portable.
> Implement alternative RPC is not good idea.
Is this the general concenus?
I am familar with your solution for handling RemoteException (it is a
well estabilshed pattern). Perhaps I am the only coder that thinks
RemoteException makes RMI a PITA.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New tool - armi - 'alternate to RMI'
Posted by Juozas Baliuka <ba...@mwm.lt>.
I think it is better to use RMIC, generate wrappers for remote methods and
handle all Remote Exceptions in single method
like "void handle(RemoteExeption re)" or dispatch to error handlers. It
will be more portable.
Implement alternative RPC is not good idea.
At 16:39 2001-12-23 +0000, you wrote:
>Folks,
>
>I'm more usually found in the Avalon project at Jakarta. I have something
>that I have been writing that might be more at home here than there. It
>is a replacement for RMI that delivers on one design goal :
>
> Any interface can be published over the wire. It does not have to
> extend Remote or have RemoteException thrown left, right and centre.
>
>I appreciate that as many people love RemoteException as there are those
>that hate it. We do of course indicate this serious error state but with
>an extension of RuntimeException. The user of armi will have to be
>careful in their strategic handler code to have a catch clause for the
>exception, but it at least allows the developer how to handle it rather
>than forcing it to be handled everywhere (like RemoteException).
>
>The interface is published on the server :
>
> void publish(Object impl, String asName, Class[] interfacesToPublish)
>
>This forces of course a interface/impl seperation, but we're all doing
>that in this age right? On the client side, the developer has to do a lookup:
>
> Object lookup(ArmiHostContext hostContext, String named, Class[]
> exposingInterfaces)
>
>Such that the following could be done:
>
> ArmiHostContext arhc = new PlainSocketHostContext("myserver",1234);
> Log = (Log) ArmiFactory.getDefaultArmiFactrory().lookup(arhc,
> "log-service", Log.class);
>
>The server side is handled automatically by the fact that the publish
>method is called. The client side needs some generated classes (that
>implement the interfaces) that will be build in a style similar to RMIC.
>
>It is about 70% done. And there will be some limitations (it leans
>towards simple, standard, serializable primitives and object types for
>params and return codes).
>
>Are you folks interested? Is Commons the best place? How is a decision
>made here?
>
>Regards,
>
>- Paul H
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>