Internet Systems - January 1997

Internet Systems, January 1997 Internet Systems Online: Net Developer By David S. Linthicum

Distributed Objects Get New Plumbing

IIOP May Give Distributed Objects Wider Deployment and Ready Acceptance.

Can object request brokers (ORBs) and the Web get along? According to Netscape, they can. At Object World West in San Francisco last August, Netscape Communications Corp. declared CORBA-based distributed objects the new direction for Internet/Intranet applications development, along with Internet Inter-ORB Protocol (IIOP) as the plumbing and wiring.

IIOP is the new protocol, which replaces HTTP as the de facto Web communications standard, according to Netscape's Marc Andreessen. Netscape shipped 20 million IIOP- and ORB-enabled Web browsers (Navigator 3.0) within a few weeks. This is the same model used to deploy Java, which slowly continues to gain market share. IIOP will allow ORBs that reside on a client (usually running inside a browser) to have full interaction with an application server running CORBA-compliant ORBs. (See Figure 1.) This avoids the overhead of sending HTML files to and from servers and makes the development model more like traditional distributed computing.

Why IIOP?

There are several advantages to using IIOP. The bandwidth requirement is much less than the typical file-oriented HTML transfer. IIOP uses messages, which are more applicable to client/server applications. What's more, IIOP is said to reduce many of the problems developers face when deploying applications to the Web. Developers can focus on the application and not the communication mechanisms. IIOP is also much more elegant and efficient than using Web server APIs such as CGI. Web clients can invoke the services of distributed objects that reside anywhere on the Intranet. Development managers should see lighter-weight database processes and a better way to deploy complex multi-tiered client/server applications to their Intranets.

The adoption of IIOP by Netscape is part of Netscape's Open Network Environment (ONE). This is clearly a reaction to Microsoft's introduction of the Distributed Component Object Model (DCOM) to the Web through ActiveX. DCOM is Microsoft's ORB of choice and is a competitor to CORBA.

To move developers quickly to IIOP and ONE, last August Netscape released beta of a software developer kit with several IIOP foundation classes. The first two classes handle the user interface. You can expect to see several iterations of IIOP-enabled development tools over the next few months.

So What Is IIOP?

At its core, IIOP is simply a standard communication mechanism between CORBA-compliant ORBs. The Common Object Request Broker Architecture is the Object Management Group's (OMG) standard architecture (a specification, really) for distributed objects. With the CORBA 2.0 specification, just released over a year ago, OMG finally achieved interoperability between ORBs by defining the IIOP communications mechanism as mandatory for all CORBA-compliant ORBs. Consider IIOP as TCP/IP with a few CORBA-specific messages for ORB-related communications. All CORBA-compliant ORBs must implement IIOP as a native feature of the ORB, or provide a "half-bridge" to IIOP. Half bridges mean that any proprietary ORB can connect to other ORBs by linking to an IIOP backbone through a translation layer.

Developers can exploit the distributed features of IIOP to create distributed applications. These applications are a collection of ORBs connected via a network such as the Internet or an Intranet. ORB vendors should be able to communicate with one another using IIOP as the backbone and proprietary ORBs connecting in via half bridges.

IIOP is a natural for the Internet because of its distributed capabilities and native support for TCP/IP. The OMG believes that the Web could raise interest in the use of distributed objects. Until now, few CORBA-compliant commercial ORB vendors have been able to penetrate the market. The OMG hopes IIOP will recharge the dying distributed object marketplace plagued by slow delivery cycles and a lack of tools. (See my column, "Are We There Yet?" in the November issue of DBMS.)

Commercial IIOP Products

