Java client-server: what options are there?

[Ramon F Herrera]

This is an issue that I have been pondering and investigating
for years, and I wish there was a book, chapter or URL that
covered it.

I have to develop client-server systems in which the following
is pretty much decided:

- The database is Oracle 9iR2
- The server OSs are Solaris and Linux
- The clients (a few dozen) are Windows (XP?)
- The client side runs on Java

Those are the givens, the rest is up for grabs...

The main undecided part is: exactly how to realize the client-server
connection? That's what I would like to hear and read about.
What options do I have?

To get the ball rolling, I will share my experiences so far.

First, I tried the JDBC approach, with a standalone application.
There was a stored procedure in the server, and it was called
from the client. The cons were: the size of the JDBC being much
larger than my app, and there was also the issue of performance.
I feel that I should move more of the functionality and heavy duty
processing to the server side, where I can have plenty of horsepower.

My second attempt was a Java applet which got its data
through CGI-BIN from an OCI C program running on the server.
The performance was pretty good and I'd like to stick with
the OCI part but not with CGI-BIN.

I just began the third approach: using SSH. The server part
is a given since it comes ready in Linux, and I got the Java
client part from sshtools.com.

I have read about servlets, Tomcat, etc. but it looks like once
I get into that stuff (the area seems to be called "Enterprise"),
the tools become extremely expensive (for instance I will have
to upgrade my $700 Developer JBuilder to a $3500 Enterprise JBuilder).

The issue of performance still worries me (I am a speed freak):
I wish I could just use the Unix R-commands (rsh, etc.) so all
the encrypting-decrypting doesn't get in the way of client
performance (my app is Intranet in a trusted environment) but
I guess I can live with the more modern, secure, etc., SSH.

Thanks very much for sharing your expert insight on this,
(and if you are a writer deciding on a topic, I'll bet that
this one will sell a lot of books! - anyone from O'Reilly
out there?)

-Ramon F Herrera

 

[Sudsy]

Ramon F Herrera wrote:

Thanks very much for sharing your expert insight on this,
(and if you are a writer deciding on a topic, I'll bet that
this one will sell a lot of books! - anyone from O'Reilly
out there?)

Not likely! There are already scads of books out there which address
issues such as these, although it doesn't look like you've read many
of them (no offense intended).
The problem is that you're mixing up too many different approaches
and technologies. You could easily write a Java daemon which uses
JDBC to talk to the database and a ServerSocket to communicate with
clients. Then it's just a matter of deciding on the protocol.
That's a tougher call since only you can answer questions like:
- are you planning on returning result sets? (e.g. from SELECTs)
- do you need all the information at once? (all field contents)
- do you want paged results? (fetch in groups of n)
- do you need to scroll through the results?
I'd tend to go with a Value Object approach. Small, efficient and
narrowly focused.
Drop me a note off-line and I can send you some basic code. And
forget about the secure shell (SSH) protocol. From the description
of your environment, it's overkill.

 

[hiwa]

(e-mail address removed) (Ramon F Herrera) wrote in message
Currently there would be no choice but the HTTP/servlet/JSP/JDBC
framework. Don't worry about Enterprise stuff. You could do it almost
free with free tools as Tomcat, Eclipse, Netbeans, JUnit, Jakarta
Struts, etc., etc.

 

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

<snip>

Currently there would be no choice but the HTTP/servlet/JSP/JDBC
framework.

Why would that be? Why would middleware not be an option? Mightn't
sockets also solve Sudsy's problem?

 

[Ramon F Herrera]

There are already scads of books out there which address
issues such as these, although it doesn't look like you've read many
of them (no offense intended).

None taken!

I even own some books on this general topic(for instance, one
on how to connec via Oracle JDBC), but they seem to be
too "vertical" and in-depth on one particular approach.
I would have to read, say, 20 books and then make my own
conclusion. What I am wishing for is the "horizontal" type
of coverage that you can get in a newsgroup: the approaches
are as follows, these are the pros and cons, and this is
an executive summary on how to implement each approach.
I guess I am looking for "the skinny" on Oracle client-servers
approaches.

Thanks!

-Ramon

 

[Sudsy]

Ramon F Herrera wrote:

I even own some books on this general topic(for instance, one
on how to connec via Oracle JDBC), but they seem to be
too "vertical" and in-depth on one particular approach.
I would have to read, say, 20 books and then make my own
conclusion. What I am wishing for is the "horizontal" type
of coverage that you can get in a newsgroup: the approaches
are as follows, these are the pros and cons, and this is
an executive summary on how to implement each approach.
I guess I am looking for "the skinny" on Oracle client-servers
approaches.

Thanks!

I usually start from the bottom up, which is why I suggested
a Java daemon to begin. Since you already have access to a
webserver (to run the CGI code) then the next step up would
be a Java servlet running under Tomcat. Tomcat would merely
provide the servlet container functionality for the Apache
front end. Nicely documented and fairly simple to install
and configure. You just send/receive serialized objects
using HTTP for transport.
At this point you might reconsider the format of the data
exchange. Depending on your requirements (i.e. if you're
ever going to make this application available externally)
then you might think about using XML. You can document the
content very nicely with XML Schema and validate along the
way.
From here you start getting into some more sophisticated
solutions, often involving RMI and/or IIOP. While these
can certainly be applicable to larger, enterprise-level
applications, their use would be overkill for what you've
described. They're more more for use in heterogeneous
networks, accessing legacy code, etc.
Be wary of those who would suggest a particular toolset for
every situation. It's amazing how when you give someone a
hammer suddenly everything resembles a nail! I'm not about
to suggest a J2EE solution with entity EJBs, for example.
Start simple.

 

