There’s way too much new stuff to learn! You could spend the rest of your life—including the additional 100 years you’ll get because of Y2K—learning the technologies listed in Table 1.2 and still not master them all. Oracle Corporation is far ahead of most of us; we’re lucky if we can keep our existing production systems running, much less learn dozens of new tools and methodologies.
Given the increasing importance of the Internet, though, we need development skills that we can use right now, not in the distant future. Additionally, some sites, for one reason or another, haven’t even moved from Oracle version 7.3 (or even 7.0) to Oracle8, much less Oracle8i. What are they supposed to do?
In this section I’ll suggest an approach to building web applications for Oracle8i that you can learn in just a week or two, even if you currently know nothing about the Web and even if you’re still using Oracle7. Everything I’ll cover will migrate smoothly to Oracle8i. In this way, you’ll have time to start learning the other technologies even as you develop new systems. The approach I suggest here uses a subset of the technologies listed in Table 1.2: OAS, WebDB, HTML, PL/SQL, and XML. I’ll also tell you why I think Java should be your second step.
The first thing you’ll need to do is connect the Oracle database to the Web. The simplest way to do this is to use either OAS or WebDB. Both products work with Oracle 7.3 or above. I’ll cover each in its own chapter, focusing on what you, as an application developer, need to know to use and understand the technology.
Once you’ve seen how to connect the database and the Web, you can start learning how to write web applications by combining HTML, the language used to create web pages, with PL/SQL, the SQL-like language used to develop Oracle stored procedures. The next three sections explore the reasons for choosing these tools.
HTML is based on a simple principle: a limited syntax composed of tags and attributes can define almost any document, from a quarterly report to an online catalog. Each tag affects the text between the start tag and the end tag. Tag attributes act like parameters that refine the tag’s behavior. There are several reasons why HTML is an appealing user interface:
HTML uses a simple, forgiving syntax to create documents. These documents can range from a text-only listing of all employees in a particular table to a complete data entry form that inserts or updates a record in a table. This simplicity is in stark contrast to the host of proprietary languages that try to be all things to all people.
A browser running on a PC, a Macintosh, or a Unix system will display a document in roughly the same way. Because virtually all browsers support HTML, you can concentrate on developing the contents of a page without worrying about how it will be distributed. If you build an online employee directory, anyone with a browser can access it through an HTML interface, regardless of the type of machine they have.
With a browser and a TCP/IP connection, a user can access any application on your network by simply typing in the appropriate URL. Imagine trying to coordinate a similar system based on Oracle Forms. Use of HTML eliminates the version conflicts, SQL*Net conflicts, and configuration headaches that make being an application developer a real drag.
HTML is a non-proprietary, standards-based language. If a browser supports the base HTML language, it can display any HTML document, even if the document is 10 years old. This gives considerable freedom to you as a developer, because as long as browsers support HTML, a user can modify or change his machine however he wants, and your application will still work.
Despite all these advantages, HTML is not a panacea. There are some limitations that affect the way you design an application:
HTTP, the underlying protocol of HTML, is a stateless protocol, meaning that it doesn’t preserve information between connections. This seriously affects the way you must design web applications. We’ll discuss this in later chapters.
PL/SQL is an evolutionary, not revolutionary, step for most IS developers because it’s a straightforward extension of standard SQL that’s ideally suited for database processing.
Packages (groups of procedures and functions) provide many of the benefits of object-oriented languages without the hassle of learning a brand new programming methodology.
PL/SQL stored procedures are accessible from any SQL*Net or ODBC product, from Oracle Forms to Pro*C to Microsoft Access to Java. As a result, you can implement a business rule in the database as a PL/SQL procedure and use it in any frontend tool, rather than writing the same logic again and again for each development environment.
PL/SQL is included with Oracle version 7 and above and is supported on all Oracle platforms.
Oracle8 introduced, and Oracle8i refined, a host of performance improvements to PL/SQL. Additionally, packages are parsed, stored, and executed inside the database, providing superfast data access. Once loaded, these packages may be shared across multiple sessions, resulting in even better performance.
Millions of lines of production PL/SQL code are quietly humming away in companies across the world. While it may not have the sex appeal of some other technologies, PL/SQL has proven itself a scalable, robust solution in thousands of mission-critical applications.
The major downside of PL/SQL is that it’s a proprietary language supported only on Oracle systems. If you are concerned about locking yourself into an Oracle-only solution, you should consider using Java.
You’re probably wondering why, if Java is the future of Oracle, you should bother with PL/SQL at all. The answer is pretty simple: almost all IS developers are prepared to take advantage of PL/SQL and its many capabilities without a great deal of new training. Java, on the other hand, demands a solid understanding of object-oriented design and programming (a technique substantially different from the structured programming model used by languages like COBOL or C) before you can begin using it effectively. If you’re worried that PL/SQL is doomed to go the way of Latin, consider the following:
The millions of lines of production PL/SQL code provide a wonderful disincentive against the wild-eyed radicalism of Java zealots.
Oracle’s strategy acknowledges that there is no “one-size-fits-all” solution for every problem, and has repeatedly emphasized that Java and PL/SQL will coexist in the database and play off one another in the future.
The performance improvements for PL/SQL in Oracle8i, combined with the fact that WebDB is a PL/SQL application, bode well for Oracle’s commitment to the language.
Finally, and most importantly, Oracle has publicly committed that it will support PL/SQL forever!
By the way, I’m not advocating Ludditism. Java is a very important and interesting language that you need to learn. In the interim, though, you can use PL/SQL to develop hundreds of useful web applications that will make your users very happy. Additionally, you won’t have wasted any effort; these programs will continue to work even after you’ve mastered Java and fully adopted Oracle8i. Finally, Oracle allows you to call PL/SQL procedures from inside a Java program and vice versa, allowing you to use the language most appropriate for the task at hand.
Other than Java, XML is probably one of the most important technological advances to hit the Web in a long time, especially in the arena of electronic commerce, electronic data exchange, and integrating the various parts of ERP systems. In the last chapter of this book you’ll learn how to create XML documents from inside the Oracle database, using PL/SQL.