The instructions state: "The program must be able to work in a non-networked mode. In this mode, the database and GUI must run in the same VM and must perform no networking, must not use loopback networking, and must not involve the serialization of any objects when communicating between the GUI and database elements. The operating mode is selected using the single command line argument that is permitted. Architecturally, this mode must use the database and GUI from the networked form, but must not use the network server code at all. " The words "networked form" are throwing me for a bit of a loop. Currently in my application, if the user selects "Remote" from a pop up window, the RMI server is started and the database is accessed via the remote methods. If the user chooses "Direct", no server connection is created and the database is accessed via the methods provided in the interface. It seems to me that I have this implemented correctly. However, when Oracle states that "the program must be able to work in non-networked mode...and must use the database from the networked form" it seems contradictory, or at least not clear to me.
Since I am testing this on my own computer, the Remote connection uses a loopback call and is told where to look for the database (on my computer), whereas the Direct connection simply accesses the database file wherever I tell it it is. Have I missed something?
in networked mode your client and database will run in different VMs. in standalone mode both will run in the same VM. And of course you develop just 1 Data class which is used in both modes. Your implementation sounds fine, no worries
Thanks very much, guys. That is what logically seemed to be the way it should be done but I assume nothing.
I do have another question, though. When setting the configurations for the direct connection, my GUI pop up asks only for the location of the database file on the local VM (ie my computer). This makes perfect sense. My RMI does the same thing, except that a port is also specified in a GUI text field. If I am not mistaken, though, I also need a third text field that will accept the IP address of the network connection (so the RMI pop up asks for the IP address, the physical file location on the other VM, and the port). Is that correct? It seems as though it should be. This is my first time programing network connections, so my apologies if these are basic questions. I currently have it set up like this:
This is the local host connection, but I no doubt need to be able to change this in my GUI before I connect. I only bring this up because the SCJD book implementation differs from my own so I want to make sure I have not missed anything that is typically standard. As I said, I assume nothing in fields where I have little experience.
The configuration settings depend (of course) on the mode your application is running in:
standalone: database file location
network server: database file location + port number
network client: server address (ip or name) + port number
Joined: Aug 14, 2010
Okay I get it. I think my confusion stemmed from my having the a call to the Client class constructor be the catalyst for starting the Server, instead of starting the Server, and then starting the client in two different GUI popups.
Currently, I have the client and server connected in my code, so that when the "Remote" connection choice is chosen, a call to the Server class is made (before anything else) from within my Client class constructor. Then the Client class creates the remote object with the IP address. Apparently I must separate these two. Thus the reason I though I would need to add a third text field for the IP address (which I do). I just need to separate the launching of the Server and Client into two separate actions.
You are indeed not supposed to start the network server from the network client. You just need 2 seperate java invocations to do that (java -jar runme.jar (network client) and java -jar runme.jar server (network server). For the standalone application you just need 1 invocation: java -jar runme.jar alone