Issue 1593: Obtaining a default ORB (java2idl-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of concern to the IDL-to-Java RTF because it affects the IDL-to-Java mapping. There are two places in the Java to IDL mapping spec that imply the use of a default ORB. One is the toStub method of the PortableRemoteObject class, and the other is the readObject method of the javax.rmi.CORBA.Stub class. It is not clear how we can obtain a suitable default ORB for use in these APIs without either excessive resource consumption (if we start a new ORB every time) or violating applet isolation boundaries (if we use the same ORB every time). Resolution: Closed, accepted Revised Text: Actions taken: June 29, 1998: received issue June 4, 1999: closed issue Discussion: There is a problem with implementing the deserialization of stubs and the PortableRemoteObject.toStub method. Both of these require an ORB object to which the returned stub object will be connected via its delegate. However, there is no well-specified way to obtain a suitable implicit ORB object in CORBA. In the case of stub deserialization, it is not possible to pass an explicit ORB object to the deserialization operation. In the case of toStub, we do not wish to add an explicit ORB object because this breaks the "portable RMI" programming model in which application code refers only to RMI types and not to CORBA types. Proposal: Deserialization of javax.rmi.CORBA.Stub creates an "unconnected" stub. Before being used, it must be connected to an ORB. This will happen automatically if the unconnected stub is written to a GIOP marshaling stream by being passed to javax.rmi.CORBA.writeRemoteObject or javax.rmi.CORBA.writeAbstractObject. However, in other cases, the stub must be connected explicitly. To enable this, the method void connect(ORB orb) throws RemoteException { ... } is added to the javax.rmi.CORBA.Stub class, and the method static void connect(java.rmi.Remote unconnected, java.rmi.Remote connected) throws RemoteException { ... } is added to the javax.rmi.PortableRemoteObject class. The Stub.connect method throws RemoteException if called on a stub that is already connected to an ORB (i.e., has a delegate set). Otherwise, a delegate is created for this stub and the specified ORB. This method is not intended to called directly by application code; instead, application code should call the PortableRemoteObject.connect method, which will in turn call the Stub.connect method. This allows the application code to remain portable between IIOP and JRMP. The PortableRemoteObject.connect method may take an RMI/IDL stub or an exported RMI/IDL implementation object as its "unconnected" and "connected" parameters. If "unconnected" is a connected object (i.e., an RMI/IDL CORBA stub with a delegate or an implementation object with an RMI/IDL tie that has been associated with an ORB), then a RemoteException is thrown. Similarly if "connected" is an unconnected object (i.e., an RMI/IDL CORBA stub without a delegate or an implementation object whose RMI/IDL tie has not been associated with an ORB), then a RemoteException is thrown. Otherwise, "unconnected" is connected to the same ORB as "connected" by setting its delegate if it is a stub or by associating its tie with an ORB if it is an implementation object. RMI/IDL implementation objects may be connected implicitly by being passed to javax.rmi.CORBA.writeRemoteObject or javax.rmi.CORBA.writeAbstractObject, or explicitly by means of the PortableRemoteObject.connect method. Connecting an implementation object is not the same as exporting it, and RMI/IDL implementation objects may be unconnected when first exported. RMI/IDL implementation objects are implicitly connected when they are exported to JRMP, and RMI-JRMP stubs are implicitly connected when they are created. The stub returned by PortableRemoteObject.toStub has the same connection status as the target implementation object passed to toStub. So if the target object is connected, the returned stub is connected to the same ORB. If the target object is unconnected, the returned stub is unconnected. The javax.rmi.CORBA.Stub.writeObject method writes the following data to the serialization stream: 1. int - length of IOR type id 2. byte[] - IOR type ID encoded using ISO 8859-1 3. int - number of IOR profiles 4. For each IOR profile: a. int - profile tag b. int - length of profile data c. byte[] - profile data End of Annotations:===== Return-Path: Date: Mon, 29 Jun 1998 14:38:29 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: java2idl-rtf@omg.org Cc: java-rtf@omg.org, issues@omg.org Subject: Obtaining a Default ORB This item arises from the Java-to-IDL Mapping RFP, but is also of concern to the IDL-to-Java RTF because it affects the IDL-to-Java mapping. There are two places in the Java to IDL mapping spec that imply the use of a default ORB. One is the toStub method of the PortableRemoteObject class, and the other is the readObject method of the javax.rmi.CORBA.Stub class. It is not clear how we can obtain a suitable default ORB for use in these APIs without either excessive resource consumption (if we start a new ORB every time) or violating applet isolation boundaries (if we use the same ORB every time). Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb