CORBA and Java technologies - JDK 5 Documentation v1.4.1, Java 2 SDK 英文文档

CORBA Technology and the Java^TM 2 Platform, Standard Edition

The Java 2 Platform, Standard Edition, v1.4, provides an Object Request Broker (ORB) and two CORBA programming models that can utilize the Java CORBA ORB and Internet InterORB Protocol (IIOP). This topic discusses these options for creating and distributing CORBA technology.

CORBA technology is an integral part of the Java 2 platform. It consists of an Object Request Broker (ORB), APIs for the the RMI programming model, and APIs for the the IDL programming model.

For more information on which specifications are implemented in this release of the Java platform, see the compliance document.

How does J2SE leverage CORBA

Common Object Request Broker Architecture (CORBA) technology is the open standard for heterogeneous computing. CORBA complements the Java^TM platform by providing a distributed object framework, services to support that framework, and interoperability with other languages. The Java platform complements CORBA by providing "Write Once, Run Anywhere^TM" portability, a highly productive implementation environment, and a very robust platform. By combining the Java platform with CORBA and other key enterprise technologies, the Java 2 Platform is the ultimate platform for distributed technology solutions.

CORBA standards provide the proven, interoperable infrastructure to the Java platform. IIOP (Internet Inter-ORB Protocol) manages the communication between the object components that power the system. The Java platform provides a portable object infrastructure that works on every major operating system. CORBA provides the network transparency, Java provides the implementation transparency.

The Object Request Broker

An Object Request Broker (ORB) is part of the Java 2 Platform, Standard Edition, since version 1.3. The ORB is a runtime component that can be used for distributed computing using IIOP communication.

NOTE: Although it is true that ORBs written in different languages should be able to talk to each other, we haven't tested the interoperability of the Java ORB with other vendor's ORBs.

The Object Management Group (OMG) is an industry consortium that creates and publishes specifications for CORBA. Vendors implement the specifications to produce products known as Object Request Brokers (ORB). The good news for developers is that the Java^TM Standard Edition, v1.2 and higher includes an ORB that is available in every deployment of the Java 2 Platform, Standard Edition. To read more about the ORB class, follow the link.

The Java CORBA ORB supports both the RMI and IDL programming models, both of which can use the underlying IIOP wire-level protocol for communication.

Introducing the CORBA Programming Models

History of the CORBA Programming Models

In 1997, Remote Method Invocation, or RMI, was introduced in JDK 1.1. Initially, RMI was positioned as a natural outgrowth of Remote Procedure Calls (RPC), strictly for enabling calls to be made between Java objects in different virtual machines, and even on different physical machines.

In 1998, came JDK 1.2, which introduced Java IDL, a Java API for interoperability and integration with CORBA. Java IDL included both a Java-based ORB, which supported IIOP, and the IDL-to-Java compiler, idltojava, for generating client-side stubs and server-side code skeletons. The ORB supports both the RMI over IIOP and Java IDL programming models.

In 1999, the RMI over IIOP standard extension to the Java platform was introduced for JDK 1.1.6 and 1.2. Now that RMI over IIOP is integrated into J2SE version 1.3 and higher, the optional download has been end-of-lifed, but is still available from the archives.

The OMG finalized modifications of its IIOP specification so that it would support most of the JDK 1.1 functionality of RMI. RMI over IIOP was introduced as a standard extension to JDK 1.2. This enabled remote objects written in the Java programming language to be accessible from any language via IIOP.

J2SE, v.1.3 introduced a new, 100% Pure Java^TM, IDL-to-Java compiler, idlj, along with support for IDL abstract interfaces and value types. Also in v.1.3, RMI over IIOP is included in the JDK.

