MySQL and JSP Web applications

来源：互联网发布：数据比对工具编辑：程序博客网时间：2024/05/18 20:04

MySQL and JSP Web applications

JSP developers encounter unique problems when building web applications that require intense database connectivity. MySQL and JSP Web Applications addresses the challenges of building data-driven applications based on the JavaServer Pages development model. MySQL and JSP Web Applications begins with an overview of the core technologies required for JSP database development--JavaServer Pages, JDBC, and the database schema. The book then outlines and presents an Internet commerce application that demonstrates concepts such as receiving and processing user input, designing and implementing business rules, and balancing the user load on the server. Through the JDBC (Java DataBase Connector), the developer can communicate with most commercial databases, such as Oracle. The solutions presented in MySQL and JSP Web Applications center on the open source tools MySQL and Tomcat, allowing the reader an affordable way to test applications and experiment with the book's examples.

So What Is JSP All About?

　If you meet the requirements mentioned, you should already have a pretty good idea what the answer to this question is. JSP is all about doing highly object-oriented Web sites that can leverage all the best practices of modern software engineering. These practices include things such as SQL databases and UML-based design. This isn't to say that JSP is a cure-all and that using it will automatically make your Web site a paragon of engineering art. It's just as possible to design bad Web sites in JSP as with any other technology. That's why, as you go through the text, you will see how to incorporate the best practices and how to avoid the pitfalls of convenience when projects get stressful. JSP itself is an evolutionary step along the path that started with the first static Web servers, moved through CGI-enabled servers, and finally the first generation of script-enabled servers. JSP is less a Web server with a Java component than it is a Java engine that understands the Web.

　JSP grew out of Java servlets. Servlets allow the developer to handle the incoming Web requests using a Java program that has access to all the normal information that a Common Gateway Interface (CGI) program would. In addition, the servlet has access to session-persistent objects. These are Java objects that are associated with a specific user session and can be used to store state between requests. Servlet programming was a major step forward in allowing developers to write well-structured modular Web applications using an object-oriented language. It also solved the problem of state persistence, allowing more information to reside on the server during a transaction and less to have to pass back and forth between the user and the server. Servlets still suffered from one major problem. Because they eventually need to spit out HTML, the HTML coding had to be embedded in the servlet code. This led to code fragments like the one shown here:

