CORBA, Java, and the Object Web

CORBA, the open object bus, holds the promise of an open playing field for components.

Distributed CORBA objects may have finally found their killer application. It's called the Object Web-the marriage of distributed objects and the World Wide Web. The major computing companies-including Sun, JavaSoft, IBM, Netscape, Apple, Oracle, BEA Systems, and Hewlett Packard-have chosen CORBA IIOP as the common way to connect distributed objects across the Internet and intranets. Consequently, CORBA may become almost as ubiquitous as TCP/IP by the end of 1997. This will create a mass market for components that run on top of CORBA middleware.

This is good news for those of you who are in the market for a great heterogeneous component infrastructure based on distributed objects. In the last few years, many of you discovered that a distributed object standard-even if it is supported by more than 700 companies-is not enough to create a successful component infrastructure. Commercial CORBA ORB offerings from the major software vendors also were not enough. Even great technologies such as IIOP and CORBA transactions were not enough. Components also require a thriving ecosystem to be commercially viable. In the Microsoft world, the ecosystem for ActiveX is provided by OLE killer applications such as Visual Basic, Word, Access, and Excel. Until the advent of the Object Web, the CORBA world had great technology but no thriving ecosystem. No one got rich writing CORBA components. But that's about to change.

CORBA in a Nutshell

The Common Object Request Broker Architecture (CORBA) is one of the most important (and ambitious) middleware projects ever undertaken by our industry. It is the product of the Object Management Group (OMG), a consortium that includes more than 700 companies, representing the entire spectrum of the computer industry. The notable exception is Microsoft, which has its own competing object broker called the Distributed Component Object Model (DCOM). For the rest of our industry, the next generation of middleware is CORBA. The CORBA object bus defines the shape of the components that live within it and how they interoperate. Consequently, by choosing an open object bus, the industry is also choosing to create an open playing field for components.

What makes CORBA so important is that it defines middleware that has the potential to subsume every other form of existing client/server middleware. In other words, CORBA uses objects as a unifying metaphor for bringing existing applications to the bus. At the same time, it provides a solid foundation for a component-based future. The magic of CORBA is that the entire system is self-describing. In addition, the specification of a service is always separated from the implementation. This lets you incorporate existing systems within the bus.

CORBA was designed to let intelligent components discover each other and interoperate on an object bus. However, it goes beyond just interoperability. It also specifies an extensive set of bus-related services for creating and deleting objects, accessing them by name, storing them in persistent stores, externalizing their states, and defining ad hoc relationships between them.

The four main elements of the CORBA architecture are shown in Figure 1. They are as follows:

• Object Request Broker (ORB) defines the CORBA object bus
• CORBAservices define the system-level object frameworks that extend the bus
• CORBAfacilities define horizontal and vertical application frameworks that are used directly by business objects
• Application objects are the business objects and applications-they are the ultimate consumers of the CORBA infrastructure.

The Three-Tier Object Web

As a result of all this work, a new Object Web model is starting to emerge. It follows the three-tier client/server application model shown in Figure 2. As usual, the first tier belongs to the client. In this case, the client belongs to browsers, Java client applications, and shippable applets. The second tier is provided by any server that can service both HTTP and CORBA clients. The third tier belongs to traditional servers.

The middle-tier CORBA/HTTP combination is supported on almost every server platform-including various flavors of UNIX, Windows NT, OS/2, NetWare, MacOS, OS/400, MVS (mainframe), and Tandem NonStop Kernel. CORBA objects act as middle-tier application servers; they encapsulate the business logic. They interact with client components through a Java ORBlet (for example, a downloadable ORB written in Java bytecodes) or any regular CORBA ORB that can run IIOP over the Internet. Of course, the CORBA objects on the server can interact with each other using a CORBA ORB. They can also talk to existing server applications in the third tier using SQL or any form of middleware.

The second tier must also provide a server-side component coordinator (or object transaction monitor). We know of two major projects that are creating CORBA-based transaction monitors: IBM's Business Object Server Solution (BOSS) and BEA Systems' Tuxedo-based ObjectWare. 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 Oracle's Cartridges, which are named CORBA objects that are also transactional, secure, and capable of emitting events.

A server component must also be buildable. This means it must provide a build interface that lets you assemble it using visual tools. For example, the object can provide an icon that represents it to the tool. When you click on the icon, the object will display the methods it supports and the CORBA events it emits. This is all done via introspection (that is, the component can tell you something about itself). So you will be able to wire object ensembles by connecting output events to input methods.

The third tier is almost anything a CORBA object can talk to. This includes procedural transaction monitors, message-oriented middleware, database management systems, object database management systems, Lotus Notes, and e-mail. So the CORBA business objects replace CGI applications in the middle tier, which is good.

The Java client can directly communicate with a CORBA object using an IIOP ORB. This means CORBA replaces HTTP/CGI as the middleware layer for object-to-object communications, which is also very good. Like HTTP, CORBA's IIOP uses the Internet as its backbone. This means that both IIOP and HTTP can run on the same networks. HTTP is used to download web pages, applets, and images; CORBA is used for Java client-to-server communications.

Client/Server Interactions on the Object Web