J2SE v.1.4, the current version, was introduced in 2001, and includes support for the Portable Object Adapter, Portable Interceptors, Interoperable Naming Service, GIOP 1.2, and Dynamic Anys. J2SE v.1.4 also includes an Object Request Broker Daemon (ORBD), which is used to enable clients to transparently locate and invoke persistent objects on servers in the CORBA environment, and servertool, which provides a command-line interface for application programmers to register, unregister, startup, and shutdown a persistent server. For more information on new features in J2SE v.1.4, see Changes in CORBA Features Between J2SE 1.3 and 1.4.

Comparing the CORBA Programming Models

Cross-language, cross-vendor interoperability is achieved via the Internet InterORB Protocol, or IIOP. IIOP is a transport protocol for distributed applications written in either IDL or Java RMI.

When using the IDL programming model, the interface is everything! It defines the points of entry that can be called from a remote process, such as the types of arguments the called procedure will accept, or the value/output parameter of information returned. Using IDL, the programmer can make the entry points and data types that pass between communicating processes act like a standard language.

CORBA is a language-neutral system in which the argument values or return values are limited to what can be represented in the involved implementation languages. In CORBA, object orientation is limited only to objects that can be passed by reference (the object code itself cannot be passed from machine-to-machine) or are predefined in the overall framework. Passed and returned types must be those declared in the interface.

With RMI, the interface and the implementation language are described in the same language, so you don't have to worry about mapping from one to the other. Language-level objects (the code itself) can be passed from one process to the next. Values can be returned by their actual type, not the declared type. Or, you can compile the interfaces to generate IIOP stubs and skeletons which allow your objects to be accessible from other CORBA-compliant languages.

The RMI Programming Model

What is the RMI Programming Model

The RMI Programming model is a general object model for distributed computing via the rmi API. You can choose to work completely within the Java programming language, using the Java Remote Method Protocol (JRMP) or work with other CORBA-compliant programming languages using the Internet InterORB Protocol (IIOP).

The RMI programming model is part of the Java^TM 2 Platform, Standard Edition, and consists of both an Object Request Broker (ORB) and the rmic compiler. The rmic compiler is used to generate stubs, skeletons, and ties for remote objects using either the JRMP or IIOP protocols. The rmic compiler can also generates OMG IDL. For more information on using rmic, link to rmic - The Java RMI Stub Compiler.

The RMI over IIOP Programmer's Guide discusses the differences between using RMI with JRMP or IIOP.

When should I use the RMI programming model instead of the IDL programming model?

The RMI programming model speeds distributed application development by allowing developers to work completely in the Java programming language. When using the RMI programming model to produce Java technology-based distributed applications, there is no separate Interface Definition Language (IDL) or mapping to learn. The RMI programming model provides flexibility by allowing developers to pass any serializable Java object (Objects By Value) between application components. Like the IDL programming model, the RMI programming model is based on open standards defined with the participation of hundreds of vendors and users in the Java Community Process (JCP). Like the IDL programming model, the RMI programming model can use the Internet Inter-ORB Protocol (IIOP) as its communication protocol. IIOP eases legacy application and platform integration by allowing application components written in C++, Smalltalk, and other CORBA supported languages to communicate with components running on the Java platform.

With the RMI programming model, developers can write remote interfaces in the Java programming language and implement them simply using Java technology and the Java RMI APIs. These interfaces can be implemented in any other language that is supported by an OMG mapping and a vendor supplied ORB for that language. Similarly, clients can be written in other languages using IDL derived from the remote Java technology-based interfaces.

Where can I found out more about the RMI programming model

For more information on RMI over IIOP, see RMI over IIOP Documentation.
For more information on RMI over JRMP, see RMI Documentation.
For an introductory tutorial using RMI over IIOP, see Tutorial: Getting Started with RMI over IIOP.
For more information on mapping Java interfaces to OMG IDL, see Java Language to OMG IDL Mapping Specification.

The IDL Programming Model

What is the IDL Programming Model

The IDL programming model, known as Java^TM IDL, consists of both the Java CORBA ORB and the idlj compiler that maps the OMG IDL to Java bindings that use the Java CORBA ORB, as well as a set of APIs, which can be explored by selecting the org.omg prefix from the Package section of the API index.

