This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Network Approaches Your choice of RMI or serialized objects will not affect your grade, but no other approach is acceptable. In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely.
I am not clear about this paragraph. Hence the questions. 1. "In either case" means while in network mode using either RMI or serialized objects. Right or Wrong? 2. What does the location of the database mean here? Is it an absolute path + file name to data file or just path? What are the possible values? 3. In network mode location of the database need to be provided by user. In non-network mode user need not provide database location. Right or wrong? 4. If Aplication is started in stand alone mode, can another gui started with "mode left out" (Just gui) connect to the database in stand alone mode? [ December 16, 2005: Message edited by: jiju ka ]
1. "In either case" means while in network mode using either RMI or serialized objects. Right or Wrong?
2. What does the location of the database mean here? Is it an absolute path + file name to data file or just path? What are the possible values?
I assume "location of the database" may be a path + filename relative to the working directory, or an absolute path + filename. You have to be able to configure the location in your preferences. A sensible default may the name of the dbFile supplied with the submission, located in the working directory.
3. In network mode location of the database need to be provided by user. In non-network mode user need not provide database location. Right or wrong?
Wrong. See above
4. If Aplication is started in stand alone mode, can another gui started with "mode left out" (Just gui) connect to the database in stand alone mode?
No. Starting standalone mode means starting a local (non-networked) database and the client gui, bypassing any networking code. Starting the network client (no argument to main) means starting the client gui and using your networking code to connect to a remote (i.e. not the one just started) JVM hosting the database server.
Joined: Oct 12, 2004
Thanks for the replies. I am still not convinced what are the values for location of the database. I need to be more descriptive.
the program must allow the user to specify the location of the database
Purpose: I couldn't figure the purpose of user identifying the database.
Glossary: Database is using db file. For a database there will be one db file. It is easy to specify the location of the dbfile. But to identify a database, the database should have a name. It makes sense if sun means "network part of server" by database. Does it?
One assumption I have is the RMI naming registry have name of the RMI server. This name can be custom set and may vary from configuration to configuration. Can this name be used to identify the database?
Onething confusing to me is the purpose of identifying the database. The name of the database could have been configured and not user supplied in an ideal case.
I am going to move well outside of the boundaries of what is required for the assignment in order to (hopefully) give you some idea of why we want to be able to specify the location of the various files.
There are potentially at least four different files available in our deliverables:
The data file itself.
This would presumably be stored on the server which gives best uptime and disk access. For example, you might put it on a RAID system.
The runme.jar file.
To run the server you must always be able to access this, however it is not being updated on a regular basis. So you might still have it on the high availability server, however you might not need to put it on the RAID drives - leave the RAID space for the mission critical data.
The configuration file(s).
From a server perspective: This is the file that is going to specify how the server is to run. It may not change very often, but it is essential. So you would probably have it on your high availabilty server. It does not need to go on the RAID drives, however it might go onto a special drive where everything on the drive gets backed up on a regular basis (so a different drive to where the application is).
The user documentation.
This is low priority - as long as the application keeps running, you can still make bookings. And it never needs to be backed up. So you might put all user documentation on a secondary server so that you it does not interfere with core business.I have worked in several businesses that have operating environments like this - in general this has been done on Unix boxes, but the discussion still holds with any operating system.
So if we assume that we have:
C drive for configuration
D: drive for documentation
P: drive for application programs
R: drive for the RAID system
Then I might start my application via a command line such as:Then when the application starts up I will use the configuration window to tell the application that the data is on R: drive (and possibly that the documentation is on drive D: ). This information will then be stored in the configuration file so that it does not have to be re-entered next time.
Although not as common, the same logic can apply even to a single PC. My laptop has a C: and a D: drive. All programs get installed on C: drive. All data, documentation, etc., gets saved to D: drive. So if I need to reinstall my operating system, I can reformat C: drive and install there without loosing my data on D: drive.
So - a bit of an elaborate scenario just to show why we might want to be able to specify where the location of the database is. But did it help?
Going on the same perspective Andrew has directed...
If I understood right client 1 , 2 and 3 have the freedom to modify the configuration. Unless the parameter being configured have a constraint like "updatable only once and only at the startup of the server", the whole application will get into an inconsistent state.
Means once a configuration is applied, it should not be allowed to change as long as users are active.
To the user the system is a black box. User shouldn't bother about the internals of the system unless the security of the user is tampered. So the user shouldn't have the freedom to set a configuration.