Figure 3 shows how a typical web-based client interacts with its server on the Object Web. First, the web browser downloads the HTML page. In this case, the page includes references to embedded Java applets. Second, the web browser retrieves the Java applet from the HTTP server. The HTTP server retrieves the applet and downloads it to the browser in the form of bytecodes. Third, the web browser loads the applet. The applet is first run through the Java run-time security gauntlet and is then loaded into memory. Fourth, the applet invokes CORBA server objects. The Java applet can include IDL-generated client stubs, which let it invoke objects on the ORB server. Alternatively, the applet can use the CORBA Dynamic Invocation Interface to generate server requests on-the-fly. The session between the Java applet and the CORBA server objects will persist until either side decides to disconnect.

In Figure 3, the Java client is a downloadable applet. Of course, the client can also be a regular Java application. The difference is that you do not have to download a Java application over the Internet, which removes the overhead of the HTTP download. But then you would give up the benefit of being able to dynamically load a client on demand. Today's Java ORBs support either approach. So we have an evolutionary solution that does not disrupt existing web applications.

What CORBA Brings to Java

Augmenting the World Wide Web infrastructure with CORBA provides three immediate benefits. First, it gets rid of the CGI bottleneck on the server. Second, it provides a scalable and robust server-to-server World Wide Web infrastructure. Third, it extends Java with a distributed object infrastructure. A brief explanation follows.

CORBA avoids the CGI bottleneck. It lets clients directly invoke methods on a server. The client passes the parameters 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 through 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. With CGI, you must start a new instance of a program every time an applet invokes a method on a server; with CORBA, you don't. Additionally, the CGI does not maintain the state between client invocations; CORBA does.

CORBA provides a scalable server-to-server infrastructure. Pools 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 lets the server objects 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 cannot distribute the load across multiple processes or processors.

CORBA extends Java with a distributed object infrastructure. Currently, Java applets cannot communicate across address spaces using remote method invocations. This means that there is no easy way for a Java applet to invoke a method on a remote object. CORBA lets Java applets communicate with other objects written in different languages across address spaces and networks. In addition, CORBA provides a rich set of distributed object services that augment Java-including metadata, transactions, security, naming, trader, and events.

The Other Contenders

In Part Four of our book Client/Server Programming with Java and CORBA (John Wiley & Sons, 1997), we cover the top five competing infrastructures for building the Object Web-including streamed Sockets, HTTP/CGI, Java RMI (Remote Method Invocation), CORBA/IIOP with Netscape's Caffeine (which lets you create CORBA IIOP objects directly from Java-no IDL is needed), and DCOM/ActiveX. We wrote the same client/server application using each of the competing technologies. We then put together a report card that compares the client/server development process, the Java integration facilities, installation and deployment, Ping performance, and intergalactic reach of each system. Table 1 shows our Michelin rating of the five contending Object Web technologies. Four stars is the highest rating. A hollow star is the worst rating; it means the function is not there.

Yes, CORBA is inevitable. Why? Table 1 says it all. CORBA's only real competition is DCOM. RMI is a niche Java-to-Java ORB; it's not going anywhere on the enterprise. Sockets is just a low-level protocol. HTTP/CGI just doesn't cut it. So, it's CORBA vs. DCOM. It appears CORBA won the first round. But the battle will continue for the remainder of the century.

We have learned the hard way never to underestimate Microsoft. DCOM will make a strong showing in NT-only shops and in corporations that standardize on the Microsoft Object Web. However, the World Wide Web is by definition heterogeneous. So it will be an uphill battle for Microsoft. In a worst-case scenario, DCOM could win if the CORBA-based Object Web coalition fell apart (see the "Meet the Players" sidebar).

The bottom line is that Java is primarily a mobile code system, while CORBA is a distributed object infrastructure. Java lets you write portable applications that can run on any machine in the galaxy. CORBA provides an intergalactic distributed object infrastructure over the Internet. CORBA lets Java objects communicate with any other object, anywhere. The two technologies are complementary.

In summary, this new CORBA coalition is building around a killer application called the Object Web. The Object Web transforms CORBA from a set of standards to a set of products that fulfill an intergalactic need. CORBA becomes a powerful architecture that ties together products that form the Object Web. For example, ORBs running in Netscape browsers can talk to middle-tier Oracle Cartridges that also happen to be CORBA business objects. Object transaction coordinators-from IBM, BEA Systems, and Hitachi-can coordinate these server-side business objects because they, too, sit on the CORBA bus. Components and Beans from Apple, Components Integration Labs, JavaSoft, IBM, Oracle, Netscape, Symantec, and Borland can also play on the CORBA bus. The CORBA bus is the foundation technology that brings together all these disparate pieces of software from multiple vendors. The CORBA/Java Object Web will eventually draw in thousands of smaller software developers that will create specialized components to service this huge market.

In parallel, Microsoft is building its own rendition of the Object Web; it is based on DCOM and ActiveX. The Microsoft Transaction Server (formerly code-named Viper) is the DCOM component coordinator; it is Microsoft's secret weapon for winning the Object Web. Currently, the Microsoft Web appears to be a single-anchor mall with tons of boutiques. Let the games begin.