Oracle’s Big Gamble

Whether you call it “NCA” or “Web-based distributed computing,” Oracle is betting its entire product line that organizations are ready to develop for the Internet rather than the operating system

Does the Internet offer a better architecture than classical, two-tier client/server? Oracle is betting on it. Larry Ellison and his troops are hoping to give application developers end-to-end Java solutions conceived from the ground up in conjunction with the Web. They’re hoping their efforts will reduce costs in a distributed environment and improve system performance.

It just might work. You can capture the rather dramatic improvements in performance and cost made possible today by Internet technology without sacrificing your previous investments in legacy applications. In fact, Oracle’s latest wave of new or upgraded products interoperate in a various ways with databases, transaction servers, and ORBs from competing vendors.

Network computing will not completely replace mainframe or client/server, just as client/server architectures didn’t completely replace mainframe ones. Instead, think of it as another tool in your toolbox that will fit many—but not all—needs. Oracle8i (formerly Oracle8.1 and renamed presumably for a better Internet tie-in), one of the keystones of the Network Computing Architecture (NCA), adds many new features to implement better two-tier architectures.

This feature presents a good deal of information about some of the latest new or upgraded NCA products but goes to press before their scheduled releases in late 1998. Beyond the scope of this article are many other new features such as Extensible Markup Language (XML)—supported in both Oracle8i and its new Internet File System (iFS) utility — that expand the ability to manage nonrelational data files in the database.

What’s New with NCA

Oracle’s NCA seeks the same objective as proprietary client/server but offers a simpler, standards-based architecture. The key is shifting the business logic off the individual client machines (where it is so difficult and expensive to manage) into one (or a rational number of) middle-tier application server, where it can be professionally managed. NCA also provides a common set of integrated services (transactions, security, and directory) on every tier of its architecture that lets it achieve all the benefits of client/server with less development, deployment, and operational complexity. (See Figure 1.) The basic, three-tier system can also be expanded horizontally by adding different Oracle Application Server (OAS) components and heterogeneous data stores. (See Figure 2.)

FIGURE 1. Overview of Oracle’s new Java-centric architecture for distributed computing.

FIGURE 2 Integrated Oracle Application Server 4.0 and Oracle8i system.

Using another new NCA feature, you can now deploy a single component model—Java—on all tiers. Instead of maintaining groups and subgroups of programmers with each specializing in a different language (all of which have impedance mismatches to the others), you can develop distributed applications with a single language — one that Oracle has integrated highly with SQL.

We’ll use the marketing-inspired term “NCA” throughout this feature, but it may not endure; not everybody likes it. Ellison has said that attempting to “brand” open Internet computing was a mistake; the company is now considering replacing the term with “Oracle Internet Computing.” Whatever the outcome, you shouldn’t confuse Oracle’s second thoughts about this marketing term with any lack of commitment to the underlying technology in Oracle’s Java-centric Web model for distributed computing. As an example of that commitment, the new multithreaded Java Virtual Machine (JVM) in Oracle8i goes well beyond any traditional single-user, client-side JVM in scalability and robustness. (It will, for example, scale to support tens of thousands of users — but don’t try this at home with your 450Mhz Pentium II.) The Oracle JVM is also 100-percent compatible with JavaSoft’s JVM.

Oracle’s Internet Linchpin

A combination of several components, OAS 4.0 gives you application logic and communication between clients and its application logic. It manages the creation of application logic, as well as communication between clients and this application logic, among multiple instances of this application logic, and among this application logic and one or more data sources. In addition to providing an environment for executing programs, OAS 4.0 offers services that simplify the process of writing Web applications in multiple languages. Java is the one to focus on.

As you can see in Figure 1, two kinds of clients can use Oracle Application Server: Web browsers, which use the HTTP communication protocol; and Java applets, which run within Web browsers equipped with client ORBs that communicate with the OAS ORB using IIOP. We’ll focus on the latter. (Unknown to many, the Netscape Navigator browser — not Microsoft Internet Explorer — includes a CORBA 2.0 ORB.) And because OAS 4.0 exposes its CORBA 2.0 ORB to the outside world, you can create open standard CORBA components that work with OAS 4.0 via the open standard IDL. DCOM clients can also access these applications across a DCOM/ CORBA bridge.

