Waiting for my exam...

[alzamabar]

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.
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.
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

[Nicholas Cheung]

Hi Marco,

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.

The 3 modes can be viewed as:
server: start the remote server only
client: start the client, so that it connects to the started server. If the server is not available => error
standalone: start the client and server together in the same machine

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.

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.

[Satish Avadhanam]

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

Hi Marco, here is a link where the same doubts are dealt.
Database location
The mode flag
I think those two links should help you understand what the three modes stand for. If you still got doubts, you can ask them.
Hope this helps.

[alzamabar]

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.

I've read it, thanks. So, while both the server and client mode will need an IP and a port number, I'm corcerned about the standalone version. Shall I start the same server as the previous solution, just on the localhost? In this case, shouldn't I provide a port number anyway?

[Vishwa Kumba]

After going thru the old posts mentioned by Satish,
I think, in the standalone mode, there is no RMI.In my layman's words, it is just one big program(tightly coupled) that allows you do to the booking via a GUI using the local DB file.The complete program runs in one JVM and accesses the local DB, so we need to mention the path for the local DB file while starting the application.
In my B&S assignment, it says...

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.

Can somebody explain what is loopback networking?
[ March 04, 2004: Message edited by: Vish Kumar ]

[George Marinkovich]

Hi Vish,
I agree with what you stated about running in standalone mode.

Originally posted by Vish Kumar:
Can somebody explain what is loopback networking?

I believe loopback networking describes the following situation:
1) On a machine you open a command window and enter "java -jar runme.jar server", then you configure that application to use localhost.
2) On the same machine you open another command window and enter "java -jar runme.jar", then you configure that application to use localhost for the database server.
Consider the instructions again and what they say about the non-networked mode (which is also known as standalone mode):

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.

So they are contrasting the standalone mode from the loopback networking scenario we outlined above. In standalone mode the database and GUI must run in the same JVM, in the loopback networking scenario they run in two different JVMs. In standalone mode the application must perform no networking, in the loopback networking scenario networking is being performed, specifically loopback networking. In standalone mode the application must not involve the serialization of any objects when communicating between the GUI and the database elements, in the loopback networking scenario this is precisely what is going on.
So this is a long-winded way of saying that if your application running in standalone mode resembles the loopback networking scenario, then you're implementing standalone mode incorrectly.

[alzamabar]

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.

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.

[George Marinkovich]

Marco,

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.

I guess that would be OK, as the assignment instructions quoted seem to prohibit only using serialization.

[alzamabar]

Originally posted by George Marinkovich:
Marco,

I guess that would be OK, as the assignment instructions quoted seem to prohibit only using serialization.

George, you're helping a lot in this exam, thank you for that. I'm following another thread about db locations and modes and your posts are very handy.
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.
Marco

[George Marinkovich]

Hi Marco,
I think you're straying away from the intention of assignment instructions. Maybe an example will help here.
Imagine that you have a single computer. On this computer you start your application in server mode. On this same computer you start another instance of your application in network client mode. When the GUI displays you configure it so that it uses localhost as the database server. After doing all this your application is up and running. It's running as a client server and it's using networking (in this case loopback networking). In this scenario the database and GUI are running in two different JVMs, the applications are performing networking, and objects are being serialized when communicating between the JVM running the GUI and the JVM running the database. Your application must be able to work in this way, which we might call a networked mode. However, your application is also required to work in a non-networked mode.
To quote from my assignment instructions:

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.

So non-networked mode is going to be significantly different than networked mode. Specifically, in non-networked mode the database and GUI are going to run in the same JVM, no networking will be performed (not even the loopback networking described in the networked scenario given above), there must be no serialization of objects when communicating between the database and the GUI, the application running in this mode must not use the network server code at all, and in fact, networking must be entirely bypassed in the non-networked mode.
At the back-end of your application you have database access code that deals directly with a database file and provides the database operations specified by the Sun-supplied interface. At the front-end of your application you have a GUI that allows the user to view records, search for records, and book records. If you were to connect your back-end directly to your front-end, you would have a solution to the non-networked mode of your project. My suggestion is that you develop this capability first. It satisfies the requirement that your application be able to run in standalone mode and it's easier to implement because it doesn't involve any networking issues (it's also single-threaded so it doesn't even have to involve any locking issues).
For networked mode you are going to need a database server. Something that can accept requests from a remote client for database operations and return the results to the remote client. Your going to have to implement a network communications solution (RMI or sockets) in order to support these requests and return these results. The client GUI will be largely the same for non-networked and networked mode. In the non-networked case it will connect directly to the back-end. In the networked case it will connect to the database server.
Finally, with this background, let me address your question:

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.

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. 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. 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?
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.
There should be a clear distinction in your application between running in non-networked mode and non-networked mode. At some point after your application starts running it needs to connect to the database. If it's running in standalone or server mode it can connect to the database directly. If it's running in network client mode it doesn't connect to the database directly, but rather it connects to the database server. I hope this helps. If not, ask more questions.

[alzamabar]

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?

Thanks, Marco

[Satish Avadhanam]

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

All this will be very clear to you once you recieve the instructions...
Good Luck and see you around

[alzamabar]

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):

public interface SCJDContract {
    /** Adds thing to the db */
    public void addThing(Thing thing);
    /** Retrieves a thing given its key */
    public Thing getThing(String upc);
}

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.
May I simply created a new interface with the same methods as above, only extending Remote and adding RemoteException? Then the network server will implement the new interface, rather than this one.
Marco
[ March 07, 2004: Message edited by: Marco Tedone ]
[ March 07, 2004: Message edited by: Marco Tedone ]

[Satish Avadhanam]

Hi Marco,

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):

public interface SCJDContract {
    /** Adds thing to the db */
    public void addThing(Thing thing);
    /** Retrieves a thing given its key */
    public Thing getThing(String upc);
}

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 ]

Hope it helps.