[Andrew Thompson]

hiwa wrote: ....
Why would that be? Why would middleware not be an option? Mightn't
sockets also solve Sudsy's problem?

The OP was Ramon, not Sudsy.

 

[Juha Laiho]

(e-mail address removed) (Ramon F Herrera) said:

I have to develop client-server systems in which the following
is pretty much decided:

- The database is Oracle 9iR2
- The server OSs are Solaris and Linux
- The clients (a few dozen) are Windows (XP?)
- The client side runs on Java

Those are the givens, the rest is up for grabs...

Pretty much money into the database engine, and apparently also for
the Sparc (Sun) hardware, but then, that's still the currently most
used model.

The main undecided part is: exactly how to realize the client-server
connection? That's what I would like to hear and read about.
What options do I have?

As others have discussed, create the server side Java-based, so your
JDBC connection is between the server-side Java classes and the database,
and either use applets or pure HTML-browser on client side (to connect
to the server-side components).

I have read about servlets, Tomcat, etc. but it looks like once
I get into that stuff (the area seems to be called "Enterprise"),
the tools become extremely expensive (for instance I will have
to upgrade my $700 Developer JBuilder to a $3500 Enterprise JBuilder).

No, no J2EE needed here. As development tools, take a look at NetBeans
and Eclipse and pick the one you like. Or then just use your favourite
code editor.

The issue of performance still worries me (I am a speed freak):

Then design your database structure properly, and have someone to set
up the DB system correctly. After that, make sure your algorithms are
proper for your data. Think how much data you're transferring and
accessing at each point, and plan to minimize data volumes as early as
possible.

 

[cboy]

re:
for instance I will have
to upgrade my $700 Developer JBuilder to a $3500 Enterprise JBuilder

No need to do an upgrade - you have all the tools you need to do what you
need for servlets, jsp.
Enterprise JBuilder will offer you nothing you need for this kind of stuff.

Andles

 

[Rolf Breuning - Remove _ from Email]

Hello,

A number of possible solutions - with a number of questions to decide:

1. Database / Webserver / Browser
2. Database / Webserver / Browser / Applet
3. Database / Server / Java-Program
4. Database / Java-Program (The direct Client JDBC-solution which you already ruled out)

If on the client GUI is simple enough to be realized by a HTML / browser interface I would go for solution 1 (pure Webserver / Browser) as
it requires no installation at the client side. A Tomcat based server is then a good solution. Encryption is possible (https) but from your
requirements (trusted network) not necessary. Tomcat is freeware and being a pure java program development can be done with any environment
(at least freeware tools can do it, I don't known about JBuilder).

If a complex GUI is needed or a tighter integration into the client platform (e.g. file system access) is required, solution 1 is not the
best; Solution 2 with an Applet is still possible. In an Intranet environment, however, it does not offer much additional benefits over
solution 3 (Database / Server / Java-Program solution. In both cases, the server and the client talk directely over a specific connection
protocol.

As a communication protocoll between Server and client you might use directely TCP-Sockets as available in the java classes.
If you know TCP, this is an easy solution. You can package data to be transmitted into Java objects, use the Java serialisation feature to
send them.
Java, however, also offers various middleware alternatives:
- RMI (Remote method invocation) is the Java
- Java also comes with a CORBA implementation, which is cross-language and may be considered if one of the communication partners is not in
Java.

Regards

Rolf Breuning

 

[Rolf Breuning]

Hello,

A number of possible solutions - with a number of questions to decide:

1. Database / Webserver / Browser
2. Database / Webserver / Browser / Applet
3. Database / Server / Java-Program
4. Database / Java-Program (The direct Client JDBC-solution which you already ruled out)

If on the client GUI is simple enough to be realized by a HTML / browser interface I would go for solution 1 (pure Webserver / Browser) as
it requires no installation at the client side. A Tomcat based server is then a good solution. Encryption is possible (https) but from your
requirements (trusted network) not necessary. Tomcat is freeware and being a pure java program development can be done with any environment
(at least freeware tools can do it, I don't known about JBuilder).

If a complex GUI is needed or a tighter integration into the client platform (e.g. file system access) is required, solution 1 is not the
best; Solution 2 with an Applet is still possible. In an Intranet environment, however, it does not offer much additional benefits over
solution 3 (Database / Server / Java-Program solution. In both cases, the server and the client talk directely over a specific connection
protocol.

As a communication protocoll between Server and client you might use directely TCP-Sockets as available in the java classes.
If you know TCP, this is an easy solution. You can package data to be transmitted into Java objects, use the Java serialisation feature to
send them.
Java, however, also offers various middleware alternatives:
- RMI (Remote method invocation) is the Java
- Java also comes with a CORBA implementation, which is cross-language and may be considered if one of the communication partners is not in
Java.

Regards

Rolf Breuning