1. CORBA
  2. ORBit
  3. Help


Question Answer
a.) How does a client connect to a server? This is a well known problem in CORBA (more precisely in any distributed object system). It is commonly known under the term "bootstrapping". In general, object references can be obtained from a Name Service (or a Trading Object Service), but a name service (thanks to the clear design of CORBA) is itself an object. So, how do you get the reference to the name service if it is itself an object ?

The standard solution for a client, finding a first object reference to a server is by exchanging an Interoperable Object Reference (IOR). The server process produces an IOR of the created object by using the method object_to_string(). The generated string, also called stringified object reference, can be transfered by any kind of media, like email, HTTP, NFS, filesystem, or even as a message in a bottle ;-) . The client process reads the IOR from the medium and converts it back into its binary representation via string_to_object(). Afterwards the client holds a valid object reference to the server and thus is able to invoke methods in the usual way.

Until now non-standard ways to solve this bootstrapping issue have been introduced by different ORBs. One example is the Visibroker Location Service. The ORB registers each object at a central service by a proprietary _bind() method. The discovery of the service is done by network broadcasts. The drawback of this mechanism is that the information about the objects is stored in a central table. The table needs to be updated on a regular basis. This is necessary because of malicious objects not cleanly deregistering. If the broadcast interval is to short the updates will cause a lot of noise on the network. If the interval is to long the table contains zombie objects. Such kind of proprietary solutions exists for many major CORBA implementations.

Ideally the method resolve_initial_references() could be used to find a reference to the naming service. Therefore the ORB must be able to read IORs without requiring the developer to write some additional code. In the past each ORB had its own command line parameters to pass IORs to the ORB's core (ORBit: ORBNamingIOR=IOR:.....). The Interoperable Naming Service (INS) specification (ptc/99-12-03) introduces the standardized command line parameter -ORBInitRef to achieve this.

yourclientapp -ORBInitRef NameService=IOR_of_naming_service
The only trick is to pass argc and argv to the ORB_init() call of the ORB, so that the ORB's core can extract the relevant parameters. Afterwards the call

nsobj = resolve_initial_references("NameService");
returns the desired object reference. The INS specification defines, besides the IOR, other human readable object references.
This offers the possibility for a client to point to a server object just by providing a human readable address. Another proposed naming scheme is corbaname, which refers to a naming service running on the host the, specified by hostname.
The a/b/obj specifies a Name, i.e. a sequence of NameComponents, which resolves to an object reference. These mechanisms will extremly improve the whole bootstrapping process and finally solve the problem, as it has been one of the most annoying issues in the past. There are are also a few critics of the human readable object reference corbaloc. They think that the fact of having opaque IORs is weakened by the INS specification. Specifying protocol details, like port numbers or protocol version numbers, can result in references to become invalid when the protocol, used for transportation is exchanged. The Object URLs have to be extended to support the new protocol information, whereas IORs always remain the same, a sequence of numbers.

The CVS HEAD version of ORBit has a partial implementation of the INS specification (see NameService).

Michi Henning has a more elaborate description of the problem here.
b.) How can I specify default parameters in IDL? IDL does not allow to specifiy default parameters. There are mainly two reasons for that. First, IDL is some kind of least common denominator of all the languages for which a CORBA mapping is available. Many languages do not support the concept of default parameters and thus have difficulties in supporting this feature in the mapping. And second, default parameters are not really necessary. The designer of an interface can easily split such funtionality into two or more separate methods (Attention: Overloading is not supported for the same reasons, so that methods must have different names).
c.) How can I get the IP address of a cient/server object in CORBA? The IP address (as well as the port number or any other protocol related feature) is hidden in the IOR (Interoperable Object Reference). The reason for this opacity is that CORBA can use any protocol for transportation of requests between object instances. The GIOP (General Inter ORB Protocol) is independent from any special network protocol. The IIOP (Internet Inter ORB Protocol) is a translation of GIOP into TCP/IP. IIOP support is not a mandatory feature of an ORB, but because of the Internet it has become a must for any ORB to implement. If we start relying on the presence of a specific protocol the original intention becomes weakened and may render object references, valid today, invalid in the future. (see TAO (The ACE ORB, ACE - Adaptive Communication Environment) for an ORB which supports pluggable protocols)

Back to top

2. ORBit

