| |
10:00:02 PM |
 |
Dabblings with AltRMI and asyncronous messaging.
Quick detour: AltRMI is a replacement for RMI. Unlike RMI, it adds no constraints to objects that are remote so you're not forever messing around with things like RemoteExceptions and objects can be transparently distributed. Apart from allowing for simpler code, it has incredible performance (muuuch faster than Sun RMI, IIOP, SOAP, t3, ORMI, etc) and has many pluggable ways of providing transports. For any kind of object that requires distributed objects, this is now my middleware of choice.
Imagine this... public interface DealSystem { void makeDeal(Deal d, Trader t);
Trader[] listTraders();
} public class CustomDealSystem implements DealSystem {
public void makeDeal(Deal d, Trader t) {
/* ... */
}
public Trader[] listTraders() {
/* ... */
}
}/* client */
DealSystem dealSystem = (DealSystem)factory.lookup("DealSystem");
dealSystem.makeDeal(someDeal, someTrader);
A clean and simple interface/implementation seperation you'd expect to see in most applications. The implementation is being looked up from the AltRMI factory and could be an in VM object or located somewhere else. Either way, calling the methods repeatedly could take a long time due to possible network latency or because the actual implementation method spends a while doing stuff.
However, seing as AltRMI already has the mechanism in place to serialize method calls over a stream, what's to stop them from being invoked asyncronously? So, with no modifications to the interface, implementation or client, a configuration setting could specify that the makeDeal() method should be called asyncronously. Behind the scenes AltRMI can route the calls to a backing message server. Obviously async methods are constrained to not throw exceptions or return anything, so listTraders() has to be sync.
This is a much cleaner interface to async messaging than JMS provides as you just call methods using their preferred signature instead of playing with things like message objects.
As a pair-programming and unit-testing excercise, myself, Charles Lowell (work colleague) and Paul Hammant decided to implement this. Started but not complete - we'll let you know how we got on. Yes of course, we test-first and pair-program. :)
There's some overlap here with the AOP stuff Rickard is playing with seeing as asyncronous calls are being implemented as aspects - I wonder where to next...... ?
| 