Couple of questions -- 1. I learned that applet can be embedded in a html page given a "file.jar" which indicates those class codes. So when a client opens the applet, does it download the "file.jar" file ? 2. If the answer to question 1) is yes. Suppose I want to do some database query/update, I write the back end code using JDBC and write the GUI applet with panels inside, then I pack the back end code into a .jar file and deliver to client. However, when I write the JDBC part I didn't assume it is a remote client-server mode (i.e. I didn't use RMI or TCP/IP), then when client download the .jar file, how can it work remotely from client side ? If you think I didn't make it clear enough for question 2), please answer this for me --- How do you write an applet application that can access remote server's database ? I mean, what parts of code should be put in the .jar and what should be taken care of ? Thanks, Steve
Well, what you are actually doing is executing an applet. Whether the classes that make up the applet are loose files or in one or more jars - or both - is just a matter of implementation. In most cases, the browser will download the code it needs and store it in cache, loading and executing as necessary, The exact way the code is made available isn't important as long as the results are according to spec. HOWEVER. When you attempt to execute JDBC code in an applet, regardless of how the client receives the applet classes, you'll get a java security exception thanks to the applet security "sandbox". What you're trying to do is a 2-tier database app and that's usually a BAD THING. Why? A number of reasons, but one example is SQL Slammer. SQL slammer infected hosts that were foolish enough to open an SQL Server tcp/ip port direct to the internet - which they'd have to do if 2-tier apps were accessing the database. You can authorize an applet to use JDBC, but you have to create a signed applet. Even if you do, however, it may not always work. A lot of companies restrict what TCP/IP ports will go through their firewalls to only FTP and HTTP and forbid traffic over the ports that carry database communications. Usually a 3-tier design is better. It's a little long to describe here. I recommed you check your local library or bookstore. The magic word is "HTTP Tunneling". That's a technique by which you can send requests over HTTP to a JSP, servlet, CGI or other server-side application to talk to the database. The actual database code (JDBC) runs on the server according to requests from the client (applet).
An IDE is no substitute for an Intelligent Developer.
Joined: Mar 26, 2003
Tim, thanks lot for the response. Could you help me understand better by this specific example --- Suppose my applet has few picklists boxes showing departure and arrival time of an airline, then after lick a "Go" button I want to show available flights on the bottom panel in the same applet. Apparently the last step requires DB query. So, based on your suggestion of "3-tier". Should I implement another servlet code that takes the information of "departure, arrival dates" from the applet and do DB query and then return the results to the applet ? In this case, is "servlet" usually the good "middleman" candidate between applet and database ? what else can be candidates ? Thanks, steve
That's correct. The server-side code can be a servlet, a JSP, a CGI program, Windows ISAPI DLL code, SOAP services, or whatever kind of code you prefer. As long as you can send down your request and get a response via HTTP it really doesn't matter how the server does it. I'm focusing on HTTP tunneling here because it's probably the most common technique, since the protocols are well understood and the problems due to sandbox rules and firewalls is minimized. Although I should note that an unsigned applet can only talk to the server it was downloaded from! The best way to do HTTP tunneling is to use the java.net.HttpURLConnection class. This allows you to easily set up the request and recieve its response plus it also automagically handles the support services such as cookies - which are often used to maintain secure sessions with the server. HttpURLConnection will send and recieve the cookies for your browser without you even having to write code or set up special options. The format of the data you request and of the response is up to you. You can use GET or POST and transmit data as simple lines of text, XML or in whatever form you like. I recommend text forms over binary, partly because it's easier to test, partly because most of the good reasons for using binary (compression, security, etc.) are now part of basic support services, and partly because it's simply easier to diagnose problems when you don't have to pick bits apart. One thing I don't recommend is use of the Java serialization services - people get burned when the server is using a different version JVM on the server than on the client. The Java serialized data format has been known to change.