Like Oracle8i, OAS 4.0 Enterprise Edition introduces two complementary component paradigms: Enterprise JavaBeans (EJBs) and 100-percent Java CORBA objects. A major difference between Oracle 8.i and OAS 4.0 is that you can build CORBA applications on Inprise’s VisiBroker ORB with the former. You have to provide (often manually) the code to build the infrastructure for an individual application. In contrast, OAS 4.0 offers Oracle’s own ORB and an incredibly simplified mechanism for creating and deploying your CORBA objects; Oracle calls them JCORBA objects (JCO). If you use JCO, you don’t have to know the complexities of CORBA at all, just Java. Developing CORBA objects in Java is much simpler because JCO gives you a robust environment by leveraging the OAS 4.0 infrastructure. At first, the nascent JCORBA and even the newer EJB will run side-by-side; eventually, Oracle will provide a migration path between them.

You can scale a single OAS 4.0 to the demands of your application, or you can add more servers to handle growing use. OAS’s management console works as though it were conceived by a cost accountant. For example, before throwing more money (hosts) at your system to handle increasing demand, you can use OAS’s management GUI to allocate load among a distributed installation in an administrator-configurable way — thereby ensuring that no available capacity goes unused. One scheme is to assign percentages of user requests to individual instances of a particular application for each node. Alternatively, you can rely on resource use at runtime; that is, put the next application instance on the “most free” node based on CPU or memory use.

It’s worth mentioning that Microsoft Transaction Server 2.0 (MTS)—a competitor of OAS—has the static but not the dynamic load balancing we’ve described; it also depends exclusively on Internet Information Server (IIS) and Windows NT. As a result, MTS simply lacks the flexibility and scalability of Oracle products. It’s also notable that we frequently use IIS instead of OAS 4.0’s native Apache HTTP daemon during the development process. This approach avoids the frustratingly long waits required to get OAS 4.0 to relinquish its locks on middle-tier files we want to open and change. We do, however, use Oracle’s own Web server in production.

Object/Relational Options with Oracle8i

Up to the release of Oracle8, business objects on the application side of an Oracle system had to interact with normalized relational tables to retrieve and process information. But Oracle8 is an object/ relational database, letting data architects model the client-side business objects as object types in the database while keeping the data within a relational framework. In this manner, you can use SQL (and PL/SQL) to manipulate relational as well as object data. What makes Oracle’s object/relational technology appealing is that it can be implemented in an evolutionary rather than revolutionary transition. You won’t lose your investment in relational applications.

A word of caution: We initially found we had to spend a great deal of time planing our object data models in order to get them right the first time. That’s because the job of introducing changes to these databases when we had everything up and running was sometimes daunting. We overcame this shortcoming by turning to the forward/reverse engineering and other features of a new tool for visually modeling Oracle8i schema objects, Rational Rose 98 Enterprise Edition.

Oracle8i provides tight integration between Java and SQL. For now, you can work with either relational or object database tables or both, code in either Java, SQL, or both, and choose whether to use Java-written EJBs or CORBA components—or both. With all these options, your system can evolve as gradually or as rapidly as you wish.

Complementary CORBA

Oracle 8i introduces two complementary component paradigms: CORBA servers implemented in Java and EJBs. You can think of CORBA as complementing EJB or as a stepping stone to EJB. By providing both options, NCA lets you move forward with its new Java-based technologies without having to scrap your prior models.

CORBA separates interface from implementation and provides language-neutral data types that make it possible to call objects across language, network, and operating system boundaries. Encapsulating existing applications is easy with separation; you can make your existing code look like an object on the ORB.

Although CORBA is a widely supported technology, it isn’t for everyone. For one thing, it doesn’t define a server-side component coordinator framework. It also doesn’t have a fully completed, server-side component model. EJBs, on the other hand, start where CORBA leaves off. EJB augments CORBA by defining the interfaces between a server-side component (or bean) and its container. Server components are managed beans that run on a server. The container acts as a component coordinator and uses a standard JAR (Java archive) package to import EJBs from tools and other containers. When an EJB is inside its container, it can be managed in a scalable way using transactions, state management, and automatic activation and deactivation.

