1256-1258
Page 1256
Internet Information Server, function as separate applications and use middleware such as ODBC and SQL*Net to exchange information with the database.
Many books exist on the sole subject of Web access to information stored in Oracle and other databases; covering that topic here is beyond the scope of this chapter. I do want to mention one other subject before I leave this section, though: the Network Computer. The senior management at Oracle and several other companies have been touting the Network Computer as the revolution that will completely change the information systems environment in the future. The Network Computer (or NC, as you often will see it) is essentially the dumb terminal (or, better still, the X terminalfor those familiar with the UNIX environment) for the Web era. The basic premise of the Network Computer is that purchasing, installing, and maintaining complex personal computers for a large number of usersmany of whom have very limited computer processing needscan be very expensive for companies. Many order-entry people spend all day accessing a single application that they use to enter a few screens' worth of data into the order-entry system, for example.
The network computer is designed to be less expensive to purchase (although early models still are priced comparably to some PCs). The big advantages come after installation, though. Basically, you sit the Network Computer on your desktop, connect it to the network, and provide a Web server from which it can download all its information and programs. This feature enables you to limit your software configuration work to those few Web servers instead of a large number of workstations. Time will tell whether this initiative to simplify the maintenance of PCs or a similar one in the PC vendor community will win the battle. I do not ever want to give up my PC; however, many users would prefer a simple terminal that they cannot mess up. The Web environment and perhaps the Network Computer are subjects you might want to consider when developing applications.
Database-to-Database Connections
A logical extension of the concept of using multiple computers to perform the work of an application is using multiple servers to support the overall database-processing capabilities for a large organization. For Oracle, these capabilities came in three phases. In the first phase, Oracle used SQL*Net (or Net/3) to enable users to access data in tables in a remote database through a database link. Figure 55.8 shows the general concept of the database link. Here, you tell Oracle to "get me all the rows in table x, which is located in database y, that meet my criteria." You issue a command (create database link), which creates a simple alias (such as marketing) for the database to which the users refer. The create database link command captures all the details of the connection (addresses, user ID and password to connect with, and so on) and stores them for use when the users request this connection. One of the drawbacks of this capability is that a database link connects you to the remote database with whatever user ID and
Page 1257
password are specified in the create database link command. The user accesses the data with the privileges of this user ID and not the ID of the user who is issuing the query or sending the transaction (which could cause security problems).
Figure 55.8.
Database links.
Overall, this first phase was a good start on splitting up the database processing workload; however, other issues soon became apparent. The biggest issue was that remote locations usually had to rely on a relatively slow wide area network (WAN) communications link to access a database located on a centralized server. Another factor was that programmers had to be aware of all the database links and put them into the SQL statements they issued.
The next generation of database-to-database connectivity came with Oracle's Distributed Database option (option means that you had to pay extra for it). If you had remote field offices connected to the central office by relatively slow communications lines, you could implement smaller servers in the field that receive a nightly download of data from the central server. You then would write batch routines that run at night, figure out which records need to be downloaded, and so on. You could do these things yourself, but it is much easier if the DBMS takes care of these tasks for you. That is the idea behind the Distributed Database option.
Such a system has two general features. First, you can access tables located on remote databases as easily as you access tables located on the disks attached to your local server. Second, if you have multiple copies of the data to speed up processing at remote sites, you can set up the system so that Oracle synchronizes the data between the systems. Actually, quite a bit of logic goes into ensuring that if you make a change in a particular record, it is applied to all the copies of the database especially when some of the changes might take minutes or even hours to finish. It is much easier to put that burden on Oracle instead of coding it into your application. There isn't a huge number of installations out there using this option, but it could be very useful in certain cases. Figure 55.9 illustrates the Oracle Distributed Database concepts.
Page 1258
Figure 55.9.
The Oracle Distributed
Database option.
Suppose that you have linked multiple Oracle databases located on different servers to distribute the database processing load of your organization. What more can you ask for? You now have the capability to take advantage of the large number of PCs sitting on people's desks, you can have multiple servers (located wherever you need them in your WAN) performing the database management tasks, and you can even use a three- tier client/server architecture to distribute complex computational loads to a different server. Well, there is one other possibility that Oracle sales representatives usually do not like to consider. What if you have a lot of data on DB2 that you do not want to convert to Oracle, or what if you have a subsidiary or business partner who has adopted VAX RDB as his standard DBMS?
The answer to this question comes in the form of gateways. Oracle makes a series of gateways that link Oracle databases to DB2 and other major database products. It seems reasonable that Oracle will continue to work in this area to increase the number of gateways to other vendors ' databases. The key to these gateways is that they are similar conceptually to the Distributed option. All you (or your DBA and system administrator) have to do is install this gateway product and provide all the configuration information about where the data is stored, what format it is in, how you network into the database, and so on. The gateway software then takes care of the details whenever your applications issue a query or transaction that affects data in these remote databases. As with many of the networking products discussed in this chapter, the gateways are not for everyone, but they can be a big help to those who need them.
Just for the record, many of the other database vendors and third-party developers have gateways that connect to Oracle databases. They have seen the same market opportunities to sell software to organizations that are not planning to convert all their databases to Oracle systems. The key to choosing the correct gateway is to ensure that it supports the versions of the databases you are using and that it fits into your computer and network architecture. These gateways are relatively new products, and I suggest that you check with other customers who are using the products or perhaps even set up a test system in your organization before you commit to purchasing the gateway as the ultimate solution to all your problems.
EAN: 2147483647
Pages: 391