2 tier architecture

[Mark Thomson]

Having just read and re-read the Bodgitt & Scarper assignment I have a couple of questions regardinb the architecture of the system.

Now I understand there are three options in terms of how the application can be run:

1. server mode - I assume this just runs the server with no GUI???
(passing commandline option mode=server)

2. alone mode - I assume this runs the server and client in a non-networked environment??
(passing commandline option mode=alone)

3. no mode - I assume this means we are running in network mode and thus we are connecting to an already running server???
(not passing any command line option )

Are my assumptions along the right track??

In regards to pint 1. The assignment also mentions:

'The program must allow the user to specify the location of the database file, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely'

Does this mean that the 'server' needs to have a GUI component?? otherwise following the statement that were not allowed to pass any extra command line parameters in, I'm not sure how the server would know where the database lives.

Also the part:

'and it must also accept an indication that a local database is to be used'

Does this mean that the user needs to be able to specify the location of a remote database?? if so I'm not sure how that would be achieved

Any advice will be appreciated

[Jon Entwistle]

Hi Mark,


My project is URLyBIRD but your instructions look the same for these points:

1. server mode - I assume this just runs the server with no GUI???
(passing commandline option mode=server)

I know that may people have implemented a server GUI, but I really cant see the use of it and so I didn't.

2. alone mode - I assume this runs the server and client in a non-networked environment??
(passing commandline option mode=alone)

If there is no network there can be no server. alone means that your client must access the database in the same VM without using the network.

3. no mode - I assume this means we are running in network mode and thus we are connecting to an already running server???
(not passing any command line option )

Yes - this is client only mode which requires a running server on the loopback or a remote host.

Does this mean that the 'server' needs to have a GUI component??

You need a GUI to collect configuration information for each mode.

Does this mean that the user needs to be able to specify the location of a

No - as far as the client is concerned (the only mode using a remote database), the location of a remote database is an IP address/host name and port.

Regards,

Jon

[Robert Konigsberg]

Your three assumptions on command-line match my assumptions. Therefore we are both right or both wrong.

'The program must allow the user to specify the location of the database file, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely'

Does this mean that the 'server' needs to have a GUI component?? otherwise following the statement that were not allowed to pass any extra command line parameters in, I'm not sure how the server would know where the database lives.

My server does not have a GUI component. This, I think, is a) a reiteration of the "alone" mode and b) an indication that the database location is configurable. This configuration must be made by a GUI. Basically I think this means that you should be allowed to run the GUI, whether it connects to something or not, and make your configuration changes from there.

'and it must also accept an indication that a local database is to be used'

Does this mean that the user needs to be able to specify the location of a remote database?? if so I'm not sure how that would be achieved

Yeah, basically my user documentation says something like, "If you want to configure the database on the server, run the GUI on the server's machine and configure it."

Hope this helps,
RK

[Jon Entwistle]

Hi Mark,

I have just re-read my post and I see that my comment about the server GUI even confuses me :roll: !

Just to clarify, I see the collection of configuration data as a seperate step prior to running the application so no matter what mode I use, a dialog pops up asking for the relevant config data for that mode. If a suncertify.properties file exists, the fields are filled in with the data from the file.

In the case of the server, once the config data has been collected and the user starts the application, the GUI disapears, and a confirmation that the server is running is printed on the command line. To stop the server, the user must press ctrl-c.

All of this is my interpretation of the requirements of course, although I would be wary of not giving the user the opportunity to change the relevant configuration data for server mode before starting the server.

Hope this helps,

Regards,

Jon

[derek leong]

Hi,

Robert wrote:

My server does not have a GUI component

In some assignment requirement, server GUI is a must. My instructions.html reads:

All configuration must be done via a GUI, and must be persistent between runs of the program.

Jon wrote:

In the case of the server, once the config data has been collected and the user starts the application, the GUI disapears, and a confirmation that the server is running is printed on the command line. To stop the server, the user must press ctrl-c.

How about having a GUI server dialog with start and stop buttons? When the start button is clicked, the server is started, and the start button is disabled, leaving only the stop button that can be clicked. When the stop button is clicked, the server is stopped and the server dialog disappears. It's more friendly than pressing ctrl-c.

Hope it helps.
Derek

[Mark Thomson]

Just to clarify, I see the collection of configuration data as a seperate step prior to running the application so no matter what mode I use, a dialog pops up asking for the relevant config data for that mode. If a suncertify.properties file exists, the fields are filled in with the data from the file.

I like that idea and i reckon I am going to go with this GUI no matter what mode the system is being run on.

I am also now making the assumption that if a remote database is to be used then the GUI will request an IP address and port no. Have you guys also made that assumption??

[Jon Entwistle]

Hi all,

Dereck:

How about having a GUI server dialog with start and stop buttons? When the start button is clicked, the server is started, and the start button is disabled, leaving only the stop button that can be clicked. When the stop button is clicked, the server is stopped and the server dialog disappears. It's more friendly than pressing ctrl-c.

The question I asked myself when thinking about this is 'How many servers do I know which use a GUI when running?' The answer is none. Web servers, mailservers, ftp servers etc. etc. etc.

These processes are either started manualy from the command line in which case they stopped by ctrl-c. More likely they are started in the background, and need to be stopped by finding the process number and sending it a kill signal. This is not very user friendly, but servers are supposed to be run in the background without need for interaction. Having a big start and stop button sitting in the middle of my screen would, for me, be a huge nuisance with no added benefit.

Now I stress this is my personal view on how a server should behave once the config inormation has been collected although I really think that either approach is equaly acceptable for the assignment.



Mark:

I am also now making the assumption that if a remote database is to be used then the GUI will request an IP address and port no. Have you guys also made that assumption??

That is what I asked the user for in client (i.e. no argument) mode, although I mentioned IP or hostname in the GUI.

Regards,

Jon

[Mark Thomson]

I am planning to architect the system with the following components

1. GUI
2. Server
3. Database Layer

Now in network mode the GUI access's the server via the RMI Interface. In Non gui mode the GUI access's the servers code directly, bypassing the RMI interface altogether ( as per the spec )

Now in the spec SUN mention the following:

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

Does this mean in non-networked mode my GUI has to access my Database layer directly and not access the server code at all. Or does it mean I must not use the Server RMI interface, but I'm ok to access the actual Server methods??

[Robert Konigsberg]

In some assignment requirement, server GUI is a must. My instructions.html reads:

quote: All configuration must be done via a GUI, and must be persistent between runs of the program.

I don't agree. I had the same requirement. Why can't you use the CLIENT app to configure the server? If it's all deployed from the same jar (which I assume you have too) then your client app can perform the configuration, and it'll write to the same .properites file as the server would read.

I also added a shutdown button on the client. I documented in the user guide that when someone shuts down the server, one should tell all other users that they must disconnect.

RK

[Jon Entwistle]

Hi Robert,

If it's all deployed from the same jar (which I assume you have too) then your client app can perform the configuration, and it'll write to the same .properites file as the server would read.

I think that is a very dangerous assumption to make.

Even though it is not explicit from the requirements, it is very safe to assume that the server will need to be able to run on a machine which is different from clients (otherwise there is no point in the server/client mode.)

Regards,

Jon
[ July 22, 2004: Message edited by: Jon Entwistle ]

[Robert Konigsberg]

I don't agree, and I may be wrong.

In the REAL WORLD, I would agree this is a dangerous assumption. Additionally. in the real world I would also be able to speak to people and find out something about what is behind the requirements. After 13 years I've never been prevented from getting *some* clarifications, either through the requirements or user-acceptance phases. This project is certainly not the real world, though it does have lots of real-world aspects to it.

Truth be told, it's not unreasonable to add additional conversation between the client and server, such that server parameter management could be handled through RMI-or-other interface. However one could just as well say that I was preventing the interface from being over-complicated.

