Hey Paul
----- Original Message -----
From: "Paul Hammant" <[EMAIL PROTECTED]>
> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