The beauty of the EJB framework is that you can declaratively define most of your server-side, runtime attributes. You can administer and set the properties of your server-side components with visual tools such as Oracle’s JDeveloper, a version of Inprise’s JBuilder for NCA. These properties include the company’s transactional, security, and state management policies. In other words, advanced systems programming skills aren’t required because of EJB’s high level of abstraction.

You can specify transactional operations such as COMMIT or ROLLBACK declaratively with EJB’s transactional model. When methods of the bean are executed, they happen automatically. In addition, EJBs are portable across a range of JVMs. For example, you might want to relocate a particular bean from Oracle8i to OAS 4.0 Enterprise Edition, or even Lotus Domino 5.0. While EJBs do not require foreign IDLs, they are compatible bidirectionally with a range of communication infrastructures, including CORBA and DCOM.

A transparent propagation of an EJB transaction exists across multiple hosts. (See Figure 3.) You can declare transaction attributes to let EJB containers automatically manage the propagation of transactions on your behalf without writing any code. EJBs are standard Java applications, and the various elements the JVM provides to make Java execution fast (RDBMS integration and NComp, the native Java compiler) also benefit EJBs. Because EJBs access the persistent state in the RDBMS through the embedded JDBC driver, SQL data access is very efficient from EJBs deployed on Oracle8i. This scenario provides an ideal EJB server platform for data intensive EJBs.

Oracle 8i provides a highly scalable EJB server in two ways: First, because EJBs are standard Java applications, they can exploit the JVM’s shared memory optimizations to achieve scalability to thousands of concurrent clients. Second, immutable portions of the EJB, including its metadata and initial prototype, are placed in shared memory only once and then shared across all EJB instances. It doesn’t matter how many instances are running concurrently.

There’s more to the story about tight integration of Java and SQL in this object/ relational DBMS. You can now write a Java stored program and store it in Oracle 8i. You load the program into the database server either from a client-side development tool or some other Java source. Then, you compile the loaded program using the database’s embedded bytecode compiler or NComp, and execute it on the JVM. NComp will generally yield higher performance than today’s just-in-time (JIT) alternatives. Without NComp, you’d have to put additional hardware resources on your machine in order to maintain performance when user demand increases.

Now, Java subprograms can be called from SQL either as top-level stored procedures, triggers, or functions, or as Java methods of Oracle8i object/relational types. Conversely, Java applications can call SQL via the JDBC driver implemented in the server.

FIGURE 3 Transparent propagation of an EJB transaction.

A Look at the Client/Server Sides

Being a vendor-independent library, JavaSoft’s JDBC only provides access to standard SQL types and doesn’t support the Oracle-specific types such as ROWID, binary large objects (BLOBs), or user-defined object types and collections. However, JDBC was designed with extensibility in mind and, as you might guess, support for BLOBs, Oracle8 object types, and REFs are featured in 8i.

Because OAS 4.0 and Oracle 8i include the same database connectivity options, you have an additional level of flexibility as to where to put your application logic. The server-side driver integrated with the database deserves special attention.

Java applications executing on the JVM within Oracle 8i communicate with the SQL and PL/SQL engine within the database via the new JDBC driver. Because the entire JVM executes in the same address space as the database and the SQL and PL/SQL engine, when JDBC calls occur within the server, the JDBC driver performs a local, in-process call to access SQL. This approach is an alternative to executing a remote Net8 call to access SQL. Obviously, this process is very efficient, and performance of Java code-making JDBC calls within the Oracle server will further improve Java application performance with the Oracle database.

In addition to offering greater performance, Oracle designed its server-side JDBC driver to be consistent with its client-side drivers. (“Client” in this context can also include OAS.) The server-side driver supports the same features and Oracle extensions as the ones with exactly the same APIs. This makes application partitioning for the Java programmer simple; you can easily move data-intensive Java code into the database server for better performance without modifying parts of your Java application. The tight integration of Oracle’s JDBC drivers and object type extensions gives you the ability to access composite data structure defined in SQL from your Java applications.

SQL Java (SQLJ) provides another means by which Java programmers may access relational data. JDBC is a call-level library interface that can’t exploit RDBMS schema information at compile time. It is relatively low level and can be tedious for simple static SQL access. On the other hand, SQLJ enhances the capabilities of JDBC by providing Java with compile-time access to the RDBMS schema, greatly simplifying code and offering type safety and higher performance. SQLJ is specified as a straightforward, seamless integration of SQL and Java.

