CORBA, Java, and the Object WebThe Web is in trouble. CORBA and Java are out to save it.

Robert Orfali, Dan Harkey, and Jeri Edwards

The next-generation Web -- in its Internet, intranet, and extranet incarnations -- must be able to deal with the complex requirements of multistep business-to-business and consumer-to-business transactions. To do this, the Web must evolve into a full-blown client/server medium that can run your line-of-business applications. The current HTTP/CGI paradigm is flawed; it can't meet these new requirements. The various CGI extensions -- such as cookies, the Microsoft Internet Services API (ISAPI), the Netscape Server API (NSAPI), Active Server pages -- are simply Band-Aids. To move to the next step, the Web needs distributed objects. We call this next wave of Internet innovation the "Object Web."

One approach to creating the Object Web is with Common Object Request Broker Architecture (CORBA) and Java. Without the Object Web, CORBA and Java would just be esoteric technologies -- mostly of interest to the enterprise client/server market and to object aficionados. As it turns out, CORBA and Java are having a shotgun wedding. Their marriage must be consummated for the higher good of the Object Web. The anxious parents are a coalition of vendors that includes almost everyone in the software industry but Microsoft. Microsoft is building its own Object Web, based on its ActiveX/Distributed Component Object Model (DCOM) technology. This may explain the sense of urgency behind the CORBA/Java wedding. We'll first do the introductions and then tell you all about the CORBA/Java Object Web.

First, we must warn Java supporters that CORBA is a lot more than just an object request broker (ORB) -- it is also a very complete distributed object platform. CORBA extends the reach of your Java applications across networks, languages, component boundaries, and operating systems.

Next we must warn CORBA proponents that Java is much more than just another language with CORBA bindings. Java is a mobile object system; it is a portable OS for running objects. Java will allow your CORBA objects to run on everything from mainframes to network computers to cellular phones. Java simplifies code distribution in large CORBA systems: Its bytecodes let you ship object behavior around, which opens exciting new possibilities for CORBA mobile agents. We find Java to almost be the ideal language for writing our client and server CORBA objects. Its built-in multithreading, garbage collection, and error management make it easier to write robust networked objects.

The bottom line is that these two obj ect infrastructures complement each other well. Java starts where CORBA leaves off. CORBA deals with network transparency, while Java deals with implementation transparency. CORBA provides the missing link between the Java portable application environment and the world of intergalactic objects.

So Why the Shotgun?

So why isn't this marriage made in heaven? Until recently, the problem was one of establishing clean divisions between the work of the Object Management Group (OMG, the force behind CORBA) and JavaSoft. For example, JavaSoft started to get into the ORB business when it defined its remote method invocation (RMI) for Java-to-Java communications across virtual machines. It really stepped squarely on OMG's toes with that one -- the 700-plus members of the OMG gave it the mission to develop distributed object standards.

The good news is that this turf war appears to be over. JavaSoft adopted CORBA as its distributed object model; it will run the RMI APIs on top of CORBA/ Internet In teroperable ORB Protocol (IIOP) with help from the OMG. This June announcement has done a lot to help heal the rift between the CORBA and Java camps. Here's how JavaSoft plans to make CORBA part of the Java core:

