This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Manish, Servlets are not a requirement in order to access online databases. It's just that servlets make things a whole lot easier. An applet with the appropriate security clearance can access databases. i.e The applet has to be on the same server as the JDBC database. Bosun
Bosun (SCJP, SCWCD)
So much trouble in the world -- Bob Marley
So an applet CAN access a database! I thought I had read that it can't. One question, tho. How does the servlet make it easier?? So far using JDBC methods to create SQL statements seems pretty straightforward. If these can be put in an applet, so I don't have to write a browser(!) how would servlets help me? I'm trying to minimize the complexity of the server end, because I don't have much control over it, and it's far away! I was hoping it could just contain the database.... but I need all the help I can get! thanks!
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>"Those who cast the votes decide nothing. Those who count the<BR>votes decide<BR>everything." <BR> -Joseph Stalin<HR></BLOCKQUOTE>
Hi, The applet can surely access the database using JDBC type 4 drivers. These drivers are also called as "Thin" drivers and are completely written in Java. They do not use the legacy drivers on the server. Instead they directly connect to a TCP port where the Database server is listening.
Servlets are just a means to connect to the database using JDBC. Advantages of using servlets as a middle layer : 1) Servlets can use the other types of JDBC drivers(including the ones that use legacy code) and are not limited to Type 4 drivers as applets. 2) The database need not reside on the same machine (which is a requirement enforced by the applets sandbox). Thus, there is much more flexibility. Disadvantages: 1) All the data is wrapped in HTTP requests and response and thus encounters all the HTTP problems. We could visualize 2 different types of applications that use the aboive architectures. Case 1 : Front-end : HTML form. Then, in this case, there is no way the browser can connect to the database. Thus, we have to use the good old HTTP paradigm and packjage the request into HTTP messages and send it to the servlet which in turn connects to the Database and does the stuff. In this case the Business logic needs to be on the Server side. Case 2: Front-End : Applet In this case, the applet can directly connect to the Database (which should be on the same machine as the webserver from which the applet was loaded) using Type 4 thin drivers. In this case the Business logic needs to be on the Client side. There could be an in-between type of applications which use an applet as well as a servlet. In this case, the Bus. Logic could be on either side and also, any type of driver may be used as the servlet would connect to the Database. Hope this helps. Ashwin.
Joined: Nov 26, 2000
That confirms what I had been thinking. I will need to use an applet..... But one conceptual problem I haven't got around: (even though I have a database up and running) Can I talk to a database over a network from a plain ol' application?? WOuld my app have to be essentially a browser, or am I already there?? (I am talking to my database via a type 4 driver, but I'm not sure if that means I'm using the network, or not. ) Hmm. ?:^| Thanks!
Unless the database resides on your machine locally you would be talking to the database over the network. Usually most databases have some type of configuration file that accepts requests for services across a network (a listener of some sort). It is usually configured as existing some machine (host name) giving access to database resources (a database identifier) on some specfic port address. This raises an advantange that was not mentioned. Execution speed and network latency. Usually a database resides on a machine that has a lot of memory, a lot of disk space and a speedy processor. Usually SQL statements execute faster on the server side rather than on the client side. Getting results to a client machine across your network will be the most time consuming portion. Hope this helps, Rob Thompson