my principal design decisions were as follows:
1. I used RMI as most seemed to do - not very comfortable with sockets thing -but must say felt RMI easy enough to implement.
2. Implemented two Remote interfaces Objects one with single method which returns a RemoteData object and is registered on the rmiregistry by the server.
The other is the remote implementation of the adapted Data class to implement the Remote interface.
3. Created a simple server UI to allow closing server in an orderally way also had 2 tabbed panes first to output details of process on server, second to output errors relevent to server.
4. Implemented a LockManager class to manage locks so did not change lock signature in RemoteData implementation class.
5. Implemented unreferenced interface in RemoteDataImpl to clean up "dead" clients.
6. Used factory
pattern at client side to return inplementation of DataClient or RemoteDataClient interfaces
7. Implemented all business logic in a Facade class on client side also had a table model class in here, felt the whole thing here was a bit fuzzy- worked ok but not clearly defined class roles - a degree of coupling between classes.
8. My client UI was a single frame with 3 areas of activity -input for search, a booking panel for accepting input and displaying data being booked and principal panel JTable. Liked it aesthetically but feel it may have been a little complicated to be totally user friendly.
9. Handled exceptions by modifying DataException to carry details of process nested across rmi boundry seemed to work perhaps a bit longwinded on output to client but very specific on what was the problem.
10. Didn't really go much into talking about patterns but put all my controllers forClientUI into inner classes with GUI code and implemented the command interface to call them.
11. used online help which i felt looked well and was not undully diffucult to achieve.
12. worked hard on the javadoc until i got sick of it and decided to send the whole thing away.
13 packaged in a executable jar which i feel is a good idea because less instructions have to be given about classpaths etc as i only had Windows2000 to work on i tried to ensure the instructions i had to give were simple so less likly to bencompatible with examiners platform.
14. Modest testing but as i implemented the booking method on the client side i could turn off unlock and test to see what would happen in different situations seemed to be satisfactory but i did not know the standard required and so was concerned. Also i mentioned about the possible undesireabiity of placing the locking process on the client side and depending on "good" clients which might not be desirable in a real world situation.
These are the main features as i recall, should you feel i could be of more assistance to you,ask.
tom