In a real-world implementation I would find out what kind of environment the server resides on, and go from there. And also, like a real-world environment, I am once again being evaluated based upon some requirements that are somewhat arbitrary and out of my control.

RK

Truth be told, I'm less convinced of my position now than when I started defending it. Oh well, I'll play the devil's advocate for a while and see where it leads.

[Satish Avadhanam]

Hi Robert

Originally posted by Robert Konigsberg:


Why can't you use the CLIENT app to configure the server? If it's all deployed from the same jar (which I assume you have too) then your client app can perform the configuration, and it'll write to the same .properites file as the server would read.

Say client 1 is on machine 1 and server is on machine 2, I am just curious on how the server configuration can be done from client 1 machine. The requirement is that properties file MUST be present in the working directory where jar is deployed. When you deploy jar on machine 1 and have its own properties file, how is that client can configure properties on machine 2 where server is running? I am not saying that its not possible, but what if 10 clients want to configure the server properties file at a time and here again we want to deal with the "synchronize" concept . Nope. I think its better to have server its own gui and that when application is run in server mode we have only one GUI which configures local properties file rather than 10 different clients wants to configure from 10 different machines and their implications


I also added a shutdown button on the client. I documented in the user guide that when someone shuts down the server, one should tell all other users that they must disconnect.

RK

So if client 1 shuts down the server, command goes from client 1 to server to shutdown and from there to all other clients which are connected to server?

[Robert Konigsberg]

Satish,

You're not catching what I'm trying to communicate. Configuring Client1 will only configure for that machine. Running the client software on the server will configure for *that* machine. That's the solution I implemented. In other words, there is no "synchronization" need. Don't forget, "CLIENT" has no specific meaning. I took it to mean "All GUI operations."

Also, yes, shutdown by the client to the server is how I handled it. My user guide says, "Before shutting down, contact the other clients." Why did I do this? Because I am only allowed three command-line options, and no additional programs.

Part of the problem with this assignment is that the requirments say "must" so often that have to get creative and/or have less-than-optimal solutions. Refer back to what I said about having some opportunity to get feedback on requirments.

RK
[ July 23, 2004: Message edited by: Robert Konigsberg ]

[Satish Avadhanam]

Originally posted by Robert Konigsberg:
Satish,

You're not catching what I'm trying to communicate. Configuring Client1 will only configure for that machine. Running the client software on the server will configure for *that* machine. That's the solution I implemented. In other words, there is no "synchronization" need. Don't forget, "CLIENT" has no specific meaning. I took it to mean "All GUI operations."

OK, I got it now. If you want to configure machine where server is running, we have to run the jar from command line in same directory in modes other than server so that client gui comes up and then configure it to write to properties file. When server is run in the *same* directory it can use that configuration. If we want to run the server in a different directory, then again we have to run the jar in client mode in that directory.

RK

[ July 23, 2004: Message edited by: Robert Konigsberg ]

[Robert Konigsberg]

Yep. Not the best, not the worst. In the end, it would be best for someone to just manually edit the file, but nooooo that's not what they want. OK.

[Mark Thomson]

I am planning to architect the system with the following components

1. GUI
2. Server
3. Database Layer

Now in network mode the GUI access's the server via the RMI Interface. In Non gui mode the GUI access's the servers code directly, bypassing the RMI interface altogether ( as per the spec )

Now in the spec SUN mention the following:

quote: The 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.



Does this mean in non-networked mode my GUI has to access my Database layer directly and not access the server code at all. Or does it mean I must not use the Server RMI interface, but I'm ok to access the actual Server methods??

--------------------

Can anyone clarify?

[Robert Konigsberg]

Consider creating a layer that LOOKS like the server layer, but just passes through.

In other words:

interface Operations
{
...
public int[] find(...);
public String[] getRecord(int);
...
}

public class RMIInterface implements Operations
{
...
}

public class NonNetworkedInterface implements Operations
{
...
}

That makes your architecture very easy.

RK