RMI-IIOP: Difference between revisions
Chriskraus1 (talk | contribs) clean up using AWB |
wiki link |
||
| Line 5: | Line 5: | ||
This standard was created to simplify the development of CORBA applications, while preserving all major benefits. RMI-IIOP is largely based on the [[CORBA#Objects by Value (OBV)|Object by Value concept]] that serves as a container or direct replacement for CORBA structures, unions, sequences, arrays and strings. The [[Interface description language|IDL]] is not used. Instead, the data structure definitions "supposed" automatically, collecting the necessary data via reflection mechanisms. When CORBA needs supplementary generated classes for each non trivial data structure being transferred, RMI-IIOP only uses the generated code for remote objects. Less generated code results in the smaller footprint. |
This standard was created to simplify the development of CORBA applications, while preserving all major benefits. RMI-IIOP is largely based on the [[CORBA#Objects by Value (OBV)|Object by Value concept]] that serves as a container or direct replacement for CORBA structures, unions, sequences, arrays and strings. The [[Interface description language|IDL]] is not used. Instead, the data structure definitions "supposed" automatically, collecting the necessary data via reflection mechanisms. When CORBA needs supplementary generated classes for each non trivial data structure being transferred, RMI-IIOP only uses the generated code for remote objects. Less generated code results in the smaller footprint. |
||
Both CORBA and RMI-IIOP use the same [[ |
Both CORBA and RMI-IIOP use the same [[General Inter-ORB Protocol]] communication standard. If required, it is possible to generate the [[Interface description language|IDL]] definitions for the involved RMI-IIOP data structures and use these definitions to arrange the interoperability between the RMI-IIOP and plain CORBA applications. |
||
The recent versions of RMI-IIOP derive their servants from the standard [[Servant (CORBA)]] class. Hence it is possible to connect them to the CORBA ORB manually, involving, if necessary, the Portable Object Adapter, Portable Interceptors, CORBA naming service and all other standard CORBA features. |
The recent versions of RMI-IIOP derive their servants from the standard [[Servant (CORBA)]] class. Hence it is possible to connect them to the CORBA ORB manually, involving, if necessary, the Portable Object Adapter, Portable Interceptors, CORBA naming service and all other standard CORBA features. |
||
Revision as of 09:17, 25 April 2009
 |
| This article provides insufficient context for those unfamiliar with the subject. |
RMI-IIOP (read as "RMI over IIOP") denotes the Java remote method invocation (RMI) interface over the Internet Inter-Orb Protocol (IIOP), which delivers Common Object Request Broker Architecture (CORBA) distributed computing capabilities to the Java 2 platform. Java RMI-IIOP was developed by Sun Microsystems and IBM, combining the best features of Java RMI technology with the best features of CORBA technology.
This standard was created to simplify the development of CORBA applications, while preserving all major benefits. RMI-IIOP is largely based on the Object by Value concept that serves as a container or direct replacement for CORBA structures, unions, sequences, arrays and strings. The IDL is not used. Instead, the data structure definitions "supposed" automatically, collecting the necessary data via reflection mechanisms. When CORBA needs supplementary generated classes for each non trivial data structure being transferred, RMI-IIOP only uses the generated code for remote objects. Less generated code results in the smaller footprint.
Both CORBA and RMI-IIOP use the same General Inter-ORB Protocol communication standard. If required, it is possible to generate the IDL definitions for the involved RMI-IIOP data structures and use these definitions to arrange the interoperability between the RMI-IIOP and plain CORBA applications.
The recent versions of RMI-IIOP derive their servants from the standard Servant (CORBA) class. Hence it is possible to connect them to the CORBA ORB manually, involving, if necessary, the Portable Object Adapter, Portable Interceptors, CORBA naming service and all other standard CORBA features.