1267-1270

Previous Table of Contents Next

Page 1267

Figure 55.15.
The Openlink
combined middleware
concept.

Other standards are out there competing in the middleware market. Several vendors in the UNIX and Apple worlds favor different standards that are similar to ODBC and OLE. Each touts the benefits of its framework over the others. If you spend a lot of time working in one of these environments, you might want to consider these competing standards. If you primarily use PCs as clients , though, ODBC and OLE are the two standards you will encounter the most. I view it as though I am living with the standards set by the industry and not making them. If a standard is adopted by the rest of the computer industry, it does not matter how many wonderful features the competitors have; they probably will fade away due to lack of sales in a few years . The only difficulty you face is figuring out where this fickle industry is headed.

Sample Configurations

So far in this chapter, you've looked at most of the networking topics you probably need to consider as a developer or user of a networked Oracle system. What is missing is that one single drawing that shows you all the pieces you need to buy for this networked Oracle system. I can't provide that drawing because, as I mentioned earlier, there are too many different options. You now can use Oracle development tools with non-Oracle databases and vice versa. This section shows you a series of sample configurations to give you some idea of what working networked database configurations look like.

CAUTION

You have to look at each type of system configuration on an individual basis. So many unusual reactions occur between different versions of various products that you really should test things in your environment before you can be certain that they will work. Things might occur that you might not anticipate ”for example, none of the WAN transmission equipment in your company is capable of transmitting the TCP/IP protocol or something equally strange . Be sure to test everything using demonstration software, or limited quantities whenever possible, before you commit to rewriting your entire application architecture using a given set of products.

Page 1268

Now take a look at the first sample configuration. Because this discussion began with the topic of network access to databases with the host/terminal architecture, the first example is of this environment. (See Figure 55.16.) Note that, even though I use PCs to access the VAX Oracle database, they are emulating dumb, non-graphical terminals. The applications developed use the traditional, character-based interface in which you press F3 to commit your changes or F4 to exit from where you are. Note that all the application development software and completed applications reside on the Oracle server (in this case, a VAX) and that the links from the application to the DBMS already are set up (you do not need to configure any links as you would in SQL*Net).

Figure 55.16.
A host/terminal
example.

Figure 55.17 shows a basic client/server system. In this case, the Oracle tools set (which now goes by names such as Developer/2000 and Oracle Forms, but who knows what the marketing folks will call it next year) is shown on PCs interfacing with an Oracle database on a UNIX server. With this architecture, you do not have to use an upper middleware product on your clients (these tools are designed to interface directly with SQL*Net). Oracle tools recently have begun to also support an ODBC interface. Apparently, Oracle wants to sell its development tools even to customers who use other DBMSs.

Figure 55.17.
Oracle development
tools interfacing with
an Oracle database.

Page 1269

Figure 55.18 shows a system that uses upper middleware ”in this case, ODBC ”to interface with an Oracle database located on a Windows NT server. This environment uses the Microsoft C++ compiler with a set of third-party ODBC drivers from Intersolv. The database is Oracle 7.1, and it is located on a Windows NT server. You must ensure that your ODBC driver is compatible with the exact version of the networking software you are using (you might have trouble, for example, if you move your application to Windows 95). Also, when using a development tool such as C++, you must be sensitive to details such as the datatypes the ODBC driver is returning to your application (it does not map to character, VARCHAR, and NUMBER, as in the Oracle database). This detail work can take some time, so you might want to run some tests up front to figure out the calls and returns with which you will be dealing.

Figure 55.18.
An ODBC environ-
ment.

Finally, I thought it'd be useful to include an example of a distributed database environment. I have not encountered a large number of these configurations, but that could change in the future as gateway and distributed database processing technology continues to improve. Figure 55.19 illustrates one such system. The basic concept behind this system is that the two databases (perhaps one in Cleveland and the other in Chicago) are linked together. Users interact with their local database and let the Distributed option take care of ensuring that the remote database is updated. Delays in the transmission of the database between the systems do not delay the user's processing.

Figure 55.19.
A distributed database
environment.

Page 1270

Network Development Tips

This section summarizes some of my experiences dealing with networked database environments in a series of tips. Think of this information as highly condensed examples. At least consider the following directions:

• Do not cheat and try to implement the production environment late in the development cycle. It is tempting to say that you will develop everything on a stand-alone workstation and then convert it to the client/server environment the week before testing (you certainly can get it working in a week, right?).
  I like to spend the time getting the true working environment set up in the beginning for several reasons. First, I might find that some of my drivers and products are incompatible. I might have to troubleshoot and then order replacement products, which can take an amazing amount of time. Also, my developers need immediate feedback during development when they write software that is not optimized for the end-user environment. Imagine a piece of code that pulls down to the PC all the data from a very large table (with lots of long text fields) located on the server just to calculate the sum of a single number field. This code would be extremely slow over a busy network. The developer could use a built-in Oracle sum function and only have to return a few bytes of data with the result.
• Do not deviate from common computer environments and tools (this is an example of a recommendation that I do not always practice myself ). I like to live on the bleeding edge of technology, but that makes it extremely challenging to get those production applications out on time. Incompatibilities of drivers and tools with new operating systems such as Windows 95 require that you have a fair amount of experience dealing with lower-level system details and a wide range of access to vendors. In an ideal world, you would have a lab environment in which you could test and get new products working and then use them in your production and development environments.
• Know about your network monitoring and testing utilities. Many errors, especially those in the client/server environment, translate into something similar to "There is something, somewhere, that is not right." I hate those error messages but must live with them. What you then do is use some of the low-level testing utilities to go step by step through the system to see where the problem lies.
  If I am setting up a C++/ODBC-to-UNIX database via a TCP/IP environment and encounter a problem, for example, I have to use several utilities to test the connection. I typically start by using the ping utility common to most TCP/IP environments to ensure that I have basic networking connectivity between the two computers. I then use Oracle Net Ping to see whether my two SQL*Net processes are communicating with one another. Next, I use an easy ODBC access tool such as Microsoft Query to see whether I set up my ODBC configuration correctly. Finally, I create a new Visual

Previous Table of Contents Next