Java Programming with Oracle JDBC

Clients

In Part II, we’ll examine how to establish JDBC connections from four types of Oracle clients: an application, an applet, a servlet, and an internal client. But first, I need to define what I mean by client. Let’s begin that discussion by clarifying the term client/server.

What Is Client/Server?

Over the years, I’ve heard countless, sometimes convoluted, definitions for the term client/server. This has led to a great deal of confusion when discussing application architecture or platforms. So you have a consistent definition of the term client/server, I propose we use Oracle’s early definition for client/server and then define the four different types of clients we’ll encounter in this book.

It’s my opinion that Oracle is in large part responsible for the definition and success of the so-called client/server platform. From its beginnings, Oracle has been a client/server database. Here’s my definition of client/server:

Any time two different programs run in two separate operating-system processes in which one program requests services from the other, you have a client/server relationship.

In the early days, before the use of networks, Oracle applications consisted of the Oracle RDBMS running on one operating-system process as the server and one or more end users running their application programs in other operating-system processes. Even though this all took place on one physical computer, it’s still considered client/server. The Oracle RDBMS represents the server, and the end-user application programs represent the clients.

With the use of networks, the communication between the client and server changed, but the client/server relationship remained the same. The key difference was that client and server programs were moved to different computers. Examples of this are the use of C, C++, VisualBasic, PowerBuilder, and Developer 2000 to develop applications that run on personal computers and in turn communicate with an Oracle database on a host computer using TCP/IP via Net8. This type of scenario is what most people think of when they hear the term client/server. I call this type of client/server architecture two-tier because the division of labor is a factor of two, not because the client and server programs run on two different computers.

Now, with Java and the Java 2 Enterprise Edition (J2EE), which includes servlets and distributed objects such as Enterprise JavaBeans™ (EJB), client/server applications have become multitiered. Such multitier applications, which can have three, four, or even more tiers, are referred to as n-tier applications (in which n is more than two tiers). For example, someone using a browser on a PC can execute a servlet on another host computer. The computer on which the servlet runs is known as an application server, and it in turn might execute EJB on a third host computer, which would be known as a component server. The component server might contact yet another server, a database server running Oracle, to retrieve and store data. In this example, we have four tiers: personal computer, application server, component server, and database server. Distributing the software over four computers is one means of scaling up an application to handle a larger volume of transactions.

With respect to the n-tier application, it’s possible to deploy that application so the application server, component server, and database server are all on the same host computer. In such a scenario, we would still call it an n-tier application because the division of labor among programs is a factor greater than two. The key point to note is that while we can run all the server software on the same host computer, the n-tier architecture allows us to distribute the application over multiple servers if necessary. Did you notice in these last two examples how a server might also be a client? The servlet running on the application server was the client to the EJB running on the component server, and so forth.

Now that you have a better understanding of the term client-sever, let’s continue by looking at the different types of clients that utilize JDBC and Oracle.

Types of Clients

As far as application development using Java is concerned, prior to Oracle8i, there were two types of clients: an application and an applet. Both run in a Java Virtual Machine (JVM), but an applet runs in a browser, which in turn runs as an application. Typically, an application has liberal access to operating-system resources, while an applet’s access to those resources is restricted by the browser. I say typically, because using the Java Security API can restrict an application’s access to operating-system resources, and with a signed applet, or security policies, you can gain access to operating-system resources. Another distinction between applications and applets is that while an application has a main( ) method, an applet does not. Yet another distinction is how they are programmed to connect to the database. Because of these distinctions, it is useful to consider applications and applets as two different types of clients.

With the coming of J2EE, servlets and EJB both became new types of clients. A servlet , a Java replacement for a CGI program, is a Java class that runs inside a servlet container similar to how an applet runs inside a browser. Typically, a servlet takes the input of an HTML form submitted by a browser and processes the data. A servlet may also generate an HTML form or other dynamic content. Servlets differ from applications in a couple of ways. Like applets, servlets have no main( ) method. There are also differences in how you program a servlet to connect to a database. More importantly, a servlet is an application component. One or more servlets are written to create an application.

Moving on to component technology, EJB is a Java component model for creating enterprise applications. EJB is a software component that runs in a component server, which is usually referred to as a Component Transaction Monitor or EJB Container. Like applets and servlets, EJB has special considerations when it comes to connecting to the database and performing transactions. Therefore, we’ll consider EJB as a fourth type of client.

With the release of Oracle8i, Oracle stored procedures could be written in Java and became a new type of client. Connectivity for Java stored procedures is very simple. Because EJB and Java stored procedures are both internal clients, we’ll consider both of them as the fourth type, an internal client. In summary, we have defined four different types of clients that may utilize JDBC:

• Applications

• Applets

• Servlets

• Internal objects

The important point is that each of these client types has a different set of requirements when it comes to establishing a connection to the database. An application is the easiest type of client to connect. That’s because it has liberal access to operating-system resources; you typically just make a connection when you start your program and then close it before you exit. An applet, on the other hand, has to live with security, life cycle, and routing restrictions. A servlet has life cycle and possible shared connection issues, and an internal client such as EJB or a stored procedure has security issues.

It’s common for programmers to have problems establishing a JDBC connection to an Oracle database. Consequently, I’ll discuss each type of client’s requirements separately, and in detail, in the chapters that follow. This should get you started on the right foot. Chapter 2 covers most of the general knowledge you’ll need, so even if you’re interested only in connecting from applets, servlets, or internally from Java stored procedures, read Chapter 2 first.