So who's creating ORBs for the Web using IIOP? Most interest lies with Visigenic Software Inc.'s VisiBroker for Java (formerly PostModern Computing Technologies Inc.'s BlackWidow). Using VisiBroker, a Java applet can invoke the services of a CORBA-compliant object using IIOP. The Java applet needn't use CGI or HTTP, but it uses a direct communications link between the ORB on the client browser and the ORB or ORBs on the server.

VisiBroker runs like any other Java applet, meaning that any browsers that support Java can run VisiBroker. Applets can even employ the Secure Socket Layer (SSL) when communicating with a remote server. Because VisiBroker is just another CORBA object, it can bypass the limitation of HTTP and CGI and provide developers with a true distributed computing environment. Thus developers don't need to launch a CGI process, and the programming model is more traditional. For example, ORBs support states, but CGI is stateless.

Building Web ORBs

The process of creating VisiBroker Web clients starts with the developer defining the methods that the object will expose to other objects. These methods are set using the interface definition language (IDL). The developer must then run the IDL through the VisiBroker precompiler, which generates skeleton code for the server objects. The skeleton code may be C++ or Java; developers need to augment this code to meet the exact needs of the applications. This is where IIOP/VisiBroker really goes to work.

VisiBroker consists of two main components: a development component and a runtime component. The development component automatically converts object interfaces into Java code for either the client or the server. The runtime component manages communications between distributed applets and other CORBA-compliant objects. VisiBroker for Java run time will be bundled with Netscape Navigator 4.0.

VisiBroker is efficient. It can generate ORBs that require less than 100K of byte code. Performance is comparable to other Java applets, and users don't really know they're running an applet that's also an ORB. Why should we care about VisiBroker? Netscape selected IIOP and VisiBroker as its communications protocol, bundling VisiBroker for Java with Netscape Navigator and Netscape Web servers. This fact alone will carry VisiBroker and IIOP to your desktop in the very near future.

Although the Web-enabled world cares deeply about the invasion of the ORBs, only a few vendors have moved in this direction. Informix Corp., for example, offers the IIOP-enabled Informix Enterprise Command Center. This distributed database administration tool, which leverages the power of VisiBroker, comes in both Java and Windows versions, with the Java version uses the VisiBroker ORB. The ORB communicates with other ORB "agents" without having to go through HTML or CGI. Expect a rash of products shortly after Netscape releases Navigator 4.0, probably from existing Java development vendors.

At press time Visigenic announced Caffeine, a joint effort of Netscape and Visigenic. It gives developers the ability to create IIOP-based distributed objects using Java. Caffeine further strengthens the links between Java and the CORBA world.

Is it Worth It?

Distributed objects haven't really set the world on fire. Web-enabling them won't solve some of the problems they have. I've found that commercial ORBs are slow and inefficient -- and not ready for mission-critical applications. For instance, the ORBs don't provide garbage collection or concurrency control. What's more, they don't scale well for client/server. Binding Java to an ORB won't solve these problems.

What ORBs on the Web will do is bypass the limitations of CGI (even Netscape's NSAPI and Microsoft's ISAPI), providing a better architecture for distributed system development and extending the capabilities of Java. IIOP lets the client link directly to the methods on the remote ORB without the overhead of CGI. CGI must begin a new instance of a CGI program each time the client invokes a service. Don't forget that CGI can't do states.

Within the architecture of ORBs and the wiring of IIOP, developers can standardize interprocess communications. Objects can run on multiple servers to provide load balancing (albeit in a limited way). CGI applications must react to all incoming client requests with no easy way to spread the load to additional processes.

Java-enabled ORBs are better than "traditional" Java applets and applications. Java applets can't talk from address space to address space; they must invoke the services of other Java applets. ORBs, using IIOP, can link to ORBs created with any number of programming languages. ORBs solve these problems because they have their own communication backbone.

I don't expect ORBs to take the Web world by storm, but as developers and users alike discover the advantage of driving Internet/Intranet applications with ORBs, they will experience a steady growth. You should remember that there's another ORB in town, and Microsoft isn't likely to give up the momentum behind DCOM. Although DCOM isn't as mature as CORBA and IIOP, tools are already available to create DCOM-enabled applications, and Microsoft has more resources behind its technology. CORBA has yet to receive large-scale interest from the tool vendors.

If you're thinking about developing applications with Java-enabled ORBs and IIOP, you're better off waiting until the technology takes a few more baby steps.

Figure 1.

--The distributed features of IIOP can be used to create distributed applications. These applications are a collection of ORBs connected via a network such as the Internet or an Intranet and using IIOP as the communication backbone.

David S. Linthicum is a widely published author, speaker, and computer science professor, and technical manager with AT&T Solutions in Vienna, Virginia. You can email David at 70742.3165@compuserve.com, or visit his home page at http://ourworld.compuserve.com:80/homepages/D_Linthicum/.

Please send questions or comments to dbms@mfi.com
Updated Friday, December 13, 1996.