Java Development Kit 1.2 (slated for Q3 '97) will include a pure-Java CORBA ORB. The ORB is a subset of Joe -- the all-Java ORB included with Sun's NEO. In addition, JDK 1.2 will support JavaIDL, a development environment for generating CORBA stubs and skeletons from IDL. JDK 1.2 will also include an all-Java version of the CORBA Naming Service.

Java RMI will be implemented on top of CORBA/IIOP. This means that JavaSoft will abandon the proprietary ORB on which RMI is currently built.

A future JDK will support Enterprise JavaBeans. Enterprise Beans will communicate with client Beans via CORBA/IIOP (and other protocols). Most important, Enterprise JavaBeans will support the Java Transaction Service (JTS), which is based on the CORBA Object Transaction Service (OTS).

These annou ncements are very significant for both the low-end and the high-end of the CORBA/Java market. At the low end, you will be able to get from your JDK provider (perhaps even from Microsoft) a free CORBA/Java ORB as well as an IDL development environment. At the high end, you will be able to get transactional JavaBeans. Transactions provide ACID -- atomic, consistent, isolated, durable -- protection for Beans. They also serve as glue that you can use to synchronize independently developed Beans. Because of all this, what started as a shotgun wedding may be turning into a love affair.

What exactly is a CORBA/Java ORB? It's a CORBA/IIOP ORB that's written entirely in Java for portability. The ORB must be able to generate Java language bindings from CORBA IDL. In addition, any code generated by the IDL compiler must be in pure Java; you should be able to download that code and run it on any machine hosting a Java run-time environment.

So where can you get one of these fabulous CORBA/Java ORBs? As we go t o press, we know of three ORBs that fit the bill: Sun's Joe, Iona's OrbixWeb, and Visigenic/Netscape's VisiBroker for Java. Each of these ORBs has strong backers. Joe will be incorporated in JDK 1.2 (you can download the beta). OrbixWeb is sold by Iona, the leading ORB vendor. And VisiBroker for Java is bundled in every Netscape Communicator and Enterprise Server; it is also being bundled with Oracle's Network Computing Architecture (NCA), Sybase's Jaguar, and Novell's IntranetWare. In addition to these pure-Java ORBs, many ORBs written in C++ now provide Java language bindings -- for example, Expersoft's PowerBroker, IBM's Component Broker, and soon BEA's ObjectBroker.

Why Today's Web Can't Hack It

The Web first started out as a giant unidirectional medium for publishing and broadcasting static electronic documents. Basically, it was a giant URL-based file server. In late 1995, the Web evolved into a more interactive medium with the introduction of three-tier client/server, CGI-style. CGI is n ow used to access every known server environment.

HTTP with CGI is a slow, cumbersome, and stateless protocol; it is not suitable for writing modern client/server applications. CGI is not a good match for object-oriented Java clients. Web server vendors have gone through numerous contortions to work around the limitations of HTTP/CGI. Their solutions are usually in the form of proprietary server extensions and new APIs such as NSAPI, ISAPI, Next's WebObjects, and WinCGI.

To get around HTTP's statelessness, some of these extensions may require that clients pass cookies (i.e., server data held on the client) to identify their state. Others extend cookies with session objects on the server to represent their clients. These attempts are mostly proprietary and seriously flawed.

In addition, CGI is slow; it launches a new process to service each incoming client request. To get around this limitation, many of the vendor extensions provide memory-resident work-arounds -- such as in-process DLLs, ser ver plug-ins, and even ORB-based objects. In general, the server side will do almost anything to keep the services in memory across invocations. Consequently, it introduces another slew of nonstandard (and sometimes platform-specific) extensions.

The main problem with these approaches is that they require HTTP and the Web server to mediate between objects running on the client and on the server. There is no way for a client object to directly invoke a server object. The HTTP form you submit is still the basic unit of client/server interaction. This clumsy work-around is not suitable for full-blown client/server applications that require highly interactive conversations between components. It also does not scale well.

In 1996, the Web finally discovered objects. Java applets were the first step toward creating a client/server Object Web. Java is a necessary but not sufficient step toward creating the Object Web; Java needs to be complemented with a distributed object infrastructure, which is where CORBA comes into the picture.

The Object Web was officially born in June 1997 when Netscape shipped Communicator with a CORBA/Java ORB. On the server side, Netscape shipped both a CORBA/C++ and CORBA/Java ORB with every copy of the Enterprise Server 3.0. The intersection of Java and CORBA object technologies is the first step in the evolution of the Object Web.

Client/Server Interactions on the Object Web

How a Web-based client interacts with its server on the Object Web is pretty simple:

1. Web browser downloads HTML page. In this case, the page includes references to embedded Java applets.

2. Web browser retrieves Java applet from HTTP server. The HTTP server retrieves the applet and downloads it to the browser in the form of bytecodes.

3. Web browser loads applet. The applet is first run through the Java run-time security gauntlet and then loaded into memory.

4. Applet invokes CORBA server objects. The Java applet can include IDL-generated client stubs, which le t it invoke objects on the ORB server. The session between the Java applet and the CORBA server objects will persist until either side decides to disconnect. Note that you will need an IIOP-savvy firewall to make this work. Today, Iona's WonderWall firewall is the only game in town. But by the time you read this, Netscape might have shipped its own IIOP firewall.

5. Server objects can optionally generate the next HTML page for this client. After preparing the next pages, the server can tell the client what URL to download next. This dynamic HTML generation on the server side is typically not needed with the Object Web. A client application is packaged as a single HTML page with embedded components such as applets (or JavaBeans via the Object tag). In contrast to HTTP/CGI, CORBA lets you instantaneously interact with the server by clicking on any of the components embedded in the HTML layers without switching out of the page's context to obtain the response.

The technology we just described performs surprisingly well today. However, the Object Web is still under construction, as we explain next. Some key pieces will have to become available before we can declare the Object Web ready for mission-critical prime time.

How CORBA/Java Augment Today's Web

Augmenting the Web infrastructure with CORBA/Java provides two immediate benefits:

1) CORBA avoids the CGI bottleneck. It allows clients to directly invoke methods on a server. The client passes the parameters directly using precompiled stubs, or it generates them on-the-fly using CORBA's dynamic invocation services. In either case, the server receives the call directly via a precompiled skeleton. You can invoke any IDL-defined method on the server, not just the ones defined by HTTP. In addition, you can pass any typed parameter instead of just strings. This means there's very little client/server overhead, especially when compared with HTTP/CGI.

