RMI design

[Lucy Sommerman]

Just wanted to quickly check that my RMI design is okay...have finished but maybe what i have done is so shoddy they will fail me...SO..doing B&S..

I have a Data class that implements the DBAcess interface (no rmi in either)
I have a RemoteData class that implements RemoteDB.
RemoteDB is identical to DBAccess interface except that it extends java.rmi.Remote and its methods throw java.rmi.RemoteException.
RemoteData implements RemoteDB and extends java.rmi.UnicastRemoteObject.

The RemoteData class has an instance of Data as a variable - so when its methods are called it calls the equivalent method in the Data class - i.e. used the same code, just with RMI wrapper.

I *think* this is all basically OK. However, in my GUI, I have an instance of RemoteData r and Data d. At startup, the mode (i.e. standalone, client, server) is passed to the GUI, and if we are in client mode then we call methods on RemoteData r, else we call on Data d. Does that sound basically okay, or is really bad design? I have heard others speak of DataProxy, but have not quite comprehended what is meant by that...

Thanks

Lucy

[Andrew Monkhouse]

Hi Lucy,

The Adapter (or Wrapper) design pattern is often used to describe converting one interface to another interface (note: lower case "i" - I am not necessarily talking about a Java "Interface"). So in that context your RemoteDB and RemoteData are adapting the provided DBAccess interface to suit the RMI requirements.

The Proxy design pattern is used to describe having one instance of an object stand in for another object (this is the same in the real world - for example you can give another person "proxy" voting rights). On the client side you use the RMI to get an instance of something that implements your RemoteDB Interface (the stub). In this case the instance of the object that implements the RemoteDB Interface is standing in for the RemoteData class - it is a Proxy.

The only difference between what you have and what those who use a DataProxy have is that you are only proxying the RemoteData class. Your client side code is still aware that there is a difference between the RMI RemoteData class and the local Data class. It is possible to hide those differences such that the client code is only aware that there is a Data class - it doesnt know whether it is local or remote (or what protocol might be used if it is remote). That would then be a Data proxy.

Do you need to go that extra distance? Probably not.

All of which is a long way of not answering your question

Does that sound basically okay, or is really bad design?

Sounds good to me.

Regards, Andrew

[Lucy Sommerman]

Ah okay, I got it..thanks...well i think that if I have time maybe I could gain myself a few extra points by doing the proxy thing, as that is really *better* design, no? but what I have is okay...so now all i have to do is a bit more documentation and then I am there...phew long haul, but will see it thru having come this far...

Thanks v. much for your help.

Lucy

[Andrew Monkhouse]

Originally posted by Lucy Sommerman:
maybe I could gain myself a few extra points by doing the proxy thing,

Remember, though, that you have the line in the instructions telling you that you will not gain extra points for going beyond the specification.

Originally posted by Lucy Sommerman:
as that is really *better* design, no?

True, and you could also look at what the Factory pattern will do for you (even though it is a bit of overkill when we only have a local mode or one type of networked mode).

Regards, Andrew