Out.println("<HTML>\n<HEAD>\n<TITLE>Thank you for
Registering</TITLE></HEAD>\n");
Out.println("<IMG SRC=\"thanks.jpg\" WIDTH=200 HEIGHT=100 ALIGN=\"LEFT\”>");

　 This kind of embedding gets very old very fast when you have to code a lot of pages. In addition, having to escape all of the quotation marks can lead to a lot of confusing and hard-to-find errors if you leave out a backslash. Eventually, a still-better idea emerged. Suppose that you could combine the best of static HTML pages and with the interactive capabilities of servlets. The result was JavaServer Pages (on the Microsoft side, the result was Active Server Pages). As Figure I.1 shows, JSP is a complicated beast. In the next chapter, you'll walk through this flow in detail, but for the moment, here are the major steps:

1. A request comes in from a browser using the normal HTTP request format.
2. The Web server hands off the request to JSP. JSP looks at the filename and finds the appropriate JSP file.
3. The .jsp file is converted into a .java file, containing Java code that will create a class whose name is derived from the .jsp filename.
4. JSP then compiles the .java file using javac to produce a .class file. Note that the two previous steps are skipped if a .class file already exists and is newer than the .jsp file.
5. An instance of the newly created class is instantiated and sent the _jspService message.
6. The new instance looks to see if there is already an instance of the stuff.User object called user existing in the session object space for the currently connected user. If not, one is instantiated.
7. As part of servicing stuff.jsp, the user instance is called with the getUserName() method.
8. If the JSP processing requires access to information in a database, it uses JDBC to make the connection and handle the SQL requests.

　　　As you can see, a tremendous amount of power is available in the JSP world. Developers are free to write Web pages that look mostly like HTML, except where callouts to Java are required. But, at the same time, they are free to develop fully fleshed-out object-oriented applications using all the features that Java can bring to bear. They also get all the benefits of servlets, including session persistence.

Why Do We Need Databases?

　　　Well, one reason is so that Larry Ellison of Oracle can afford to keep himself on Prozac when he thinks about Bill Gates. A more serious answer is the same reason that drove man to first press a stick against a piece of wet mud: because it's good to write things down. Web servers are marvelous creatures, but they're a bit like idiot savants. Ask them to serve a Web page or run a piece of Java, and they perform like a champ. But start asking them to remember what they did five minutes ago, and they develop amnesia faster than a character in a soap opera.

The first and most important reason that you use databases is that there's a lot in an e-commerce transaction that you need to remember and track:

               •A user's name, address, credit card, and other information previously entered on a registration page
              •hat the user might have put into a shopping cart and left from a previous transaction
              •What items are in stock, along with their price, description, and so on
             •Orders that need to be fulfilled, orders that have been shipped, and items that have been backordered .
　　Now, you could store all this information in a flat file on the server's hard disk, but there are other important properties that you want to have for this data:
           •You want to be able to back out a transaction if part of it fails.
          •You want to be able to locate the data somewhere more secure than the Web server, which could be in a DMZ or outside the firewall altogether.
          •You want to be able to access data such as user data or products quickly, even if there are thousands or millions of them.
　　When you add these items to the shopping list, only a relational database will really do the job effectively.

MySQL

　　　Many sites don't need the battleship strength (and price tag) of Oracle. MySQL is an open-source SQL database available for anyone to use, with many (although not all) of the features of its big brothers, such as Oracle.
　　　MySQL is available for just about any computer that has decent power—it is fairly lightweight on the processor and easy to install (10 minutes, as opposed to multiple hours for Oracle).
　　　So, perhaps you are wondering, what's the catch? What are you not getting in MySQL that makes people turn to Oracle? Well, MySQL is a neat little package, but it is missing some things that would be nice to have in a perfect world.
　　　A major feature that MySQL does not offer is database consistency checking. You can use foreign key tags in your schema, but MySQL cheerfully ignores them. A lot of DB As I know would consider this a very bad thing.

　　　A foreign key constraint prevents you from creating inconsistent data. For example, let's suppose that you had a scheme that looked like this:
CREATE TABLE USER (
       USERID INTEGER,
       FIRST_NAME     VARCHAR(80),
       LAST_NAME      VARCHAR(80));
CREATE TABLE PURCHASE (
       USERID FOREIGN KEY USER(USERID),
       ITEM INTEGER,
       QUANTITY INTEGER);
　　　In a database such as Oracle's, if you created an entry in the PURCHASE table with a user ID of 3, there would have to already be a user ID of 3 in the USER table or an error would occur. Similarly, you couldn't delete user 3 from USER if it was referenced in PURCHASE.The MySQL folks make a pretty impassioned argument in their documentation that depending on foreign keys for data integrity is a bad idea anyway, but convincing your DBA of this philosophy is likely to degrade into a religious debate.

　　　In addition, some other features are missing, such as subselects and select into. But probably the other major piece that you will miss is the rollback/commit functionality. MySQL does implement rollback and commit for certain types of tables, but not all of them. Again, the MySQL folks offer their own spin on why this is okay, but being able to roll back transactions is (in my opinion) important enough to make sure that you have it available.
　　　Rollback allows you to set a savepoint on the database before starting to do a series of transactions with it, and be able to either roll back to the original state or commit the changes at the end. For example, when recording a purchase, you need to record a debit against the user's account and enter a record into the shipping table so that you'll know later to ship the item. Let's say that the second part fails. You wouldn't want to charge the user but not ship the item. Thus, you'd want to roll back to the state before the transaction began.
　　　So, MySQL isn't a full-blown production database—at least, not yet. It's still good enough for probably 90% of the e-commerce sites in the world, however. And version 4.0, which is in alpha as of this writing, addresses a number of these concerns, including row-level locking and transaction control.

Putting Tomcat and MySQL Together

　　　Combining Tomcat and MySQL provides a powerful, reliable, and free platform that you can use to learn, develop, and deploy JSP applications. And, best of all, the code that you develop using this platform will run nicely using iPlanet and Oracle or WebSphere and SQL Server.
　　　As a learning tool the two together are almost "reference implementations" of their respective protocols (JSP and SQL). As a result, you won't pick up any nasty vendor-proprietary bad habits while you're getting up to speed.
　　　In addition, you can enjoy the knowledge that you are supporting the open-source software movement. Open-source software is code that is made freely available under one of several public licenses, frequently the GNU General Public License (GPL).

FACTS AND FICTION ABOUT THE GPL

　　　The GNU General Public License is probably one of the most misunderstood documents in existence,The basics break down to this:
　　1. If you place a piece of software under the GPL, anyone is free to make a copy
　　　of it in either source or executable form and give it to anyone else.
　　　　2. If you take a piece of software under the GPL and use it as a part of your
　　　product, you can't charge for that product beyond duplication costs.
　　　Many people interpret this to mean that they can't use GPL software for commercial purposes. Nothing is farther from the truth. What you can't do is charge specifically for parts of your product that are partly or largely derived from GPL products.
　　　You are free to use GPL code in the development of a Web site because you're not selling the site itself to a third party as a product. (Consulting companies fall into a weird quasi-space, but no one has gone after them for using GPL software to date.)

　　　Why is it good to support this movement? There are two sides to this answer: one technical and one political. Technically, it's a good thing because open-source software tends to encourage the development of open standards such as JSP and JDBC, allowing you to choose your tools from among a larger group rather than being locked into one vendor's proprietary solution. It's a positive thing politically because it keeps the large companies honest. WebLogic and iPlanet have to stay competitive and responsive because they know that there's a free solution out there if they aren't. And when you use open-source software, you are sending a message that your overriding concerns are features and reliability, not having a large company to sue if something goes wrong.

0 0