Java IDL adds CORBA (Common Object Request Broker Architecture) capability to the Java platform, providing standards-based interoperability and connectivity. Java IDL enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard IDL (Object Management Group Interface Definition Language) and IIOP (Internet Inter-ORB Protocol) defined by the Object Management Group. Runtime components include a Java ORB for distributed computing using IIOP communication.

To use the IDL programming model, you define remote interfaces using the Object Management Group's (OMG) Interface Definition Language (IDL), then compile the interfaces using the idlj compiler. When you run the idlj compiler over your interface definition file, it generates the Java version of the interface, as well as the class code files for the stubs and skeletons that enable your applications to hook into the ORB.

Java^TM IDL is part of the Java 2 Platform, Standard Edition, v1.2 and above. To develop applications with Java IDL, use Java^TM IDL Compiler, idlj, which is included in every installation of J2SE v1.3 and higher.

When should I use the IDL programming model instead of the RMI programming model?

The OMG IDL (Interface Definition Language) is a purely declarative language designed for specifying programming-language-independent operational interfaces for distributed applications. OMG specifies a mapping from IDL to several different programming languages, including Java, C, C++, Lisp, Python, Smalltalk, COBOL, and Ada. When mapped, each statement in OMG IDL is translated to a corresponding statement in the programming language of choice. Java IDL is an implementation of the CORBA specification. For example, you could use the Java IDL Compiler, idlj, to map an IDL interface to Java and implement the client class in Java. If you map the same IDL to C++, using an IDL-to-C++ compiler and a C++ ORB, and implement the server in that language, the Java client and C++ server interoperate through the ORB.

NOTE: Although it is true that ORBs written in different languages should be able to talk to each other, we haven't tested the interoperability of the Java ORB with other vendor's ORBs.

Where can I find out more about the IDL programming model

For more information on the IDL programming model, see Java IDL Documentation.
For an introductory tutorial to the IDL programming model, see Tutorial: Getting Started with Java IDL .
For more information on how IDL maps to the Java language, see see the OMG IDL to Java Language Mapping Specification.

Comparison of IDL and RMI programming models

There are several scenarios that will define how you will want to create distributed CORBA applications. Here are some of them:

If you have been developing CORBA applications using IDL for some time, you will probably want to stay in this environment. Create the interfaces using IDL, and define the client and server applications using the Java programming language to take advantage of its "Write Once, Run Anywhere^TM" portability, its highly productive implementation environment, and its very robust platform.
If all of your applications are written in the Java programming language, you will probably want to use Java RMI to enable communication between Java objects on different virtual machines and different physical machines. Using Java RMI without its IIOP option leverages its strengths of code portability, security, and garbage collection.
If you are writing most of your new applications using the Java programming language, but need to maintain legacy applications written in other programming languages as well, you will probably want to use Java RMI with its IIOP compiler option.

What about CORBA and J2EE?

In addition to Java IDL and RMI over IIOP, J2EE includes Enterprise JavaBeans^TM technology (EJB^TM).

Enterprise JavaBeans is part of the Java 2 Platform, Enterprise Edition. The EJB server-side component model simplifies development of middleware components that are transactional, scalable, and portable. EJB servers reduce the complexity of developing middleware by providing automatic support for middleware services such as transactions, security, database connectivity, and more.

EJBs use RMI over IIOP for their distributed object model, and use the Java Transaction Service (JTS) for their distributed transaction model. When Enterprise JavaBeans are implemented using the RMI over IIOP protocol for EJB interoperability in heterogeneous server environments, the standard mapping of the EJB architecture to CORBA enables the following interoperability:

A Java client using an ORB from one vendor can access enterprise beans residing on an EJB server provided by another vendor.
Enterprise beans in one EJB server can access enterprise beans in another EJB server.
A non-Java platform CORBA client can access any enterprise bean object.

Java Software