The source code can be downloaded as a gzipped .tar-file.
This is the fourth and final part of the CORBA tutorial which implements a distributed object system. This example expands the previous example two and demonstrates the Naming service, a way to locate distributed objects in the network.
The source code has been developed and tested using the mico ORB on MacOS X. On other systems, the Makefile(s) may need to be adjusted properly. The files can also be downloaded on the software section of this site.
Up to now we have not bothered about the “boilerplate” initialization code at the beginning of either the client and the server. When we look a little closer we see that it consists of two parts: first, the ORB itself is initialized, then an entity labeled POA (Portable Object Adapter) is setup. The latter proceeds by using a control file called
ior.dat contains information like the TCP/IP address, port number etc. about the service. IOR is the abbreviation for Interoperable Object Reference, a piece of data that uniquely identifies a service in the network. It is written by the server and subsequently read by the client.
Thus, in order to connect clients to servers, the control file needs to be passed around. While this has been done in the initialization section of each program so far, we will now look into a frequently used alternative that can be used to pass around the IOR without the need of additional network services.
Control files limit the general applicability of an object; either one needs a distributed file system or it is necessary to pass that file around by “some other means”. For a large enterprise such a system can quickly become cumbersome. CORBA offers a solution — while the IOR is still needed to match clients and servers, it need not be passed around as a file. Instead, it can be provided by a CORBA service called Naming service. The Naming service essentially stores the IOR under a name (similar to a single-purpose distributed file system) and makes it available to all clients on the network.
The cool thing about this setup is that the Naming service is just like any CORBA service, i.e. all the infrastructure to talk to it is already in place if a valid CORBA implementation got to this point. The downside is that in order to talk to the Naming service, some way of calling it must be in place and that way should better be independent of IORs!
The way mico ORB solves this problem is by passing a human-readable URL around which contains the TCP/IP address, the port number and an ID identifying the Naming service server. This is similar to a raw IOR, but can actually be typed by a user at the command line. Once communication to the Naming service is established, a file-system-like CORBA server matches up IORs with names. Thus, any server can store its IOR under a given name and any client can retrieve it as long as it knows the name.
While the specific interface of the CORBA Naming service is beyond the scope of this introduction – good documentation can be found e.g. on CORBA explained simply – it is instructive to take a closer look at the work flow that the server
This work flow will make sure that clients can connect to the server as soon as they manage to connect to the Naming service. Hence, looking at the client
client.cc, we identify the following elements:
The rest of the code,
protocol_impl.h stays the same. I have added the specific commands (see below) to run the server and the client on the local host to the
Makefile as a reminder.
The setup is slightly more complicated now since we need to start the server that provides the Naming service first. Unfortunately, this is vendor specific and the exact calling convention depend on the implementation used. Again, we stick with the mico ORB and use different processes on the localhost (IP:
127.0.0.1, port: 12456) to run the client and the server.
Putting everything together the command for starting both the Naming service and the
Protocol server becomes:
$ nsd -ORBIIOPAddr inet:127.0.0.1:12456 & $ ./server -ORBInitRef \ NameService=corbaloc::127.0.0.1:12456/NameService
The client also needs to be notified of the Naming service in the same way as the
$ ./client -ORBInitRef \ NameService=corbaloc::127.0.0.1:12456/NameService \ "Hello, world."
Note that the line that initializes the ORB “consumes” the parameters leading to the initialization. Put into practice, the working example looks like this:
Again, the functionality stays the same as in the previous two examples. The flexibility, however, has increased notably since all we need to do now is to make sure the network routing and firewalls are properly configured; we do not need to worry about the file
This part concludes our example codes for CORBA. You can return to the CORBA overview to read about some of the more advanced aspects or to study further literature on the subject.
Imprint / Impressum
© 1997-2013 Dr. Wolfram Schroers. This site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Additional permissions available at http://www.field-theory.org/editorial/index.html.
Wolfram is a leading software engineer focused on Enterprise and B2B apps on iOS. His clients rank from small independent studios to companies in the German DAX index.
He has worked at top Universities on three continents in the past decade and is a popular speaker at conferences. He is currently working in Berlin, Germany, and can be reached at his company website.