CORBA is a complete distributed object platform. It extends applications across networks, languages, component boundaries, and operating systems. A CORBA Object Request Broker (ORB) connects a client application with the objects it wishes to use. The client application does not need to know whether the object resides on the same computer or on a remote computer elsewhere on the network. The client application needs to know only two pieces of information: the object's name and how to use the object's interface. The ORB takes care of the details of locating the object, routing the request, and returning the result.
As CORBA grew, three influential trends were taking shape:
Netscape envisions a near-term future in which software objects with defined interfaces interoperate across corporate intranets and across the Internet. The benefits for application developers and information technology (IT) organizations are significant:
Choice. CORBA is based on an open, published specification. It is implemented on and supported by numerous hardware and operating system platforms. CORBA Java objects are portable. You can build objects on one platform and deploy them on any other supported platform.
Interoperability. CORBA objects are fully interoperable because they communicate using the Internet Inter-ORB Protocol (IIOP). An enterprise IT organization need consider only its functional needs when selecting an ORB, CORBA services, and software objects, even when they are developed by different vendors. In addition, software bridges enable communications between CORBA objects and objects developed using Microsoft's DCOM technology.
Modularity. CORBA objects interact via interfaces. Because interface and implementation are separate, developers can modify objects without breaking other parts of the application. Changing an object's implementation does not affect other objects or applications because that object's interface stays the same.
Compatibility. CORBA protects your investment in existing systems. You can encapsulate a legacy application, module, or entry point in a CORBA IDL wrapper that defines an interface to the legacy code. This object wrapper makes the legacy code interoperable with other objects in a distributed computing environment.
Security. CORBA provides security features such as encryption, authentication, and authorization to protect data and to control user access to objects and their services.
Netscape is making CORBA a cornerstone technology, integrating it with every client and server solution they sell from now on. Netscape Technology Senior Vice President Marc Andreessen briefly described the company's CORBA vision in a Techvision column about the CORBA network protocol, IIOP. As Marc emphasizes, CORBA enables access to a range of services-using databases, tracking inventory, keeping medical records, controlling corporate finances, searching for information-in addition to the kinds of content and applications available today. These services are implemented as objects stored on servers of all types; CORBA lets objects written in virtually any language interact. These objects are small software components rather than large applications. For this reason, objects can be updated and distributed far more quickly and easily than older, traditional software.
The first step of Netscape's CORBA strategy is to make CORBA an integral part of every client and server across its installed base. Netscape includes the following with its new Communicator and SuiteSpot product lines:
Together, ORBs and the CORBA architecture provide the mechanism for CORBA objects to communicate. The objects are small software components that provide some kind of a service, such as access to a database, account management, or inventory tracking. Fundamental to the architecture are the ORBs. For any client or server to be a part of the CORBA scheme, it must include an ORB to help it find and communicate with other CORBA objects. Once outfitted with an ORB, a client or server can use the services of any CORBA object on any server or host on the network. An object can be both a client and a server: when it provides services to another object, it's a server; when it requests services from another object, it's a client.
The CORBA architecture provides a set of services that help objects interact with each other. (In the CORBA world, services means both the services provided by the CORBA architecture to help objects communicate and the functionality provided by the objects themselves.)
The services are among the efficiencies provided by CORBA: You write your object's code, and CORBA takes care of how your object identifies itself, finds other objects, learns of network events, handles object-to-object transactions, and maintains security. The services include the following:
Current versions of the Netscape Internet Service Broker support the CORBA naming service, and Netscape engineers are working on updates that will include support for the event, transaction, and security services for future releases of Communicator and Enterprise Server. Further, Netscape and several of its partners are extending the naming service for easier interoperability between different vendors' ORBs.
A client object requests the services of other objects through an ORB that resides on the client system. Using IIOP, the client ORB then reaches across the network, looking for ORBs on other systems and the server objects that can provide the requested services. Each object has a unique name, provided according to the CORBA naming service, which identifies it and its services to other objects. Once the ORB has found the requested service/object, the client object communicates with the server object, still using IIOP. Each object's IDL interface tells other objects how to use its services and the results those services generate.
As a practical example, consider a parcel-tracking application. (This example is based on a similar example used by Visigenic Software in its white paper about CORBA, Distributed Object Computing in the Internet Age, which is available from Visigenic as a PDF file.) Suppose an Internet user wants to track delivery of a package. From a browser, the user enters a URL that points to the delivery company's Web server. The server uses HTTP to send a Web page to the user; that page contains an embedded Java applet, which is the client component of the parcel-tracking system. Note that so far, nothing is different from a traditional HTTP Web transaction.
Next, the user enters a parcel-tracking number into the appropriate field in the Java applet. Using the client-side ORB, the applet then generates and sends an IIOP message across the network, looking for a specifically-named server object that can obtain the status of the parcel. The ORB on the server with the appropriate parcel-tracking object picks up the message and invokes the object's status-finding method. Through the server ORB, the object then generates another IIOP message looking for an object on a legacy system that contains all the parcel company's data.
Upon obtaining the last request through its ORB, the mainframe containing the data-tracking object determines that status of the parcel from its database. The mainframe returns an IIOP message with the information to the server object. The server then routes the information-again with IIOP and the ORBs-to the Java applet running on the client, which displays the results to the user.
CORBA objects do not have or need information about each other's implementation details. They communicate only through their published interfaces, and the ORB manages these communications transparently to users. The client could be a PC running Windows, a Macintosh, a workstation, a network computer, a handheld personal computer, or even a set-top box. Server objects can be programmed in a variety of languages and may include new and legacy code. Because they communicate with the objects via IIOP, clients can access functionality directly, without going through Web server software and without the performance costs of processing a CGI script for each user access.
CORBA defines an interface definition language (IDL) that provides a language-neutral way to describe a CORBA object and the services it provides. IDL lets components written in different languages communicate with each other using IIOP and the rest of the CORBA architecture. CORBA objects can reside on different types of systems, including Windows or UNIX servers and IBM 3090 or DEC VAX mainframes. They can be written in different languages (Netscape provides tools for developing in Java and C++). As long as interfaces to their services are written in IDL, the objects can communicate and use each others' services through ORBs on clients, servers, database systems, mainframes, and other systems on the network.
Here are the basic steps:
Whether you use Java or C++ depends on your preferences and the solution you're trying to develop. Java is probably more flexible, because a Java object will work on any operating system with a Java virtual machine. However, C++ may give better performance, depending on your server environment.
The specific techniques you'd use to create new Java and C++ CORBA objects are described in the Netscape Internet Service Broker documentation that's part of the current Enterprise Server 3.0 release. Start with the Netscape Internet Service Broker for Java Programmer's Guide and the Netscape Internet Service Broker for C++ Programmer's Guide.
CAFFEINE: CORBA WITHOUT IDL
Netscape's Enterprise Server 3.0 includes a java2iiop compiler (also called Caffeine) for defining CORBA-compliant interfaces using Java instead of IDL. By using java2iiop, you can generate the necessary container classes, client stubs, and server skeletons from Java bytecode. Caffeine makes it easy for Java programmers to write objects that interoperate across Java VMs using Java language semantics. You don't have to learn CORBA IDL to make Java objects remotable and accessible via a CORBA IIOP ORB. Caffeine also lets you pass objects by value. Finally, it provides a naming service that maps CORBA object references to URLs. The following figure shows the development process.
Divide your legacy code and other older code into smaller objects and write an IDL specification for them. This will expose the object's services to other CORBA objects across the Internet, making it possible for other CORBA objects to communicate with your objects. With CORBA, you can preserve your current code base and give it an interface (through IDL) that makes it accessible via Internet technology.
In addition to providing the basic ORB features defined in the CORBA specification, Netscape's ISB for Java offers enhancements that increase application performance and reliability.
|
|
|
| Fault tolerance | ISB can determine if the connection between your client application and an object server has been lost because of a server crash or network failure. When it detects a failure, it tries to restart the server or to connect your client to a suitable server on a different host. |
|
|
|
| Optimized binding | When your application binds to an object, ISB selects and establishes the most efficient communication mechanism. Depending on the platform and the location of the requested object, the bind may be established through a pointer reference or a TCP/IP connection. |
|
|
|
| Dynamic Invocation Interface | Client applications can obtain an object's interface and dynamically construct requests to act on the object. |
|
|
|
| Interface repository | The interface repository (IR) maintains information about ORB objects, such as modules, interfaces, operations, attributes and exceptions. An IDL interface enables your client applications to query the IR to obtain language binding information or to discover new interfaces. The ORB also accesses the IR when it needs to check the type of values in a client request or to verify the correctness of an interface inheritance graph. |
|
|
|
| Web Naming service | Web Naming allows you to associate URLs with objects, allowing an object reference to be obtained by specifying a URL. |
|
|
|
| Caffeine: Defining interfaces without IDL | The java2iiop utility (also called Caffeine) allows you to use Java instead of IDL to define interfaces. Use java2iiop when you want to adapt existing Java code to use distributed objects or if you do not have the time to learn IDL. It generates the necessary container classes, client stubs, and server skeletons from Java code. |
|
|
|
| Enhanced thread and connection management | ISB provides two thread policies: thread-per-session and thread pooling. You choose a policy, then ISB automatically selects the most efficient way to manage connections between client applications and servers. |
|
|
|
| Dynamic Skeleton Interface | The Dynamic Skeleton Interface (DSI) provides a mechanism for creating an object implementation that does not inherit from a generated skeleton interface. Normally, an object implementation is derived from a skeleton class generated by the idl2java compiler. DSI allows an object to register itself with the ORB, receive operation requests from a client, process the requests, and return the results to the client without inheriting from a skeleton class. |
|
|
|
| Enhanced idl2java compiler | The idl2java compiler includes its own Java-based preprocessor, which supports standard preprocessing arguments. |
|
|
|
|
|
|
| HTTP and CGI | The CGI/HTTP protocol is clumsy, stateless, and extremely slow-much slower than CORBA IIOP. Programming Internet client-server applications with CGI is a very poor choice. The bad news is that CGI is the premier three-tier client-server application model for the Internet today. The good news is that the leading Internet architects, well aware of CGI's shortcomings, are migrating to alternative technologies. Netscape will do its part by bundling a CORBA ORB with every browser. |
|
|
|
| RMI | First, RMI does not provide language-neutral messaging services. In other words, RMI objects can talk only to other RMI objects. With RMI, you cannot invoke objects written in other languages or vice versa. Second, RMI does not support dynamic invocations and interface repositories. Third, RMI does not provide a wire protocol for security and transactions. RMI is both proprietary and lightweight. It was not designed to interoperate with other ORBs or languages. Unlike CORBA's IIOP, RMI is not a suitable backbone for the Internet or intranets; it lacks services IIOP provides. |
|
|
|
| DCOM | A DCOM object is not an object in the object-oriented programming sense; a DCOM object does not have a persistent object reference that lets you reconnect to the same object at a later time. In other words, DCOM objects do not maintain state between connections. This can be a big problem in environments where you have faulty connections - for example, the Internet. The current implementation of DCOM does not support distributed naming services; it is based on the NT registry. Configuring DCOM and installing type libraries is tedious and labor-intensive. DCOM is also Windows-centric. Very few implementations of DCOM run on non-Windows platforms. Finally, for DCOM to scale on the server side, it requires the Microsoft Transaction Server (MTS). Microsoft has no immediate plans to port MTS to non-NT platforms. |
|
|
|
| RPC | With an RPC, you call a specific function (the data is separate). In contrast, with an ORB, you call a method within a specific object. Different object classes may respond to the same method call differently. Because each object manages its own private instance data, the method is implemented on that specific instance data. ORB method invocations are precise. The call gets to a specific object that controls specific data and then implements the function in its own class-specific way. In contrast, RPC classes have no specificity: all the functions with the same name are implemented the same way. |
|
|
|
We would also like to thank Robert Orfali for his contributions and editorial assistance.
For the latest technical information on Sun-Netscape Alliance products, go to: http://developer.iplanet.com
For more Internet development resources, try Netscape TechSearch.