I did modify the signature of "lock()" and "unlock()" to enable identification of the locking client.
Used RMI, with very server simple basic design...did create a SecurityManager with a security file provided. I trusted the clients to be good citizens and perform locking, because it is to their advantage to do so. Kept the GUI very minimalist, only implementing booking and flight lookup operations. The GUI was engineered to not know if it was local or remote thru use of what I called the FlightBroker object, which held the info on whether it was local or remote, and made appropriate calls on Data methods.
I had a question. When your client application is invoked using java command, do u provide information using Command Line Runtime parameters regarding whether the database is local or not?
Is it of the format
"java <client App> <flag indicating remote/local db> <DNS Name> <port No> <directory where the db.db file resides>"
Congradulations! That is great job! Very good design.
I would like to know how you did the documentation. 1) How many files and what covered each ? 2) What editor you used for those docs except for javadoc documents (as html) ?
How many copies of db.db ?
Thanks in advance.
Now, as to the documentation, let me just say I followed directions as precisely as I could. I generated the javadoc on all my code and inspected to make sure that it made sense. For the User Guide, I used Acrobat PDF format, which was accepted with nary a murmer. I had minimal online documentation, and did put in tooltips for the various buttons. One copy of db.db...
Thanks for your reply. Can you please answer one more question.
The exam requires a Data Client class implementing the
same public methods as the db.Data class. Do they mean
including a common interface/super class for the remote
and the local db.Data classes?
Originally posted by Douglas Kent:
Naravan...your question about the superclass: I "hid" the various public methods of the Data class in a my client "FlightBroker" class. The GUI client is only interested in logical operations, not with the specifics of how to do it, and whether the data is local or remote. So my FlightBroker implemented the public Data methods as directed by Sun.
I think I am on the right road then. The Data class should not extend Remote, but I need to create a server class that contains all of the public methods. This server class will register the interface in the JVM, and then server as a proxy to the real Data object. Is this correct? Or am I missing it badly?
Then the on the client side, I can use a Factory pattern (your FlightBroker) to instantiate either the real Data class (which talks directly with the file) or instantiate the RMI client stub. Is this basically how you did it?
If this was the case did this not break the requirement to provide all the public methods of the Data class to the client?
Hopefully this is not a stupid question .....
Wanted to see if you could answer one more question for me. I am debating weather or not to use a JComboBox for the origin and destination search fields on the GUI. I saw in your message you said you used a minimalist approach on the GUI. Does this mean you just used text boxes?