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.
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
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: