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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