Question Answer
a.) How can I install a version of ORBit without affecting my GNOME desktop ? Configure the package with the following command:
./configure --prefix=~/orbit_test_dir --exec-prefix=~/orbit_test_dir
Where orbit_test_dir is an arbitrary subdirectory. Then call make and make install, which will copy ORBit to the specified directory. Finally you just need to adapt your PATH and LD_LIBRARY_PATH environment variables by adding ~/orbit_test_dir/bin to PATH and ~/orbit_test_dir/lib to LD_LIBRARY_PATH respectively.
b.) I can't connect to my remote objects ? A GNOME security discussion led to disabling IIOP over IP server sockets (i.e. ports) per default. Instead either UNIX domain sockets or shared memory for interprocess communication are used. This disables communcation over the network but prevents the system from Denial of Service attacks. If you want to use ORBit over the network you need to turn it on again. This can either be done in /etc/orbitrc (system-wide settings), in ~/.orbitrc (user's settings), or on a per application basis by passing a parameter to the ORB. For Solution one and two you need to put ORBIIOPIPv4=1 into one of the orbitrc files. Controlling the settings for each application can be done by providing ORBIIOPIPv4=1 at the command-line to your client/server application and passing the argc and argv parameters to the CORBA_ORB_init() call (default-handling).
You can check the setting with the command: netstat -ao | grep LISTEN. You should not have any orbit related sockets in listen mode (a line: "unix 0 [ ACC ] STREAM LISTENING XXXX /tmp/orbit-USER/orb-YYYYYYYYYYYYYYYY" should not appear)
c.) Where can I get the CVS HEAD version of ORBit? The gnome developer site has a description on how to use the anonymous CVS access. After logging on you just need to type "cvs -z3 co ORBit", whereas "ORBit" is the name of the module.
ATTENTION: The HEAD version stops the autobuild process with the message "This branch of ORBit is deprecated. Don't use it.". The HEAD version is no longer supported because all the efforts have moved to the new ORBit2 project. When Kennard White quit working on the project, all the changes he made to ORBit HEAD became a dead end because there was nobody willing to support the stuff. Most of the features have been taken over to the ORBit2 project.
d.) What is the difference between the CVS version and the GNOME package? The Roadmap for GNOME version 1.x requires ORBit to be binary and source-code compatible. Therefore updates on the ORBit package are accepted as long as these requirements are not violated. The stable branch is orbit-stable-0-5, new features have been added to CVS HEAD by Kennard White until he left the project. His contributions are mostly taken over to the new ORBit2 project.
e.) Which parameters are supported by CORBA_ORB_init() ? CORBA parameters (defined by the INS/Core spec; only available in the CVS HEAD version of ORBit)
  • -ORBid<ORBIdentifier>
    Identifier which selects the ORB to use (ORBit stable and ORBit HEAD support only "orbit-local-orb"; ORBit-mt must be used with "orbit-local-mt-orb").
  • -ORBInitRef ObjectId=<IOR|corbaloc URL|corbaname URL>
    Initial Reference. See INS/CORBA2.4 spec. for further information.
  • -ORBDefaultInitRef <corbaloc URL|corbaname URL>
    Initial Reference Prefix. See INS/CORBA2.4 spec. for further information.
ORBit specific parameters (available in CVS HEAD and the ORBit-stable-0-5 branch):
  • ORBImplRepoIOR=<IOR>
    IOR of Implementation Repository; deprecated by standardized parameter above.
  • ORBIfaceRepoIOR=<IOR>
    IOR of Interface Repository; deprecated by standardized parameter above.
  • ORBNamingIOR=<IOR>
    IOR of Naming Service; deprecated by standardized parameter above.
  • ORBDebugLevel=warning|message|info|debug|all
    The amount of debugging information to display. The levels "warning", "message", "info", "debug" can be combined by using , ":" as separator. "all" can be used to select maximum verbosity.
  • ORBDebugModules=ORB|CDR|IIOP|TC|IR
    The modules from which to display debugging information.
  • ORBIIOPUSock=0|1
    Disable/Enable UNIX domain sockets.
  • ORBIIOPIPv4=0|1
    Disable/Enable IPv4 server sockets.
  • ORBIPv4Port=#port
    Number of port to listen for IIOP connections. This parameter is required for persistent object references (PortableServer_PERSISTENT policy).
  • ORBIIOPIPv6=0|1
    Disable/Enable IPv6 sockets.
f.) When and who started the project? The project was started by Elliot Lee and Dick Porter around February 1998.
g.) Why is the IOR from ORB XYZ not understood by ORBit? Check whether the IOR has some whitespaces at the end. ORBit version below 0.5.x does not accept IORs with trailing whitespaces.

Back to top

3. Help

Question Answer
a.) Is there a mailing list HOWTO? The mailing-list demon provides a short description on how to use it. Send an e-mail to orbit-list-requestNOSPAM@gnome.org with subject "help".
b.) How can I subscribe to the mailing list? Go to mail.gnome.org/mailman/listinfo/orbit-list/.
c.) How can I unsubscribe from the mailing list? Go to mail.gnome.org/mailman/listinfo/orbit-list/.
d.) How can I send an e-mail to the mailing list? Send e-mail to orbit-list@NOSPAMgnome.org.
e.) Is there a mailing list archive? There is a searchable archive available on mail.gnome.org/archives/orbit-list/, but it does not (yet) include mails before august 2000.
The following mailing-list archive packages are available for download: The complete archive package: orbit-list-archive.tar.gz (2112 kB)

The Perl scripts used to retrieve the mails can be found on: ftp://orbit-resource.sourceforge.net/pub/orbit-resource/spin-off/
f.) I'm new to CORBA. What books are available? There are a lot of books available. The major online stores have ratings and comments of almost any CORBA book on the market.
  1. CORBA books at fatbrain
  2. CORBA books at TU Vienna (2000)
  3. Cetus' CORBA - Books
  4. JavaWorld's CORBA books
One of the best books is Michi Henning's and Steve Vinoski's book: "Advanced CORBA Programming with C++" (ISBN 0-201-37927-9). Although the title seems to address only for C++ programmers it contains explanations of many fundamental concepts and is thus useful for a general understanding.
g.) Which CORBA newsgroups are available?
  1. General CORBA questions: comp.object.corba
  2. Java CORBA questions: comp.lang.java.corba

Back to top

Back Home

Page created by Michael Rumpf.