Our first version was very rough (it looked even worse than the first revision commited to the google repo). So I pushed it forward to get a code base which was maintainable and where features could be added easily.
One of the first new features was the runtime configuration (just call the addUri oder removeUri-Method to add or remove a server on the fly). We created a simple MBean to control it via JMX. It's really cool when you are going to deploy a new version of the backend server: Remove one, deploy new version, add it again, continue with the next.
The frontend app doesn't even notice that a server is down.
This is a client-side library, so there are some things you should spend at least a short thought about:
- if connection to one server is lost, this neither means the server is down, nor that your method wasn't executed properly. If you run the method again on a second instance, it could lead to duplicated data. If you don't, maybe no data will be saved/processed.
- load-balancing can only be rudimentary. Even the best algorithm can only guess which server will have the most free resources available, especially if there's more than a single client.
I have planned new features for it, but there's a lot of work todo before (one of them is documentation, as mentioned in the issue tracker).
Features I'm currently planning:
- A better load balancing algorithm.
A weighted one should be rather simple, but provide a much better balancing. - Support of Burlap/Hessian, JMS and RMI (as mentioned on the frontpage)
- Annotation based config
You can already mark a method as "test" method. It will be used instead of a generic alive-test approach.
criticism is welcome!
Keine Kommentare:
Kommentar veröffentlichen