Basic Design

[Ian B Anderson]

Hello,
I downloaded the assignment about a month ago and have been working on the design. My plan is at present:
DataBaseInterface - All public Data methods etc

RemoteDataBaseInterface � Locking method definitions

Data Class implements DataBaseInterface � Take out locking methods

LocalDataImp extends Data Class implements DataBaseInterface

RemoteDataImp extends Data Class implements RemoteDataBaseInterface

I think there needs to be a RemoteDataBaseInterface because this will throw a different type of exception but I�m not sure exactly. I'm also undecided as to where I should implement the locking. My take on it was that it shouldn't go in the Data class because there is no need for locking in local mode. Should it go in the RemoteDataImp class or would it be better to create a separate class implementing the Singleton pattern and all locking taking place there.
I am still a student so my knowledge and experience of Java and OO design is limited so all feedback is appreciated.

[Andras Nemeth]

Hello Ian,
I might missed something, but how do you ensure that local
and network mode are the same in the point of client?
(I mean it assume a Factory pattern, which wants an ancestor
or common interface.)
Ban

[Peter den Haan]

DataBaseInterface - All public Data methods etc
Good.
RemoteDataBaseInterface � Locking method definitions
Not so good. Ideally, the client application should be completely unaware whether the database he's talking to is local or remote. That means two things. First, the lock() and unlock() methods should always be there - in local mode, they can simply be no-ops. Second, the method calls may throw RemoteException - in local mode, of course, they simply never will.
This would suggest a design like:
DataBaseInterface - All public Data methods including locking and methods that may throw RemoteException
Data Class implements DataBaseInterface � Take out locking methods
LocalDataImp extends Data Class implements DataBaseInterface
This looks confusing. Data is the local implementation of DataBaseInterface, why have a separate LocalDataImp?
RemoteDataImp extends Data Class implements RemoteDataBaseInterface
This is misguided. Data implements local database access. Your proxy object implements the same interface but definitely should not extend Data. If you're using a local proxy class, then
RemoteData implements DataBaseInterface
would do a fine job. If you're using RMI and implement the class remotely, then you'd use
RemoteDataBaseInterface extends DatabaseInterface, Remote
RemoteData extends UnicastRemoteObject implements RemoteDataBaseInterface
I think there needs to be a RemoteDataBaseInterface because this will throw a different type of exception but I�m not sure exactly.
If you use RMI, remote calls can throw RemoteException. This means that the interface implemented by both local and remote database should declare its method to throw this exception. Remember that this does not imply that the method signatures in Data have to be modified; it is perfectly fine for an interface implementation to throw fewer (or narrower) exceptions than the interface declares.
I'm also undecided as to where I should implement the locking. My take on it was that it shouldn't go in the Data class because there is no need for locking in local mode.
Good thinking.
Should it go in the RemoteDataImp class or would it be better to create a separate class implementing the Singleton pattern and all locking taking place there.
It should not implement the Singleton pattern. Singleton is one of the most abused patterns around, think twice before using it. I'll leave the reason why as an exercise for the reader
- Peter

[Ian B Anderson]

Peter,
Thank you ever so much for your detailed reply. At present I�m thinking about what you said but just wanted to thank you first.
Cheers.

Andras,
It seems that my design was not as well thought out as I had hoped, I�m still learning!

[Ian B Anderson]

I have another question regarding where would be the best place to implement the locking. I feel that the locking part of the project should reside in a different class away from the RemoteDataImp class. This Locking class would then handle all the requests from the server. Am i thinking along the right lines or should I try and implement my locking and server as one.

[Lisa Yanchunis]

Why do you need to implement remote and local separately for just a difference in Exception throws? Why not a single method that throws one type if your local otherwise Remote?
Just curious.
Lisa

[Peter den Haan]

Originally posted by Ian B Anderson:
I have another question regarding where would be the best place to implement the locking.

It is often helpful to think in terms of responsibilities. If RemoteDataImp is not responsible for locking, what then are its responsibilities? If you decide that it must be responsible for locking, it can still delegate whole or part of the locking to a helper object.
Personally, my remote Data worked mostly as an adapter for Data. The very thing that needed to be adapted was the locking implementation, so there was little question that locking was its responsibility. Because I wanted to cleanly separate the low-level nitty-gritty locking implementation from the fairly high-level responsibility of the remote Data adapter, I introduced a separate (inner) class implementing the concept of a "record lock".
- Peter

[Peter den Haan]

Originally posted by Lisa Yanchunis:
Why do you need to implement remote and local separately for just a difference in Exception throws? Why not a single method that throws one type if your local otherwise Remote?

You need one interface that an application can talk to (call it Database). This interface must have two different implementations: local and remote. They must be different as they share no functionality whatsoever; the local implementation works with a data file, while the remote implementation sends requests over the network. An inheritance relationship is inappropriate.
If you use RMI, you have to introduce a second interface (call it RemoteDatabase) that extends Remote. The RMI framework needs it to do its work. It is wrong for Database to extend Remote, because that would mean that the local implementation, Data, would implement Remote even though it is not a remote object. This breaks the Remote contract.
Exceptions don't really enter the picture here. All I wanted to do is say that in a RMI implementation, although Database would throw RemoteException for all methods, this does not mean that its local implementation (Data) has to have a throws RemoteException in its methods too.
Does this answer your question?
- Peter

[Ian B Anderson]

Peter,
Thank you again for your replies it's alot clearer now.

[Ian B Anderson]

Peter,
You said it wouldn't make sense for the RemoteData class to extend the Data class. By this do you mean that the RemoteData class should contain an instance of the Data class and shouldn�t communicate directly with the db.db file. Then if I were to implement a Locking helper class this could talk to the db.db file through the Data object contained in the RemoteData class.
(Thank you for your help)

[Peter den Haan]

Yes, that's more or less it.
If you use RMI, RemoteData simply cannot extend Data anyway since it needs to extend UnicastRemoteObject. It may, but does not have to, a 1:1 relationship with Data - this depends on your design.
- Peter