Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Java client-server: what options are there?

Re: Java client-server: what options are there?

From: Rolf Breuning - Remove _ from Email <Rolf.Breuning__at_t-online.de>
Date: Mon, 05 Jan 2004 20:44:12 +0100
Message-ID: <btceok$nds$03$3@news.t-online.com>


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

Ramon F Herrera schrieb:
> 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.
>
> -Ramon F Herrera
Received on Mon Jan 05 2004 - 13:44:12 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US