2) CORBA provides a scalable server-to-server infrastructure. P ools of server business objects can communicate using the CORBA ORB. These objects can run on multiple servers to provide load balancing for incoming client requests. The ORB can dispatch the request to the first available object and add more objects as the demand increases. CORBA allows the server objects to act in unison using transaction boundaries and related CORBA services. In contrast, a CGI application is a bottleneck because it must respond to thousands of incoming requests; it has no way to distribute the load across multiple processes or processors.

The Three-Tier CORBA/Java Object Web

All new applications on the Object Web will be built and packaged as components. You can use CORBA IDL to wrapper existing code, written in almost any language, with object interfaces. For example, you could use CORBA to magically make a million lines of existing COBOL code look like an object (and eventually you might even masquerade it as a CORBA/Java-Bean). Any IDL-described obj ect can now play on the Object Web in a first-class manner. This magic works because CORBA -- like Java -- maintains a clean separation between the interface of an object and its implementation.

Components require a thriving ecosystem to be commercially viable, and the Object Web provides one. The major computing companies -- including Sun, IBM/Lotus, Netscape, Oracle, Sybase, Novell, and BEA -- are betting their shops on this killer app. They have chosen both CORBA/IIOP and JavaBeans as the common way to provide a high level of plug-and-play between their products. To understand what is going on, let's go over the three-tier client/server architecture of this emerging Object Web.

The Client. The first tier belongs to traditional Web browsers and the new Web-centric desktops (see "The New User Interface," July BYTE). As opposed to today's static Web pages, the new content will have more of the look-and-feel of real-world objects -- for example, you'll see places that contain people, things, and other places. This very dynamic content is provided by ensembles of JavaBeans embedded in mobile containers, such as HTML pages or Jars, that contain shippable places. You will interact with these objects via drag-and-drop actions and other forms of direct manipulation. Client Beans will be able to interact with other client Beans in the container as well as with server Beans. In addition, server Beans will be able invoke methods on client Beans using CORBA events and callbacks. Note that both IIOP and HTTP can run on the same networks. HTTP is used to download Web pages, Jars, and images; CORBA is used for Java client-to-server and server-to-client communications.

The Middle Tier. The second tier runs on any server that can service both HTTP and CORBA clients. This CORBA/HTTP combination is supported on almost every server OS platform -- including Unixes, NT, OS/2, NetWare, MacOS, OS/400, MVS, and Tandem NonStop Kernel. CORBA objects -- which could eventually be packaged as Enterprise Java Beans -- act as middle-tier application servers; they encapsulate the business logic. These objects interact with client JavaBeans via CORBA/IIOP. Less scalable applications can also call these objects via scripts that run in HTML server pages -- for example, Netscape's Web Application Interface (WAI) provides such a bridge.

The CORBA objects on the server interact with each other using a CORBA ORB. They can also talk to existing server applications in the third tier using SQL/Java Database Connectivity (JDBC) or other middleware. You can even use the CORBA/IIOP server backbone as a general-purpose data bus. This is the technology Oracle is building for its data plug-ins. JDBC-on-IIOP data backbones are available today from I-Kinetics and Visigenic.

The second tier must also provide a server-side component coordinator -- also known as an object TP monitor. These component coordinators are TP monitors built on ORBs. Instead of managing remote procedures, they manage objects. The component coordinat or prestarts pools of objects, distributes loads, provides fault tolerance, and coordinates multicomponent transactions. Without these component coordinators, you cannot manage millions of server-side objects -- a key requirement of the Object Web. Examples of CORBA-based component coordinators are IBM's Component Broker and BEA's Tuxedo/Iceberg. But, what is a server-side component? It's a CORBA server object that also implements a minimum set of component services. A good example of this is the Oracle Cartridge. Cartridges are named CORBA objects that are also transactional, secure, and capable of emitting events.

A server component must also be toolable. This means that it must provide introspective interfaces that let you assemble it using visual tools. This toolable server-side component technology will be provided by CORBAtized Enterprise Java-Beans. The CORBA/JavaBean technology is being integrated in visual builder tools from Symantec, Penumbra, ParcPlace, IBM/Taligent, Borland, and Sybase.

In a CORBA/Java Object Web, the second tier also acts as a store of component titles, HTML pages, and shippable places. These can be stored in shippable Java Jars that are managed by an ODBMS or DBMS. ODBMSes are better suited for the task.

The Back End. The third tier is almost anything a CORBA object can access. This includes procedural TP monitors, message-oriented middleware, DBMSes, ODBMSes, Lotus Notes, and e-mail. So the CORBA business objects replace CGI applications in the middle tier, which is good. Eventually, you will be able to get CORBA/Java components that encapsulate most of the third-tier functions. This is an area where CORBA's interlanguage communications capabilities will come in handy. Look at some of the I-Kinetics work to understand what you can do with these back-end components.

Architectural Glue

CORBA and Java provide the architectural glue that connects products on the Object Web. This is our industry's first attempt to provide plug-and-play at the soft ware product level, which is the ultimate open system dream.