1259-1261

Previous Table of Contents Next

Page 1259

SQL*Net 1

Now that you have looked at the general concepts of database networking, it is time to get into some specifics. A good place to start is with SQL*Net 1, which was the first product in the Oracle environment to support networking. A great big warning is in order at this point: SQL*Net 1 is no longer supported by Oracle. I considered dropping this section on version 1; however, I have run across a number of computer environments that do not upgrade every time Oracle comes out with a new product. These environments still use older tools that are adequate for their needs, so a discussion of SQL*Net 1 might be useful to you if you are working in these environments. Designed to support client/server computing and database links, SQL*Net 1 was a good start on this process and was fairly reliable.

WARNING

SQL*Net 1 no longer is supported by Oracle.

SQL*Net is a product that I classify as lower middleware. It does not alter the format of the query to comply with Oracle standards or to handle the details of transferring the results into a format the applications can handle. Instead, SQL*Net sends and receives data in the format it understands and lets other middleware or the applications themselves get that information into its format. Some applications are designed to interface directly with SQL*Net. Oracle's SQL*Plus DBMS, Oracle Forms, and its other development tools are designed to interface directly with SQL*Net. You can develop applications using Oracle's precompilers and products, such as Oracle Objects for OLE, that interface directly with SQL*Net. Figure 55.10 shows this direct interface.

Figure 55.10.
Products interfacing
directly with SQL*Net.

You might have noticed in the last paragraph that the word Oracle preceded most of the products I listed. Although third-party products are available that are designed to interface directly with SQL*Net (such big names as PowerBuilder), many other developers yearned for an open

Page 1260

standard that would enable them to write one application that could interface with a number of middleware packages and DBMSs. This is how the products I call upper middleware were born.

The basic concept is simple: Design a product that has a neutral, published interface from applications and then design a neutral interface and connection software for a variety of lower middleware transport protocols. Figure 55.11 illustrates this concept. One of the ways you can tell a good idea in the computer industry is when every big company jumps on an issue and creates its own "industry standard" to implement the concept. Such is the case with what I call upper middleware.

Figure 55.11.
Upper middleware
interfacing with
SQL*Net.

The biggest name in this market that I have encountered in my experience is Microsoft and the ODBC standard. It has the advantage of being able to access a large number of clients (PCs that run Microsoft Windows, Windows NT, or Windows 95). ODBC also came out early in the client/server evolution process, so a number of applications already are written with this standard. Finally, Microsoft provides a series of drivers and utilities with most of the operating systems delivered, so you can keep the cost of an installation down (you would be amazed at how fast the cost of a client workstation can go up when you start buying a large number of "optional" packages).

This is not to say that Microsoft is the only upper middleware vendor on the market. A number of vendors , such as Intersolv and Openlink, have worked to produce drivers that are faster than the standard ODBC drivers or that work with more DBMSs. Once again, you are faced with a number of choices. One is a low-cost solution; the others might provide improved performance. Still others, such as Openlink, merge the functionality of SQL*Net with an ODBC driver to reduce the number of middleware products you need to install and maintain. Finally, you have to consider the range of Java database connectivity (JDBC) middleware packages designed to connect applications written in the Java programming environment to databases. For the purposes of this discussion, you can consider these packages to be similar to ODBC.

Page 1261

One final note about middleware: Just when you were confused enough with the various options related to ODBC, Microsoft throws in another wrinkle. It incorporated the concept of upper middleware into a structure that enables you to dynamically share data between applications and even launch one application from within another. This standard is called object linking and embedding (OLE). (I discuss the differences between ODBC and OLE in the section titled "ODBC, JDBC, and OLE," later in this chapter.) For now, you should understand SQL*Net as a lower middleware product and how it interfaces directly to SQL*Net-ready applications, such as SQL*Plus, or the Oracle DBMS and upper middleware products, such as Microsoft's ODBC.

Next on the agenda is an examination of the way in which SQL*Net is implemented. Once again, more than one answer exists. Remember that part of the sales appeal of Oracle is that it works on a wide variety of computer systems and is designed to do many things. For this review of SQL*Net, I have split the topic of implementation into two separate discussions. The first analysis involves SQL*Net on computers (such as UNIX or VAX VMS) that run multiple processes at the same time. The other topic covers SQL*Net on computers that basically are single tasking (such as Microsoft DOS and Windows 3.1).

On multitasking computers (those running multiple processes), Oracle SQL*Net 1 is implemented as a listener process. Listener is a good name for this process. It merely sits there in the background and listens for someone to send a signal to it. This signal could come from the remote machine, in which case it picks up the signal from its interface to the network transmission protocol, or from the local application or database. When SQL*Net is connected to the database, it creates a server process or uses a process that has already been created to handle the interface to the DBMS and merely passes signals between this database interface process and the network drivers. Figure 55.12 illustrates the basics of this configuration.

Figure 55.12.
SQL*Net 1 imple-
mented as a server
process.

Microsoft Windows 3.1 and DOS do not support multiple background processes. As a result, Oracle had to adapt its SQL*Net 1 product to fit within this environment. The problem is that memory is usually in short supply on PC clients, so you do not want to waste memory space by permanently loading the SQL*Net drivers. To get around this problem, Oracle uses a dynamic link library (DLL). The software is loaded into memory when needed to facilitate communication between the applications and the network protocol drivers. This method actually can be more convenient because you do not have to worry about starting and stopping the background SQL*Net listener process under this architecture. Figure 55.13 illustrates the SQL*Net DLL concept under Microsoft Windows 3.1.

Previous Table of Contents Next