These command lines may only take configuration parameters selected from this list: DNS name of the server Port number used by the server Data file name(s) java.rmi.server.codebase security manager policy file
Q: What does data file name(s) mean? Should the server be capable of handling multiple db.db's? 2. And under "Creating the User Interface" is the line:
The main data output section of the user interface should be created using a JTable.
Q: Does "main data output section" refer to the search results? 3. Can the user book a flight without performaing any search? For instance, if the user knows the flight number, the user directly enter the flight number and the number of seats required. Should the UI be capable of handling this too or is it OK to enforce booking on a flight selected from a search result only? Thanks.
I cannot see any reason why you would want to specify more than one database name at any one time. Hower you may optionally choose to provide the examiner with the ability to specify different database names each time they run your program. So the first time they may specify file "db.db" in the current directory, next time they run your program they may choose a differently named file in a different direct. Note: I did say this is optional.
So you want to be able to do a "long sell" While this is normal practice at most airlines, I think catering for it is beyond our requirements. Certainly I enforced the rule that the user must select a flight from the search results JTable, and book from there.
I cannot see any reason why you would want to specify more than one database name at any one time
I do not see any reason too, but was confused by the wordings in the instructions. I have allowed the user to specify the data file name at startup of both the server and the client (GUI). Got one more doubt Q:
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.
Does this mean the methods in the new class have to stick with the exceptions thrown by the methods in Data class or can they throw additional exceptions? Thanks.
Hi Sathya, The assignment is interesting isn't it? It is possible to meet these requirements and not throw any additional exceptions. You might want to look at the facade pattern. I am going slow with the hints here - it is difficult to find hints to give you without giving the game away. Have a think about it, then come back with more questions if you need to. Regards, Andrew
You bet, I'am thoroughly enjoying myself! Okie..more on the Facade pattern...My current design is as follows: Current Scenario: 1. I have an interface DataOperations that has all the public methods of the Data class. All methods in this class throw the exceptions thrown by their counterparts in Data + another exception CommunicationException 2. There is a LocalDataOperations class that implements this interface and uses Data class directly to access the DB. 3. There is a RemoteDataOperations class that implements this interface and communicates with the server using sockets (yes, I'am using sockets and not RMI). Heres where CommunicationException is used to denote errors in SocketCommunication. 4. Now the GUI controller for the most part does not know whether the DB mode is local/remote. The only place where it knows this mode is in it's constructor where the code is something like:
Now my dilemma is whether the CommunicationException can be thrown by the criteriaFind() method in DataOperations Interface. Now if I use a facade pattern, I'd have one more layer of abstraction between the controller and the DataOperations implementations. This abstraction has it's set of methods that all throw just one "CustomException". But I still have to deal with the "CommunicationException" in the RemoteDataOperations class. How do I avoid it? What do you suggest? Thanks in advance for all your suggestions.
Hi Sathya, One possibility is that you catch the communications exception at a low level then throw a new RuntimeException (or a subclass of RuntimeException) for the communication exception. That way your facade only has to declare the same exceptions as per the data class. You can, of course, catch a subclassed RuntimeException at a higher level and deal with it as a critical problem (which it is). I was just trying to remember how I handled it, and as it turns out, I threw the communication exception. Didn't loose any marks for it either Regards, Andrew