NCA is essentially a 3-tier distributed processing architecture defined by open standards and built upon Oracle’s server products. The user interface is logically and physically separate from the application logic, which is run on a “middle-tier” application server.

Before you explore each platform, here are a few general attributes of the 3-tier model, shown in Figure 3.9:

•  The client can be any device, rather than just a PC. Anything that can, at minimum, render HTML can be a network computing client. The client can even be a mobile device.

•  Clients use either HTTP or IIOP (the CORBA standard protocol), rather than a proprietary client/server protocol, depending on whether they require lightweight or session connectivity.

•  Application logic is moved to the middle tier. The middle tier can be either a Web server or an application server. The middle tier provides an abstraction layer for data and system services.

•  In addition to the RDBMS, existing systems, TP Monitors, messaging systems, and so forth can be incorporated.

Figure 3.9.  General NCA architecture.

As NCA is based on component technology; each of the three tiers provides a framework for application-specific components and access to common services and facilities.

As shown in Figure 3.10, application-specific logic is programmed as components, and the runtime infrastructure is supplied by the server platforms. Common services are factored out of each application—they are provided through a common interface for all applications.

Figure 3.10.  NCA platforms support application components and access to common services.

Next, we’ll discuss each of the three tiers.

Client

The role of the client tier is to render a nice user interface, be responsive, and be easy to learn and easy to use. The ideal client UI would give useful indications and feedback, get updates automatically, save changes when offline, protect the work until it is safe, and be available anywhere.

As shown in Figure 3.11, there are various capabilities that may be implemented by any given client device.

Figure 3.11.  Capabilities in the client tier.

Any device that can render HTML can potentially be a (limited) NCA client. However, to support Oracle’s Developer/2000 server or any other 3-tier application, the device will also require the Java Runtime Environment.

Future applications will likely rely on a CORBA ORB for communications and may use XML as a format for data interchange. Today, the Borland/Visigenic ORB is bundled with Netscape Communicator.

For mobile clients, Oracle offers Oracle Lite 3.0, which provides a Java-enabled object database that can be used to cache a user’s data. Oracle Lite 3.0 runs in only 350KB of memory and is being ported to several handheld devices. If you can spare another 300KB, Oracle Lite can provide you with a full SQL parser and bidirectional replication with an Oracle8 Enterprise Server.

Oracle also has a 2-tier solution for Java applets that need to connect to the Oracle8 database. The ThinNet8 driver is an implementation of the Java Database Connectivity (JDBC) API that emulates portions of Oracle’s Net8 protocol, written entirely in Java. This enables downloaded applets to connect to Oracle8, with no requirement that software be installed on the client.

To improve memory utilization and response time of the server, ThinNet8 applets can connect to the Oracle8 Connection Manager instead of connecting directly to the database. As shown in Figure 3.12, the Oracle8 Connection Manager can multiplex the incoming user connections to the Oracle8 server.

Figure 3.12.  Java applets being multiplexed to Oracle8.

Application Server

The role of the Web/Application Server tier is to run application code and abstract common services. The ideal application server would run application components fast and support lots of users in a safe, secure, and manageable way.

The Oracle Application Server (OAS) is actually two servers in one.

As a Web server, (as shown in the top half of Figure 3.13) it provides all the normal functions, including virtual path management, CGI, and realm-based security. But it goes beyond traditional servers by providing an ORB-based architecture for running Web programs. Any URL that does not request a static page or CGI program is directed to the Web Request Broker (WRB). The WRB manages the startup and shutdown of cartridges that run Web programs written in Java, PL/SQL, C, or Perl. The PL/SQL cartridge is particularly good at dynamically creating Web pages based on data in the database and is very effective for creating simple Web-based applications.

Figure 3.13.  Oracle application server.

As an application server, (shown in the bottom half of Figure 3.13) OAS provides an industry-standard container for Enterprise JavaBeans and provides access to high-quality implementations of common services such as transactions, naming, security, and so forth.

Because many developers are not yet experts in CORBA and component models such as Enterprise JavaBeans, Oracle has extended the cartridge concept to include support for Java-CORBA server components. Oracle provides tools that take an ordinary Java class, package it into a “cartridge” so that it can be managed (instantiated, load balanced, and so forth), and install it into the application server. This makes it really easy to create new server-side components. Client applications access the components as if they were local objects.

All the various internal processes of the OAS (such as the resource manager, dispatcher, virtual path manager, logger, and so forth) communicate using CORBA. This means that they can be placed on separate physical machines if needed to increase capacity of the server. In this manner it is possible to create “cartridge farms,” a machine dedicated to running a particular set of application objects.

Database Server

The role of the Database Server is to provide very fast access to large amounts of data, respond to huge numbers of concurrent requests, never lose anything, keep it secure, and provide powerful development and administrative facilities.