could anyone help me in this scenario.I extracted classes12.zip and put it in the same codebase.And the Applet class file is in the sam codebase.After that only its recognising all classes but getting this exception.Though sun says we don't need policy file as its loaded from codebase and accessing the server there.So what is the solution?? URGENT
hi suman, the problem it seems the database machine- 10.10.1.72. datbase machine is not accessible from ur applet. instead using jdbc directly from the applet my suggestions would be following, 1. use jdbc connection from a servlet and then let applet communicate directly with the servlet to run any query and get any results OR 2. use XML based communication to send anything to the server where a servlet would interpret it and dump it to the database and give results back in XML format which Applet can interpret (essentially this is the same case as 1st option but with XML data exchange rather than direct URLCOnnection communication b/w applet/servlet) OR 3. use RMI from the applet and let the RMI object on the server to handle the database communication
the reason we should avoid using jdbc from the applet are- 1. "the client machine needs to have the jdbc driver on their machine to make it work". We can of course put that jdbc driver in the CODEBASE for client download but if the driver is big then it is unnecessary download for clients apart from the applet code itself 2. this design won't be much scalable/flexible. what if u change the database from oracle to informix or something?? u end up chaning the applet code and the html for the applet and let clients download new jdbc driver via the CODEBASE... its better to separate database communication from the applet instead... regards maulin
Maulin makes excellent points. I'll say much the same but say it shorter: When you do JDBC from an applet that's a 2-tier system. Maulin has given some good reasons for avoiding a 2-tier, but here's another: SQL Slammer A 3-tier system wouldn't have the database server exposed directly to the internet. Thus, the server is better protected. Also, you wouldn't have to sign the applet or put server-dependent code in the applet. 3-tier is more expensive than 2-tier. It's more complex and there's some additional runtime overhead. But it's usually worth it.
An IDE is no substitute for an Intelligent Developer.
Fred, I don't think this question directly relates to the topic, so you might not get as many good answers as you would have if you'd started your own topic. But maybe I can help a little. The original question here was applets and JDBC, so I figure that maybe you're looking for database access from an applet. For a 2-tier solution you don't need a servet/JSP server. Applets can be downloaded from almost ANY web server, including Apache and IIS. Once the applet has downloaded and started, if it's using JDBC, that doesn't go to a Java server either. In most cases, the JDBC request goes directly to the database server and not a web server. For example, the JDBC drivers for SQL Server build up a TCP/IP request that goes to the server's TCP/IP port (normally that's port 1433). To do actual client/server programming with IIS, doesn't work, I don't believe. You could do requests to MTS, but that would actually be a CORBA request, since RMI is Java-to-Java, and not Java-to-VB or Java-to-C/C++. For any of the above solutions, however, you can only do work using a signed applet, as each one of them needs some sort of privileges beyond what the applet sandbox permits. A lot of times you'll get better and more maintainable results by simply using a 3-tier solution. An unsigned applet can send requests for data (and updated data) back to the same server it came from (even if it's running IIS) using a process known as HTTP Tunnelling. Another good reason for 3-tier solutions I didn't mention before but should have is that CORBA, RMI, and most JDBC connections are done via special TCP/IP ports. You don't want that for an applet that's going to be used on the Internet. Many companies only allow a very restricted set of TCP/IP ports to go through their firewalls, so if you try and access port 1433 at a company that only allows access through ports 80, 443 and 8080 (the well-known HTTP and HTTPS ports), your applet won't run.