Chapter 3 - Background On Related Technologies

3.1 Introduction

This project depends on two major technologies, CORBA and distributed file systems (CODA). In this section the features of each will be explain along with how they contributed to the project. Concluding this section will be a brief description of the other additional technologies, C++ and Java like threads for C++, that are used.

3.2 Key Underlying Technologies

3.2.1 CORBA

3.2.1.1 Overview

The CORBA platform was created by the Object Management Group (OMG) as a common method of communicating between applications without concern of who programmed them. CORBA relies on the Object Request Broker (ORB), which acts as the connecting layer between objects.

ORB architecture is similar to the idea of client/server. The client makes requests via stub code to another object in the system. The client doesn't necessarily run on the same computer that the method actually resides. The server handles the request via skeleton code. The skeleton code is the actual method that the client wants to use. The server will perform the method and then return the results to the client.

The Interface Definition Language (IDL) defines the interfaces that the client and server use to communicate. The IDL Compiler will then use these definitions to create the stub and skeleton code. The client uses the stub code to make remote procedure calls across the network. The skeleton code is used by the server to answer these remote procedure calls and return a response if applicable. How IDL works is best described by Andreas Vogel and Keith Duddy in their book titled, "Java Programming with CORBA":

"The IDL is used to generate programming language code that performs the tedious, error prone, and repetitive tasks of establishing network connections, translating data structures into byte streams (marshalling), locating object implementations, and invoking the right code to perform an operation. IDL is designed to specify the functionality of objects."¹³

The interesting feature about CORBA is that there doesn't necessarily have to be machines purely dedicated to act as a server or client. A machine can make a request and act as a client then process a request thereby act as a server.

The CORBA platform is a platform independent method of performing remote procedure calls similar to Remote Method Invocation (RMI) in Java. CORBA is better than JAVA in that it is not restricted to any particular programming language. The next version of CORBA, CORBA 3, will provide better support to this system in that it will provide the potential of real-time system performance.

Another feature used from CORBA is the OMG Naming Service. The Naming Service acts similar to a DNS server typically used in most computer networks. All hosts for a domain are listed in the DNS server with their associated IP address. As one computer needs to find another to obtain a service it first must determine its location in the network through the DNS server. CORBA works on a similar principle. Unlike DNS there are no records listed in the server as it starts. All clients wishing to be included for use register themselves with the Naming Service. ORBs can use the Naming Service to find the location of another object within the network by first determining its Interoperable Object Reference (IOR). The IOR "acts as a handle that uniquely identifies the target object and encapsulates all the information required by the ORB to send the message to the correct destination."¹⁴

Using the IOR an ORB can communicate with it to make a remote invocation. In regards to the Naming Service objects can register themselves by binding themselves. The Naming Service allows for a simple or elaborate data structure to exist within itself (see Figure 1 and 2 below). The data structure is setup up in a tree format. All information in this data structure is attached via branches providing a logical structure of the information and quick access. In this project there is only one context or descriptive element named DGCC.

Figure 1 - Name Service Tree

The project then adds either a master or slaves as leaves on the branch of DGCC when they bind themselves with the Naming Service.

Figure 2 - Name Service Tree with Leaves

3.2.1.2 Comparison between ORBacus and ACE+TAO

ORBacus is an implementation of the CORBA platform by IONA. It supports ORBs, Naming Service, Property Service, Event Service, Time Service and the bi-directional OCI plug in of the CORBA 2.3 platform standard. ¹⁵ As a whole it was an excellent implementation to learn how to use CORBA with quick support through a mailing list. At present the implementation could use a good package system for ease of installation.

ACE+TAO is another implementation of the CORBA platform. It supports ORBs, Time Service, Scheduling Service, Logging Service, Event/Notification Service, A/V Streaming, Trading Service, Naming Service, Concurrency Service and the Property Service. ACE+TAO is the best CORBA Library available because of its breadth of CORBA services and its level of CORBA standard compliance. The library as a whole is getting better to use but at the start of this project its learning curve was too steep. In the future the DGCC project will be shifting more towards this library as its discussed in Chapter 4.

Both libraries are good but ORBacus was chosen because it offered the services that this package needed and the support for learning how to use it was excellent. Choosing ORBacus allowed for more rapid development than before due Lancaster University Computer Science Department staff were more familiar with it.