Bill! Thanks for the response!
Remember that chaper I wrote for your
servlets book? I'm seriously thinking of that "object pipeline" as a contender for this. It's simple and can be easily distributed.
For those that didn't read that book, the idea is that you have a servlet-like class that you extend and implement "Object doObject( Object obj )". Then on the client side, you call a method in the HTTP class "Object send(
String url , Object parameter )". Presto! Distributed computing as simple as it gets!
I have a need to set up boxes with a collection of services. There might be 20 boxes, each with maybe 40 different services. I could just use the "Object Pipeline" (OP). It would work. Redundancy and failover can be handled with tools that are designed for the same thing for web sites.
But I want to consider EJB, RMI and JMS too. I want to try to weigh the pros and cons and maybe even say "By default, use this - and for these cases, use theses technologies." EJB has a lot of overhead, so I'm disinclined to use that. I feel OP would be easier to manage remotely than RMI, but that could just be because I'm unaware of some whizbang tools for RMI. I bet there is a mountain of tools for JMS to see how things are going.
Is JMS good for synchronized stuff? So if I call my remote method and I really can't do anything else until I get that message back .... It seems like rather than a simple method call, I might have to set up some kind of listener. Am I wrong about that?