Centralizing Application Management

OAS and Oracle8i will also provide a centralized facility with which to manage component-oriented applications through the LDAP v.3-compliant Oracle Directory Server. (Don’t presume, however, that replication between LDAP v.3 directories and different vendors can be achieved. Test it first.)

You can use the Oracle Directory Server to centralize the administration of users, security, and distributed objects, significantly lowering your cost of administration in a distributed environment. For example, CORBA servers and EJBs implemented in Java can be registered with the Oracle Directory via standard Java Naming and Directory Interface (JNDI) interfaces. A tool is planned to integrate and automate the process of publishing a CORBA server or EJB to the Oracle Directory. CORBA and EJB support will integrate many different security mechanisms, including storage of SSL certificates for identification and encryption. While the new wave of NCA products offers LDAP as a compelling new option, Oracle isn’t abandoning any of the user login or information lookup schemes of prior versions.

Oracle Applications and Business Logic

Oracle has been using NCA to rebuild its packaged application products. Beginning with Release 10.7 and, now, with Release 11, the Oracle Applications suite of financial, manufacturing, human resources, supply chain, and sales force automation software is implemented with all the benefits of graphical client/ server software — without the cost and complexity of installing client software on each user’s desktop.

While PCs previously executed the business logic, now the Developer/2000 Server cartridge (Oracle’s term for a software component) does it today using OAS on the middle tier. This combination hosts existing or new applications created with Oracle’s Developer/2000 toolset. Applications deployed with Developer/2000 Server can also interact with separate server cartridges to handle transaction, workflow, electronic payment, decision support, or other specialized functions.

Oracle’s been fairly clever about migrating its applications from a two- to a three-tier system. With the click of a button, Designer/2000 reverse engineers any application into a repository and generates it Java. Exactly the same application works either way. You don’t have to write new code or retrain users, because Designer/2000 regenerates the code for you.

At press time, the operations we’ve discussed are producing an applet (about 500KB in size) for downloading. Oracle Applications hasn’t yet reached the goal of Java on all three tiers. However, you can expect a future release of Oracle Applications to reverse engineer the repository into EJBs (perhaps with a little help from a future release of JDeveloper), with all the advantages these server-side components bring to the enterprise.

You may have heard people glibly stating that with the Web model, network traffic can be as little as one-tenth that generated by traditional client/server applications. But how does that translate into the everyday experience of the typical Oracle Applications user who’s executing repetitive transactions in the same form? The answer is, “It depends.” However, for some very realistic scenarios involving purchase order data entry and additional navigation, you might reasonably expect a distribution of bandwidth consumption over time. (See Figure 4.) We’ve taken Oracle’s own figures and, like good engineers, adjusted them downward by nearly 50 percent to compensate for any possible bias on Oracle’s part. You’ll appreciate such statistics if you’re familiar with the performance of client/server applications running over a WAN.

FIGURE 4 Oracle Applications: typical bandwidth consumption over time.

In addition to bandwidth consumption, users are concerned with latency — the amount of time required to confirm that a message reaches its destination. Although of great concern in WANs used for client/server applications, latency has little impact on Oracle’s Web applications. That’s because with NCA network traffic can be comparatively low—one round trip per field and a small number of round trips to change forms.

From Universal to Application Server

Oracle is moving beyond —but not abandoning — its “universal server” ambitions of a couple years ago. Previously, it focused on integrating object and relational technologies with access to data via SQL. Today, Oracle’s platform is the database plus the application server—with access to data via HTTP, IIOP, or other Internet standards. With Oracle’s new iFS assuming file management capabilities previously reserved for the operating system, it’ll be more practical to develop for the Internet rather than the operating system. By strongly supporting a range of Internet technologies, Oracle is putting its money where its mouth is — with the hope that you’ll reduce your capital and administrative costs while simultaneously improving performance.

Marcia and Philip Gulesian are technical director and president, respectively, of Gulesian Associates, a consulting firm located in Concord, Mass. They have written or cowritten nearly 100 articles and scientific papers and have advised corporations, universities, and governments worldwide. You can email Marcia at mg@world.std.com and Philip at pjg@world.std.com.

RESOURCES

Inprise: www.inprise.com

Oracle: www.oracle.com

Rational Software: www.rational.com