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 2002/01/10 19:12:29 UTC
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AltRMI - Proposal & request for help
Posted by Paul Hammant <Pa...@yahoo.com>.
James, Folks,
>> Very minor comment, how about renaming altrmi-tests.xml to be just
>> tests.xml. It saves some typing when running stuff. Maybe it could
>> set a new
>> trend; build.xml is for building stuff and tests.xml is for various test
>> programs.
>>
> Rename : will do. It is separate primarily because there is an ant
> task created which cannot be used in the build file that creates it :-(
Done. The targets have different names too now. See the readme or do a
-projecthelp on ant.
>>
>> Another minor comment, some of the core APIs of AltRMI use Altrmi in the
>> interface names; how about removing them, since afterall the
>> classes/interfaces are in altrmi packages.
>>
> True. There is always a compromise between namespace on classnames.
> My feeling is that "Connection" "Component" and "Document" are very
> over used as class names and should definately be prefixed for futher
> definitions. (Intellij's IDEA can be too suggestive for those). In
> short yes, Perhaps some of the Altrmi prefixes for class names should go.
About 10 things renamed now....
>>
>> e.g.
>>
>> AltrmiInvocationHandler -> InvocationHandler.
>>
> Vote against as that's already used in the JDK.
>
>> AltrmiRequest -> Request
>>
> No, because it's too simple a word. It was the firsat thing to be
> renamed from Request to AltrmiRequest.
But not those two... :-)
If enough people think it is best to purge Altrmi as prefic from all
classes then I'll do it. At the moment its 1 for, 1 against....
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AltRMI - Proposal & request for help
Posted by Paul Hammant <Pa...@yahoo.com>.
James,
>>The first thing to do is get it from CVS, compile and run it as per the
>>README.
>>
>
>Done. Nice, I'm impressed. Am digesting in more detail now.
>
>Very minor comment, how about renaming altrmi-tests.xml to be just
>tests.xml. It saves some typing when running stuff. Maybe it could set a new
>trend; build.xml is for building stuff and tests.xml is for various test
>programs.
>
Rename : will do. It is separate primarily because there is an ant task
created which cannot be used in the build file that creates it :-(
>As a complete aside, I'm interested in getting together at some point a kind
>of 'distributed JUnit' thing so that (say) client and server processes can
>be started (or even much more complex networks of clients and servers on a
>variety of machines & platforms) and the collection of processes are
>started, coordinated and ran as a single JUnit test case. Then for example,
>all the pairs of clients and servers could all be run as part of a single
>JUnit test suite. I'm thinking Ant is the way to start processes (just like
>you're doing with altrmi-tests.xml) then some kind of JUnit-ish framework on
>top doing the distribution & coordination. Anyways, back to the matter at
>hand...
>
>
>>After that look at the classes in the test package to see how,
>>from the user's point of view, it is used. I think you're brave taking
>>on a JMS transport, but then perhaps if you know it well it might be
>>quite easy.
>>
>
>I know JMS well, I've used it quite a bit. Several years ago I even
>developed a JMS provider so it shouldn't be too hard. More later...
>
>
>>AltRMI's magic (not) is that it transports method calls in
>>serializable classes. There are quite a few communicated through a
>>simple, single API...
>>
>> AltrmiReply handleInvocation(AltrmiRequest request);
>>
>>Consider...
>> class MethodRequest extends AltrmiRequest {
>> String methodSignature;
>> Object[] args;
>> Long referenceID;
>> }
>> class MethodReply extends AltrmiReply{
>> Object replyObj;
>> }
>>.. (and a few others). The handleInvocation() method, in the impls so
>>far, can tranport itself over RMI, over plain sockets (using
>>objectstreams and a custom solution). There are also very useful impls
>>that transport/marshall within one JVM ('Piped' and 'Direct').
>>
>
>Looks cool.
>
>Another minor comment, some of the core APIs of AltRMI use Altrmi in the
>interface names; how about removing them, since afterall the
>classes/interfaces are in altrmi packages.
>
True. There is always a compromise between namespace on classnames. My
feeling is that "Connection" "Component" and "Document" are very over
used as class names and should definately be prefixed for futher
definitions. (Intellij's IDEA can be too suggestive for those). In
short yes, Perhaps some of the Altrmi prefixes for class names should go.
>
>e.g.
>
>AltrmiInvocationHandler -> InvocationHandler.
>
Vote against as that's already used in the JDK.
>AltrmiRequest -> Request
>
No, because it's too simple a word. It was the firsat thing to be
renamed from Request to AltrmiRequest.
There are 20 others that are good candidates though you ust chose a
couple that I'd resist on. :-)
>It just makes code that little bit easier to understand, and there's always
>fully qualified class names if ever there's a naming conflict issue.
>
If the imports are specific (as per Apache rules) then the possibility
is greatly diminished, but still possible. I'm motivated (for those
two) by untellisense in IDEs
>Just out of interest, have you taking a look at JAX-RPC? It has a similar
>model which might give you some good ideas. From last time I looked the API
>of JAX-RPC looked like the transport was agnostic.
>
Will do.
>>For JMS, if it can transport classes like those above via an interface
>>like that above, then it is fine. I'll have to read more.
>> Specifically, I'm not sure how the asynchronous side of things will work.
>>
>
>Just to save a bit of reading... JMS can send and receive a variety of
>different kinds of Message objects. The core Message interface provides
>various standard headers as well as allowing user defined headers
>(properties) on messages. Then there are various derivations of the core
>Message interface to provide various kinds of message body such as
>TextMessage where the body is a String, ObjectMessage where the body is a
>Serializable object, MapMessage where the body is somewhat like a Map
>(though unfortunately doesn't use a Java 2 Map interface) and some binary
>messages like BytesMessage and StreamMessage.
>
>Both synchronous and asynchronous communication models can be implemented
>quite straightforwardly, receiving supports push and pull models. Also JMS
>supports queue semantics, only one consumer receives the message (similar to
>connection-less point to point) and publish/subscribe semantics (all
>consumers interested receive a copy of the message). Finally JMS provides a
>variety of Quality of Services such as persistent messages, XA compliance
>etc.
>
>So I would think it should be fairly straightforward to implement AltRMI in
>sync or async modes with JMS. More later when I've looked more deeply.
>
Yup, but making the provider open to have multiple use scenarios will
the the difficult thing.
>Incidentally do you plan on providing asynchronous method invocations? I'm
>thinking in particular bean listener interfaces are ripe for asynchronous
>communication. e.g.
>
Yes as well. But given that a method call (what the user of AltRMI
thinks is happening) is synchronous, there with have to be wait/notify
logic to make it look synchronous.
>public interface FooListener extends EventListener {
> public void onSomething( FooEvent event );
>}
>
>Since they are mostly void, the bean calling the listeners could well be
>invoking AltRMI calls on remote Listeners.
>
Mostly void? There is always a reply. Hence the wait. The reply could
come back later, picked of from a pending reply repository the
invocation returns up the stack as normal.
Tis getting exciting.....
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AltRMI - Proposal & request for help
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: 21 January 2002 13:52
> To: Jakarta Commons Developers List
> Subject: Re: AltRMI - Proposal & request for help
>
[snip]
> >
> > This sounds similar to Cactus:
> >
> > http://jakarta.apache.org/cactus/how_it_works.html
>
> Thanks for the link.
>
> I talked with Vincent about this recently; Cactus is quite HTTP /
servlet
> /
> web application focussed. I'm interested in something that would work
with
> arbitrary groups of processes in a protocol independant manner, e.g.
for
> JMS
> consumers and producers or AltRMI clients and servers or arbitrary
SOAP
> processes using different frameworks etc. So its similar to Cactus but
> more
> focussed on arbitrary groups of distributed processes using any
protocols.
>
FYI, Cactus was HTTP / Servlet / webapp focused until now ... Don't
forget that its goal is simply to provide server-side unit testing
capabilities (whatever server-side means :-) ). We focused on webapp
first, and are moving towards EJB (already in progress). The next step
we are preparing is to offer an SPI for redirector writers + custom
injectors. We're going to add JMS support soon (see
http://www.mail-archive.com/cactus-user@jakarta.apache.org/msg00999.html
for the details) but initially for MDBs. However, any protocol can be
added once we offer this public SPI (which is already there but not
public).
I agree it may not be exactly what you're interested in but thought you
might want to know about it.
Cheers,
-Vincent
> James
>
>
>
> _________________________________________________________
>
> Do You Yahoo!?
>
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>
>
> --
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AltRMI - Proposal & request for help
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Janek
----- Original Message -----
From: "Janek Bogucki" <ya...@studylink.com>
> Hi James,
>
> > From: "James Strachan" <ja...@yahoo.co.uk>
> > Reply-To: "Jakarta Commons Developers List"
<co...@jakarta.apache.org>
> > Date: Mon, 21 Jan 2002 10:02:52 -0000
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Subject: Re: AltRMI - Proposal & request for help
> >
> > As a complete aside, I'm interested in getting together at some point a
kind
> > of 'distributed JUnit' thing so that (say) client and server processes
can
> > be started (or even much more complex networks of clients and servers on
a
> > variety of machines & platforms) and the collection of processes are
> > started, coordinated and ran as a single JUnit test case. Then for
example,
> > all the pairs of clients and servers could all be run as part of a
single
> > JUnit test suite. I'm thinking Ant is the way to start processes (just
like
> > you're doing with altrmi-tests.xml) then some kind of JUnit-ish
framework on
> > top doing the distribution & coordination. Anyways, back to the matter
at
> > hand...
>
> This sounds similar to Cactus:
>
> http://jakarta.apache.org/cactus/how_it_works.html
Thanks for the link.
I talked with Vincent about this recently; Cactus is quite HTTP / servlet /
web application focussed. I'm interested in something that would work with
arbitrary groups of processes in a protocol independant manner, e.g. for JMS
consumers and producers or AltRMI clients and servers or arbitrary SOAP
processes using different frameworks etc. So its similar to Cactus but more
focussed on arbitrary groups of distributed processes using any protocols.
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: AltRMI - Proposal & request for help
Posted by Janek Bogucki <ya...@studylink.com>.
Hi James,
> From: "James Strachan" <ja...@yahoo.co.uk>
> Reply-To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Date: Mon, 21 Jan 2002 10:02:52 -0000
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Subject: Re: AltRMI - Proposal & request for help
>
> As a complete aside, I'm interested in getting together at some point a kind
> of 'distributed JUnit' thing so that (say) client and server processes can
> be started (or even much more complex networks of clients and servers on a
> variety of machines & platforms) and the collection of processes are
> started, coordinated and ran as a single JUnit test case. Then for example,
> all the pairs of clients and servers could all be run as part of a single
> JUnit test suite. I'm thinking Ant is the way to start processes (just like
> you're doing with altrmi-tests.xml) then some kind of JUnit-ish framework on
> top doing the distribution & coordination. Anyways, back to the matter at
> hand...
This sounds similar to Cactus:
http://jakarta.apache.org/cactus/how_it_works.html
-Janek
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AltRMI - Proposal & request for help
Posted by James Strachan <ja...@yahoo.co.uk>.
Hey Paul
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
> James,
>
> >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.
> >
> Welcome aboard then :-)
Thanks
> The first thing to do is get it from CVS, compile and run it as per the
> README.
Done. Nice, I'm impressed. Am digesting in more detail now.
Very minor comment, how about renaming altrmi-tests.xml to be just
tests.xml. It saves some typing when running stuff. Maybe it could set a new
trend; build.xml is for building stuff and tests.xml is for various test
programs.
As a complete aside, I'm interested in getting together at some point a kind
of 'distributed JUnit' thing so that (say) client and server processes can
be started (or even much more complex networks of clients and servers on a
variety of machines & platforms) and the collection of processes are
started, coordinated and ran as a single JUnit test case. Then for example,
all the pairs of clients and servers could all be run as part of a single
JUnit test suite. I'm thinking Ant is the way to start processes (just like
you're doing with altrmi-tests.xml) then some kind of JUnit-ish framework on
top doing the distribution & coordination. Anyways, back to the matter at
hand...
> After that look at the classes in the test package to see how,
> from the user's point of view, it is used. I think you're brave taking
> on a JMS transport, but then perhaps if you know it well it might be
> quite easy.
I know JMS well, I've used it quite a bit. Several years ago I even
developed a JMS provider so it shouldn't be too hard. More later...
> AltRMI's magic (not) is that it transports method calls in
> serializable classes. There are quite a few communicated through a
> simple, single API...
>
> AltrmiReply handleInvocation(AltrmiRequest request);
>
> Consider...
> class MethodRequest extends AltrmiRequest {
> String methodSignature;
> Object[] args;
> Long referenceID;
> }
> class MethodReply extends AltrmiReply{
> Object replyObj;
> }
> .. (and a few others). The handleInvocation() method, in the impls so
> far, can tranport itself over RMI, over plain sockets (using
> objectstreams and a custom solution). There are also very useful impls
> that transport/marshall within one JVM ('Piped' and 'Direct').
Looks cool.
Another minor comment, some of the core APIs of AltRMI use Altrmi in the
interface names; how about removing them, since afterall the
classes/interfaces are in altrmi packages.
e.g.
AltrmiInvocationHandler -> InvocationHandler.
AltrmiRequest -> Request
It just makes code that little bit easier to understand, and there's always
fully qualified class names if ever there's a naming conflict issue.
Just out of interest, have you taking a look at JAX-RPC? It has a similar
model which might give you some good ideas. From last time I looked the API
of JAX-RPC looked like the transport was agnostic.
> For JMS, if it can transport classes like those above via an interface
> like that above, then it is fine. I'll have to read more.
> Specifically, I'm not sure how the asynchronous side of things will work.
Just to save a bit of reading... JMS can send and receive a variety of
different kinds of Message objects. The core Message interface provides
various standard headers as well as allowing user defined headers
(properties) on messages. Then there are various derivations of the core
Message interface to provide various kinds of message body such as
TextMessage where the body is a String, ObjectMessage where the body is a
Serializable object, MapMessage where the body is somewhat like a Map
(though unfortunately doesn't use a Java 2 Map interface) and some binary
messages like BytesMessage and StreamMessage.
Both synchronous and asynchronous communication models can be implemented
quite straightforwardly, receiving supports push and pull models. Also JMS
supports queue semantics, only one consumer receives the message (similar to
connection-less point to point) and publish/subscribe semantics (all
consumers interested receive a copy of the message). Finally JMS provides a
variety of Quality of Services such as persistent messages, XA compliance
etc.
So I would think it should be fairly straightforward to implement AltRMI in
sync or async modes with JMS. More later when I've looked more deeply.
Incidentally do you plan on providing asynchronous method invocations? I'm
thinking in particular bean listener interfaces are ripe for asynchronous
communication. e.g.
public interface FooListener extends EventListener {
public void onSomething( FooEvent event );
}
Since they are mostly void, the bean calling the listeners could well be
invoking AltRMI calls on remote Listeners.
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: AltRMI - Proposal & request for help
Posted by Paul Hammant <Pa...@yahoo.com>.
James,
>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.
>
Welcome aboard then :-)
The first thing to do is get it from CVS, compile and run it as per the
README. After that look at the classes in the test package to see how,
from the user's point of view, it is used. I think you're brave taking
on a JMS transport, but then perhaps if you know it well it might be
quite easy. AltRMI's magic (not) is that it transports method calls in
serializable classes. There are quite a few communicated through a
simple, single API...
AltrmiReply handleInvocation(AltrmiRequest request);
Consider...
class MethodRequest extends AltrmiRequest {
String methodSignature;
Object[] args;
Long referenceID;
}
class MethodReply extends AltrmiReply{
Object replyObj;
}
.. (and a few others). The handleInvocation() method, in the impls so
far, can tranport itself over RMI, over plain sockets (using
objectstreams and a custom solution). There are also very useful impls
that transport/marshall within one JVM ('Piped' and 'Direct').
For JMS, if it can transport classes like those above via an interface
like that above, then it is fine. I'll have to read more.
Specifically, I'm not sure how the asynchronous side of things will work.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AltRMI - Proposal & request for help
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "robert burrell donkin" <ro...@mac.com>
> On Thursday, January 17, 2002, at 06:46 PM, James Strachan wrote:
>
> > 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.
>
> hi james
>
> (just to help you get up to speed) paul's big stumbling block about
> getting AltRMI accepted into the commons proper seems to be that he's
> short of initial committers. fancy volunteering?
I sure do.
Incidentally I also share Paul's admiration for Graham's Glue and Voyager
projects and think an open source Java approach would be very cool.
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: AltRMI - Proposal & request for help
Posted by robert burrell donkin <ro...@mac.com>.
On Thursday, January 17, 2002, at 06:46 PM, James Strachan wrote:
> 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.
hi james
(just to help you get up to speed) paul's big stumbling block about
getting AltRMI accepted into the commons proper seems to be that he's
short of initial committers. fancy volunteering?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AltRMI - Proposal & request for help
Posted by James Strachan <ja...@yahoo.co.uk>.
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" <Pa...@yahoo.com>
To: <co...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
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: AltRMI - Proposal & request for help
Posted by Paul Hammant <Pa...@yahoo.com>.
Robert,
> I wonder if there are any people in BCEL-land who'd be willing to
> volunteer to join you as initial committers?
BCEL is very new to Apache and most of the many other BCEL using
projects are still using the previous (non-apache) version. I think it
will take some months before a community builds up around BCEL at
Apache. The problem is that it worked perfectly before it came to
Apache and one of the golden rules for people starting projects anywhere
is that your user comunity has to have an itch for certain new features
to have the incentive to become developers. It should be easy to code
the BCEL stuff - I keep looking at it but am scared off by the assember
type syntax that Java bytecode has forced on BCEL.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AltRMI - Proposal & request for help
Posted by robert burrell donkin <ro...@mac.com>.
On Thursday, January 10, 2002, at 06:12 PM, Paul Hammant wrote:
> Folks,
>
> Here is the proposal.
that proposal's a really great piece of work, paul!
> 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.
<snip>
> 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!!
<snip>
> Initial committers:
>
> Paul Hammant (hammant)
i wonder if there are any people in BCEL-land who'd be willing to
volunteer to join you as initial committers?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Latka AbstractReporter.java documentation
Posted by Jeff Turner <je...@socialchange.net.au>.
Applied, thanks.
--Jeff
On Fri, Jan 11, 2002 at 04:05:14PM +1100, dIon Gillard wrote:
> Index: ./latka/src/java/org/apache/commons/latka/AbstractReporter.java
..
> --
> dIon Gillard, Multitask Consulting
> http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] Latka AbstractReporter.java documentation
Posted by dIon Gillard <di...@multitask.com.au>.
Index: ./latka/src/java/org/apache/commons/latka/AbstractReporter.java
===================================================================
RCS file:
/home/cvspublic/jakarta-commons/latka/src/java/org/apache/commons/latka/AbstractReporter.java,v
retrieving revision 1.8
diff -r1.8 AbstractReporter.java
75c75,78
< * Needs docs.
---
> * The base class for several 'reporters'.
> *
> * A reporter is a class that store or record information about
events that
> * occur during Latka processing
81a85,87
> /**
> * maps the request to it's success or failure as a Boolean
> */
82a89,91
> /**
> * maps the session to it's success or failure as a Boolean
> */
84a94,97
> /**
> * Holds whether or not the entire suite has succeeded
> * This is set to false when <strong>any</strong> request fails
> */
86a100,103
> /**
> * holds the failed responses received by this object
> * @see #requestFailed(RequestEvent)
> */
88a106,108
> /**
> * The log4J category used for processing log requests
> */
91a112,117
> /**
> * Invoked if the request succeeds
> * Records the success
> *
> * @param event a successful request event
> */
95a122,128
> /**
> * Invoked if the request failed.
> * Records the failure and adds the request's response to the list of
> * failed responses
> *
> * @param event a "failed" request event.
> */
100a134,139
> /**
> * A skipped request.
> * Records the skip as a failure
> *
> * @param event a "skipped" request.
> */
104c143,149
<
---
>
> /**
> * Invoked if a request error occurs.
> * Records the error as a failure
> *
> * @param event a request "error" event.
> */
108a154,161
> /**
> * Record a success or failure
> * On a failed request, the current suite, request and session are
> * marked as failed
> *
> * param event a request event.
> * param bool the success or failure of the request
> */
118a172,178
> /**
> * Check to see if a particular Request succeeded or failed.
> *
> * @param request the request to check for success or
> * failure
> * @return true if request succeeded
> */
129a190,198
> /**
> * Check to see if a particular Session succeeded or failed.
> * Once a request inside a session fails, the session itself
> * is marked as a failure.
> *
> * @param session the session to check for success or
> * failure
> * @return true if all requests in the session succeeded
> */
139a209,213
> /**
> * Returns true if all Requests in the suite succeed.
> *
> * @return true if all Requests have succeeded
> */
143a218,220
> /**
> * @return a list of all responses of failed requests
> */
The command completed successfully.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AltRMI - Proposal & request for help
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
you can download Aspectj, there are some examples and good documentation,
GUI. I sow an example with
RemoteException handling in documentation.
Aspectj compiler is like code generator, it preprocesses JAVA source files,
it is safe, because usual JAVA compiler is used to compile generated code.
At 08:11 AM 1/11/2002 +0000, you wrote:
>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:
>>><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>
>>
>>
>
>
>
>
>--
>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>
RE: AltRMI - Proposal & request for help
Posted by Donnie Hale <do...@haleonline.net>.
First, I want to make sure no one confuses me for an AOP or AspectJ expert.
:)
Interestingly, just after I posted this message, someone else posted an
AspectJ-related message in struts-dev. He shows how to apply exception
handling to the entire Struts framework in about 6 lines of code; and he
also shows his custom Ant task (not the code, just how to use it in
build.xml). If you're interested, check out the archives for struts-dev on
1/10/2002 (U.S. Eastern); "AspectJ" is in the subject line.
I used the term "interceptor" because I knew everyone would understand that
concept. But in some ways AOP seems to be significantly about intercepting
and enhancing or modifying behavior in existing classes/libraries. Check out
http://aspectj.org/doc/dist/progguide/ch01s04.html, specifically the
"Providing Consistent Behavior" section. A "pointcut" named
"publicMethodCall" is defined. It refers to any invocation of any public
method on the named set of packages. The "advice" named after() is defined
for any invocation of methods in the publicMethodCall pointcut when those
methods throw an exception of type Error. The extra behavior is in that
after() advice's code. If the methods exit normally, nothing happens. The
behavior here just writes something out; but it could throw a different kind
of exception such as a RuntimeException.
Also check out: http://aspectj.org/doc/dist/progguide/ch01s03.html to see
some simple examples of interception which add method entry/exit logging,
pre- and post-conditions, etc.
All of those types of aspects are essentially interceptors. At this point,
of course, you've about exhausted my knowledge. ;)
Donnie
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Friday, January 11, 2002 3:12 AM
> To: Jakarta Commons Developers List
> Subject: Re: AltRMI - Proposal & request for help
>
>
> 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:
> >><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>
>
>
>
--
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>
Re: AltRMI - Proposal & request for help
Posted by Paul Hammant <Pa...@yahoo.com>.
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:
>><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>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: AltRMI - Proposal & request for help
Posted by Donnie Hale <do...@haleonline.net>.
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:
> <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>