Web Request Broker’s InterCartridge Exchange (ICX)

The InterCartridge Exchange is a service of the Web Request Broker that allows one cartridge to call on services in another cartridge. In other words, an application written in one language can, through the ICX, use the services of another cartridge without any knowledge of that called cartridge’s language.

For example, say you’ve written an application in PL/SQL that needs to access another database via ODBC. Your PL/SQL code can contain a call to the ODBC service, using the Oracle provided packaged procedures called utl_http.request and utl_http.request_pieces for use with the PL/SQL cartridge. These procedures let your application send a request to an ODBC service, and get responses back.

The ICX is modeled after HTTP. Requests via the ICX act like HTTP, and appear the same as an incoming HTTP request to the called cartridge, regardless of whether the calling cartridge is on the same node as the called cartridge, or across the network in a distributed configuration. And ICX allows any cartridge to make calls to any other cartridge, regardless of the languages involved.

Accessing Non-Oracle Databases

The first tier in the Network Computing Architecture model is the universal data server, which does not necessarily mean an Oracle database. The WAS has several mechanisms by which you can access data sources other than Oracle:

•  ODBC and OCI cartridges, described in the previous section “Cartridges,” include two methods by which any cartridge can access non-Oracle data sources.

•  Java developers can use Java’s JDBC classes. Java Database Connectivity (JDBC) is a Java API to SQL databases. It consists of a set of Java classes that can access any SQL database. Applications written in the WAS Java cartridge can use JDBC as an alternative to the ODBC cartridge for accessing a non-Oracle database.

•  Oracle offers a feature known as Transparent Gateways (TG), which can integrate WAS with a large number of common database sources, such as Sybase, Informix, and other products. Through TG, any SQL*Net-compatible tool can access these other RDBMSs, even allowing for queries that join Oracle tables with non-Oracle tables. Oracle also offers Procedural Gateways that enable you to use non-Oracle transaction procedures as though they were stored procedures in the Oracle database. Finally, the Gateway Toolkit empowers developers to create their own gateways for all Windows NT ODBC-compliant RDBMSs. Note that the Oracle Gateways are a separate Oracle product and are not bundled with the WAS.

Web Security

Security is one of the most important issues with any Web application, more so than with traditional client-server systems. Since anything on a network is inherently more accessible, the probability of attempted hacks to a system is higher. But more significantly, the stateless nature of Web sessions, while providing significant benefits, also introduces some security questions that must be addressed before any serious application deployment can take place.

WAS provides a number of features to assist with the prevention of unauthorized access to your application.

User Authentication

The WAS offers several options for user authentication. One approach is to create user names and passwords that reside in the WAS, in other words, that you create through the WAS Administrator, and that are stored in files with the Web server. The passwords are encrypted in a similar manner as the Oracle database passwords, but the user names are not in the database.

When setting up these user names and passwords, you must choose between two options: Basic authentication, or Digest authentication. From the user’s point of view, there’s no difference between the two. The difference is in how the passwords are transmitted from client to server. When the user enters a password using Basic Authentication, the password is encoded in Base64 format, and transmitted to the server. Under Digest authentication, the password itself is not sent, but an MD5 checksum is sent instead. The advantage: it’s impossible to decipher the MD5 checksum. When the server receives the checksum, it can tell that the client must know the password without receiving the actual password.

Instead of configuring usernames and passwords through the WAS, another approach is to use Oracle schema names (user names). This is a new feature with WAS 3.0, believe it or not, and to appreciate why, it’s important to understand how the WAS is configured. When a new cartridge is set up in the WAS, a Database Access Descriptor (DAD) must be created. This is a set of instructions telling the cartridge how to access its data source. For example, when setting up a PL/SQL cartridge, you must define that cartridge’s database access. The DAD is given one associated user name in the database—that’s one—to service all incoming client requests. In previous versions of the WAS, this meant that the entire collection of users accessing that cartridge was seen as one (probably really busy) user to the database. To provide any sort of database user names and passwords meant that the application developer had to develop and manage user names and passwords themselves. Oracle user names (schemas) could not be used.

This changed with WAS 3.0, which allows for either option. When creating a DAD in WAS 3.0, if you just leave the user name and password blank during the configuration process, users who log in to the application will be prompted by the listener to enter an Oracle user name and password. Also, any roles you may have set up for that user account will function for the user’s login session.

The WAS also provides methods that allow you to work with the physical IP address from which a user is accessing the system. Every user on the network is associated with a physical address. By telling the WAS to, for example, only accept incoming requests from a given IP address, you effectively prevent any unauthorized access from anywhere else. You could also work the other way—allow access from anywhere except for one particularly troublesome IP address, one from which you know you’ve had attempted hacks in the past. This is possible, but not very effective, since a hacker can just try from somewhere else. But both options exist, and the first is very effective if your application’s user requirements will allow for it.