Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
However, I've got a question about the modes the application should run: as far as I knew, the application should run either in standalone mode or in network mode, therefore I thought there were two modes. But from some posts, now I learn there are three modes: server, standalone, and network client.
Shall we design an application that should act only as a server or only as a network client? My doubts in this case go to how the application will be eventually tested. As far as I can see it, when not in local mode, there should be a server started, running and listening, and a client interacting with it throughout a GUI.
SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Originally posted by Marco Tedone:
Hi, while I'm waiting for my exam link from Sun, I'm having a look around the posting on this forum. I have pretty much an idea of what the exam could look like, having read few books, one of then is related directly to SCJD.
Welcome to SCJD forum.
However, I've got a question about the modes the application should run: as far as I knew, the application should run either in standalone mode or in network mode, therefore I thought there were two modes. But from some posts, now I learn there are three modes: server, standalone, and network client.
That's right. There are 3 modes to operate.
Although I could imagine the different modes, I couldn't imagine how to implement the difference between server and network client. When not in standalone mode (where we know the application will manage a db on the local filesystem, without delegating requests to a remote server), I imagine there will be the need for a server running and listening for incoming connection and n clients that connect to it to manage the db. So what?
Shall we design an application that should act only as a server or only as a network client? My doubts in this case go to how the application will be eventually tested. As far as I can see it, when not in local mode, there should be a server started, running and listening, and a client interacting with it throughout a GUI.
Am I wrong?
Marco
Originally posted by Nicholas Cheung:
Hi Marco,
Basically, it is a client server system, and thus, you of course have to implement 2 subsystems. For testing, you can do the test after you finished the server part. Write a simple program that access the server in local mode first, and the modify the program to connect the server with RMI. Thus, without the GUI client, you can test it.
After you built your GUI, you can do the same route.
For the assignemt, I strongly recommend you to read Max's book: SCJD with J2SE 1.4. It is a cool book which covers all knowledge that you needed.
Hope this help.
Nick.
Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
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.
Originally posted by Vish Kumar:
Can somebody explain what is loopback networking?
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.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Originally posted by George Marinkovich:
In standalone mode the application must not involve the serialization of any objects when communicating between the GUI and the database elements.
Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
Originally posted by Marco Tedone:
Could I use a Data Object that implements Serializable to read/update/write data locally? At the end, implementing Serializable doesn't mean to actually use Serialization, as this is used by RMI or manually to write objects to a separate JVM.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Originally posted by George Marinkovich:
Marco,
I guess that would be OK, as the assignment instructions quoted seem to prohibit only using serialization.
Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
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.
...Keep in mind that networking must be entirely bypassed in the non-networked mode.
Would it be ok in your opinion to use the same server in server-network client and standalone modes? The only difference would be that in server-network client I would run the server as a server (infinite cycle listening for connections) while in standalone mode I would simply use the server interface to interact with the database. I wrote an HelloWorld application, with a server extending UnicastRemoteObject but run as a standalone application, and it works fine.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Originally posted by George Marinkovich:
Hi Marco,
I'm a little uncomfortable to hear that you want to use the same server in server-network client and standalone modes, since based on the preceding discussion I hope I have convinced you that the standalone mode doesn't use a server. The second sentence is more promising however. If you mean that your client GUI will use a common interface (which you are perhaps misleadingly calling a server) for both server-network client and standalone modes, then I would agree with you.
All my questions are related to a very specific issue: I would like to minimize the number of classes. Here follows what I've thought: "We receive a very basic desktop application which interacts with a database. Our assignments asks us to interact with the database in standalone mode (basically to provide a GUI to perform the same functionalities the assignment shipped from Sun performs at the beginning) and in a client/server mode. Well, if the functionalities are the same, why not to use the same class Sun shipped, only adapted for network operation?".
From what you've written, now it seems to me that I'll have to design from the scratch a server (I'm using RMI). This means that I'll have to design an interface that extends Remote and let each method throwing a RemoteException. Fine, that's fine, provided that Sun won't tell me: "Why did you rewrite a class to perform the functionalities I've already provided to you in the example?". On the other hand, it's also true that the server will need to manage concurrent accesses, which the Sun shipped version hasn't.
So, can I write a server completely from the scratch still passing my exam?
But then you begin to worry me again when you say that your server (which extends UnicastRemoteObject as a good server in an RMI implementation should) runs as a standalone application and works fine. What's causing me the problem is the use of the word standalone. If you meant that in networked mode you have two separate applications running (one in server mode and another in network client mode) then you're OK. If you mean to imply that in non-networked mode you have a server running than you I think you have a problem because there shouldn't be a server running in non-networked mode.
Unfortunately, this is what I meant. Basically I provided the class extending UnicastRemoteObject with a main method, and tried to run it directly.
If you tell me that in non-networked mode you are using code that extends UnicastRemoteObject, then I become more concerned. UnicastRemoteObject is what gives you all the RMI magic (serialization, marshalling, unmarshalling, de-serialization) that you need for handling remote objects. But why are you handling remote objects when you're running in non-networked mode?
It was just because I wanted to save on the number of classes to write.
Let's return to the single computer used in the initial example, but this time we'll look at the non-networked mode. On this single computer you start your application in standalone mode. Your front-end GUI directly makes calls on your back-end GUI. Everything's running in a single JVM, there is no need for any remote objects, there's no need for any network communications, there's no need for a database server, there's no need for an RMI registry, there's no need to reference any code that extends UnicastRemoteObject.
Can I build my GUI so that it simply uses the classes shipped with the original assignment?
Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
Originally posted by Marco Tedone:
All my questions are related to a very specific issue: I would like to minimize the number of classes. Here follows what I've thought: "We receive a very basic desktop application which interacts with a database.
Nope. We just recieve a db fileand probably a interface. That's it. We have to develop a working application.
Our assignments asks us to interact with the database in standalone mode (basically to provide a GUI to perform the same functionalities the assignment shipped from Sun performs at the beginning) and in a client/server mode.
It seems that you are assuming Sun provides a sample applicatino to build on and we have to develop that to work in standalone mode and client/server mode. If that's what you're thinking, then to clarify, as I said above, Sun only sends us a db file and probably a interface.
Well, if the functionalities are the same, why not to use the same class Sun shipped, only adapted for network operation?".
Same reason. Sun do not provide any classes. Only an interface may be provided and we have to implement it for all the requirements.
From what you've written, now it seems to me that I'll have to design from the scratch a server (I'm using RMI).
Yep, that's true. We have to develop a server from scratch as you can see the same terms "scratch" in the instruction too for designing a server.
"must reimplement the database code from scratch without altering the data file format"
This means that I'll have to design an interface that extends Remote and let each method throwing a RemoteException.
Again, yes. Maybe you need to design two interfaces. One for connection factory too. It depends on your design and requirements.
Fine, that's fine, provided that Sun won't tell me: "Why did you rewrite a class to perform the functionalities I've already provided to you in the example?".
As you can see from above reasons, Sun won't tell like that![]()
On the other hand, it's also true that the server will need to manage concurrent accesses, which the Sun shipped version hasn't.
So, can I write a server completely from the scratch still passing my exam?
I think everyone MUST write a server from scratch to PASS the exam.
Thanks, Marco
Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
Originally posted by Marco Tedone:
Well, this makes a lot of difference. Now I've got questions about the interface.
Let's say that I've got the following interface from Sun (here limited for obvious reasons):
While this is perfectly ok for a standalone approach (my standalone application will easily implement this interface), a remote approach will need to implement the Remote interface and add the throws RemoteException to each method.
Exactly.
May I simply created a new interface with the same methods as above, only extending Remote and adding RemoteInterface? Then the network server will implement the new interface, rather than this one.
Yep, that's it.
Marco
[ March 07, 2004: Message edited by: Marco Tedone ]