Servlet Between Application and SQL Server

[Scott Florez]

Hi folks. I have a "stand-alone" Java application that uses JDBC to connect to a SQL database, however I'm needing to make it web-based. Applet security understandably precludes me from using JDBC. So I figure the best way to make my application web-based is to write a servlet that acts as middleware between the Java application (which I would make into an applet) and the SQL server. While I mostly understand creating stand-alone servlets, could anyone direct me to a tutorial explaining how to implement a servlet that receives SQL queries from a Java application and passes them to the SQL server, and then return the results from the SQL server to the Java application? Or, if there's a better solution to my problem, please let me know. Thanks so much!

[Bear Bibeault]

That's a really odd approach to take.

If it were me, I'd either port the app to an Applet, or to a servlet/JSP based web application. Either should be easy to do if you've already architteted your application to have the model and business logic separated from the UI.

The combination approach is rather unconventional and is likely to be a royal PITA.

[Jeroen T Wenting]

Not to mention a MAJOR security risk.

[Scott Florez]

Originally posted by Bear Bibeault:
That's a really odd approach to take.

If it were me, I'd either port the app to an Applet, or to a servlet/JSP based web application. Either should be easy to do if you've already architteted your application to have the model and business logic separated from the UI.

The combination approach is rather unconventional and is likely to be a royal PITA.

Bear, thanks for your insight. Let me explain the way I understand things:

I can easily port the application to an applet which does seem easiest, but JDBC has its own security risks when running an applet. In fact, if you try to run an applet with JDBC in it, the JDBC part seems to be simply ignored by the VM. I believe you can make JDBC work in an applet if you manually override the security, but that obviously is a big security no-no.

It is my understanding that the reason for JDBC to be "blocked" in an applet is because of how easy it is to decompile class files. If you have database connectivity information in the application, such as the server IP address, username, and password, then it would be quite easy for anyone to obtain this information. Thus, I figured the servlet running server-side in the background would be the way to go.

Is there a better and secure way of doing this, or is there even a way to use JDBC with an applet? While I have a pretty good grasp of Java application-type stuff, I really am a novice when it comes to server-side/web-based Java technologies. Thanks so much!

[Ben Souther]

I think what the others are trying to say is that a servlet that recieves SQL commands from the web (applet, browser, or otherwise) is a very dangerous thing.

The following Google search will give you links to several good articles that cover Servlet/applet communication via Java object serialization and/or HTTP form params.
http://www.google.com/search?hl=en&q=applet+servlet+tunnelling&btnG=Google+Search

Whether you go that route, or, as Bear suggested, just build the whole thing as a webapp (no applets), I would strongly suggest not executing raw SQL commands from the web. It's better to use prepared statements with parameters passed in from the client and thoroughly validated.

[Scott Florez]

Originally posted by Ben Souther:
I think what the others are trying to say is that a servlet that recieves SQL commands from the web (applet, browser, or otherwise) is a very dangerous thing.

The following Google search will give you links to several good articles that cover Servlet/applet communication via Java object serialization and/or HTTP form params.
http://www.google.com/search?hl=en&q=applet+servlet+tunnelling&btnG=Google+Search

Whether you go that route, or, as Bear suggested, just build the whole thing as a webapp (no applets), I would strongly suggest not executing raw SQL commands from the web. It's better to use prepared statements with parameters passed in from the client and thoroughly validated.

Thanks for the response. I want to implement applications using whatever is generally the most secure and "industry-standard" method of producing Java web-based applications. The problem is that I already have several stand-alone applications that I am needing to port to web-based applications. They all use JDBC, so I can't just port them to applets. Bear said that it would be easy to port my existing applications to JSP, but I don't really see how. Wouldn't that mean that I'd need to entirely re-design the Java GUIs as HTML?

At this point I'm ready to re-design my applications from the ground up if necessary, but I need to nail down the surefire best technology to use to do it. So let me just ask a simple question: what is the single best way to create complex Java applications that can be partially or fully integrated into a web browser, which also have JDBC interaction with a SQL server? Thanks!

[Ben Souther]

One thing you might want to consider is building a Data Access tier that is independent of the user interface (UI) that you plan on using.

Build a set of Java classes with methods that query the database and return serializable objects (Lists of Row Beans for example).
With such an approach, you could call these objects from a servlet app that either binds them to scope for markup in a JSP or streams the serialized objects to your applets/web start/ or other Swing type app for use within.
You could also import and use the data access objects directly from a Swing desktop app when within a secure subnet.