In the late 1980’s and early 1990’s, leading-edge technology firms were looking for competitive advantages in an increasingly volatile marketplace, and recognized distributed computing systems as a way to achieve that edge. What was missing from the equation was a uniform architecture for building distributed systems – a model for code reuse and code integration by which system developers could live. Companies understood the value of code reuse and code integration, but no company alone was able to realize the dream of a universally accepted, language independent standard to support complex multi-tier applications. Then, in May 1989, the Object Management Group was formed.
Originally consisting of eight corporations, the OMG was formed “to create a component-based software marketplace by hastening the introduction of standardized object software.” In 1992, the OMG unveiled The Common Object Request Broker Architecture (CORBA) to finally fill the void in the distributed-object development domain. Today, the OMG has over 800 members with the common goal of defining (and conforming to) specifications that propagate heterogeneous computing environments across all major hardware platforms and operating systems.
Companies like IBM, Netscape and Oracle have since joined the CORBA camp and are actively deploying technologies that are CORBA compliant. IBM has just introduced Component Broker, its new CORBA technology that is based on OMG standards and is 100% Java compliant. Component Broker is being marketed as IBM’s strategic CORBA platform — a complete solution for customers needing to connect multiple back-end systems to dynamic, new applications.
Netscape has a partnership with Visigenic, and is bundling the Java ORB runtime into the Navigator 4.x browsers 1 . They are also providing the Visigenic’s VisiBroker for Java object request broker technology with Netscape’s Enterprise Server 3.0. Reconfirming Netscapes position on CORBA and IIOP, Marc Andreesen wrote “IIOP will be integral to everything we do. Netscape Navigator will be able not only to browse content but also to browse objects. We expect to distribute 20 million IIOP clients over the next 12 months and millions of IIOP-based servers over the next couple of years. We’ll put the platform out there so that people can start developing for it.”
Oracle is using CORBA technology in an attempt to make its vision of Networked Computing (NC) a reality. The Oracle vision, in its most basic form, is to have light-weight clients download Java applets that communicate to server applications and databases by way of CORBA/IIOP. There is an excellent article in the February 1998 issue of Object Magazine that discusses Oracle’s strategy, including CORBA involvement, in great detail.
What makes CORBA an attractive architecture is its platform and language independence. Microsoft’s Distributed Component Object Model (DCOM) also supports multiple languages (Java, VB, C++), but is lacking platform independence since it was obviously geared toward the Windows environment. However, the CORBA platform independence advantage may soon fade away as Microsoft is combining efforts with other development firms in order to port DCOM to other platforms.
One of the major cons of the Java/CORBA environment is that only a few of the specified services have been implemented in the Java ORBS. For example, Visibroker 3.0 has only implemented the Naming and Event CORBAservices to date. Important CORBAservices such as Security, Query, Transaction and Concurrency Control are not yet available but could be mission critical requirements for some types of distributed applications.
A short list of the pros and cons of implementing a Java-CORBA solution is provided below.
CORBA’s major competitor is the Distributed Component Object Model (DCOM) created by Microsoft. Microsoft’s product saturation in the business market makes them a very real competitor, claiming that COM and DCOM are used in over 150 million systems worldwide. Since COM/DCOM systems are in such abundance, the technology is not going away anytime soon.
As a result, some CORBA product-based companies are taking a “if you can’t beat ’em, join ’em” approach toward the DCOM initiative. On January 26, 1998, Iona Technologies, manufacturer of the successful OrbixWeb ORB, announced that it has licensed Microsoft’s COM technology with the objective of creating CORBA/COM interoperability. Why has IONA chosen a path of CORBA/DCOM interoperability? Annraí O’Toole, Chief Technical Officer at IONA addresses this issue, “We are not in the business of dictating to our customers. COM is a very important technology in the market place and we need to make sure that everything we do with Orbix works well with COM. COM is just as important to IONA as CORBA and our customers are not interested in religious wars or incompatibilities.”
For CORBA to really set itself apart from DCOM and emerge as the industry standard, it needs to forge a tighter relationship with Java. The technologies complement each other well, with CORBA providing network transparency and Java providing implementation transparency 2 . Java enables CORBA clients to be easily distributed to remote machines, regardless of platform, via applets and browsers. CORBA reciprocates by enabling Java to interface with different programming languages and extends Java by providing a framework for distributed object communications.
And fortunately for the CORBA backers, JavaSoft’s Remote Method Invocation (RMI), which formerly was thought of as a competitor to CORBA, is fast becoming one of CORBA’s main allies. This is supported by an announcement in the Java Spot News, dated February 18th, 1998, when the Object Management Group (OMG) publicly declared that it had finalized modifications of its IIOP communications protocol so that it could support most of the JDK1.1 functionality of the Java programming language’s RMI. This press release, found on JavaSoft’s site (www.javasoft.com), maintains that IIOP allows distributed objects to conform to OMG’s CORBA specification, thus by enabling RMI to run on top of IIOP, Java objects can now easily also conform to CORBA. JavaSoft also stated that support for running RMI over IIOP will be available as a standard extension to the next version of the Java Development Kit.
Good news indeed for CORBA/Java developers.
An ORB is the basic building block for client/server objects to communicate with each other. A Java ORB allows clients and servers written in Java to use the CORBA implementations. Since the client and server objects let the ORB handle all their distributed method invocations, neither the client nor server have any working knowledge of the makeup or the location of other objects in the system. For more information about CORBA ORB’s and to see more examples of ORBs at work, visit www.corba.net. For the purpose of this demo, Visibroker by Visigenic was implemented. Developers can download a trial version of Visibroker at www.visigenic.com. (Note: Visibroker was the ORB of choice in Orfali-Harkey’s “Client/Server Programming with Java and CORBA” 3 and also got an excellent review in the January 1998 edition of the JAVA ADVISOR.)
The Interface Definition Language file (TimeStamp.IDL) is used to create a language independent definition of all the objects that will be implemented on the server.
module TimeStamp < interface TimeStampIF < string getTimeStamp(); >;>;
In the above example, there is only method contained in the interface, ‘getTimeStamp’, that returns a string value. Also, note that the term module is comparable in functionality to the Java package naming construct 4 .
public class TimeStampServer < public static void main(String[] args) < // Initialize the ORB. org.omg.CORBA.ORB orb = [break in code] org.omg.CORBA.ORB.init(args,null); // Initialize the BOA. org.omg.CORBA.BOA boa = orb.BOA_init(); // Create the TimeStamp object. TimeStamp.TimeStampIF TimeStampObject = new TimeStampImpl(“TimeStampService”); // Export the newly created object. boa.obj_is_ready(TimeStampObject); System.out.println(TimeStampObject + ” is ready.”); // Wait for incoming requests boa.impl_is_ready(); >>
In addition to the server (TimeStampServer.java), a Java implementation of the initial interface/IDL file is necessary. The implementation file, TimeStampImpl.java, contains the actual code of the one remote method provided by this CORBA example: getTimeStamp()
import java.util.*;import java.lang.*;public class TimeStampImpl [break in code] extends TimeStamp._TimeStampIFImplBase < // Construct a persistently named object. public TimeStampImpl(java.lang.String name) < super(name); >/** Construct a transient object. */ public TimeStampImpl() < super(); >public java.lang.String getTimeStamp() < // implement operation… Calendar exactTime = Calendar.getInstance(); String exactTimeStr = (String)(exactTime.getTime()).toString(); return exactTimeStr; >>
vbj TimeStampClient And with any luck, the server will return the current date and time to the client.