+1  A: 

Separate your RMI logic from your Ball logic.

You should be able to run your ball simulation without needing any RMI modules. Just to run it locally, to test it. Then you should find a way to wrap that process in RMI so that you can still run it locally to test it without any sort of RMI interface. This block of code is the engine, and it is very important to be able to test it in as atomic a form as possible. Having extra parts integrated with it just increases the complexity of what will undoubtedly be some of the most complex code.

Don't let any extra interfaces into your engine. It should be very specific and few the packages required to use your engine. Any new functionality your software needs, implement it appropriately in the engine to support generic design. Wrap that to provide specific functionality outside the core of the engine. This protects the engine design against changes to the environment. It also allows for more complete testing of the engine.

We make exceptions sometimes in cases where something will only ever be used in one way. But in this case, testing without RMI would seem to be critical to getting your engine working correctly. If your engine runs faster than the network can keep up due to large numbers of clients connecting, do you want the whole game to slow down, or do you want the clients to lag behind? I say, you want to be able to make that choice.

Erick Robertson
On a separate issue entirely, I'm not convinced that RMI is the right solution for your project. This will become obvious, though, when these two items are distinct code packages.
Erick Robertson
Thanks!,i think u sketch a generic picture which is still quite blur(RMI logic?) as far as its realization is concerned, i talked about the specific problem, which i came across and was looking for its solution as far as the decoupling is concerned i already thought about that; the ball is remote object so that multiple clients can call its function like move() and others, if u could realize your ideas in code, which i shown in my different questions that would be great.
Static Void Main
Don't have `ball` extend `RemoteUnicastObject`. Don't throw `RemoteException` and don't worry about notifying clients. Just worry about creating the balls and making them move. You can do any number of things to test it, but make sure the code exists outside the engine for moving your balls. Once this is complete, then construct your client-server communications around it.
Erick Robertson
ok i did that already, i created a serialized class for that =), what changes do u expect from it and why are u saying to do that. will it optimized that design ?while i did that for another reason...and i m desperately looking for optimization and scalability in this design
Static Void Main
what if i have 100 balls and other objects like balls how you will manage those that is my concern now...because you have to register all of them as remote object and look for them in RMI registry and i m not satisfied with that...
Static Void Main
This is why I'm not convinced that RMI is the right solution for your communication needs. Get the RMI out of there completely. Don't even try to get the communication working until you have the simulation working.
Erick Robertson
simulation is working. and infact it is all working but now the issue is of optimization and cases which i discussed, the goal is not huge games but only small multiplayer games and simulations.and need template/generic library for that.
Static Void Main
my goal are small scale real time games/simuation, still RMI is not capable of managing that?
Static Void Main
Capable or best? I'm sure RMI is capable, but that's not what your measure should be. You should be looking for the best. That means, works the best, easiest to create, easiest to maintain, easiest to understand, easiest to add onto existing code. Can you implement RMI without changing the objects in your engine? I consider that a serious drawback.
Erick Robertson
so, we can't make RMI best as much as we can or is it totally hopeless case:-)
Static Void Main
If I was making the decision for my app, I wouldn't use RMI. I would create a network socket layer and serialize and deserialize the information to pass it across the socket. Probably I wouldn't even do whole objects, since you don't need to update the object, just send some sort of ID and a new location. This would give me the control to include exactly the information I wanted, and nothing more, in the network packets.
Erick Robertson