Assessment

From what we learned from the previous sections we conclude that the transport layer used for ORB communication is not the limiting factor of the maximum upcall rate. Any message based IPC mechanism other than sockets can be used to achieve a slight improvement. Shared memory transport is not straightforward to include into the ORB core as the OMG architecture requires a connection oriented messaging layer. Wrapping shared memory into such an interface causes loss of efficiency when exchanging small messages because of the need for separate notification. When making intramachine calls with large parameter data it is recommended to separate control and data information: a method should be invoked using the ORB with a parameter that represents a reference to a shared memory region. The receiver can then access the data and operate on them without making a private copy. Concerning overall performance, we conclude that CORBA in its current specification and available implementations is not yet suited for intramachine communication or data acquisition systems. Some of the reasons can be summarised as follows:

• Limited invocation rate due to ORB demultiplexing and presentation layer processing overhead. Since with every upcall request received the ORB core has to process the protocol as specified by the OMG, a natural performance limitation is given although algorithms for selecting the requested servant do scale. The performed work includes walking through the parameter list, data conversion and copying of the parameters into the user application. A true zero-copy approach is hardly possible with CORBA as the wire format of the object invocation and its parameters has to be transformed into the concrete language mapping of the Interface Definition Language (IDL). This mapping is standardised and has to be followed in order to be compliant with the other ORB vendors. A study aiming at simplifying the wire format did not result in significant performance improvement (2%) (see appendix A.1). In addition the standard is violated. As long as certain ORB parts cannot be bypassed if they are not required, the upper performance limit will not be broken.

• Pluggable transport layer. Although choosing different transport layers did not result in substantial performance improvements it is vital to have the possibility of exchanging it. Data acquisition systems use dedicated networks to transfer data and control messages. These networks do not necessarily offer reliable connection oriented messages or the Internet protocol stack. Although CORBA does not require IP addressing scheme or the socket interface for communication we found it difficult to incorporate another IPC mechanism. TAO in its current version provides better support for this approach. Still, a major limitation remains: it is not possible to use several transport mechanisms concurrently in a single ORB. This is a requirement for environments like data acquisition, real-time or the embedded systems market. It must be possible for an ORB to accept an incoming request on one kind of network and forward it or make subsequent invocations on a different network. No current ORB to our knowledge provides this degree of openness. This thesis does not offer a solution to this problem. Up to this point, we could only identify the deficiency.

• Degree of complexity. CORBA is a standardised architecture, yet no recommendation on how it presents itself to the application programmer is given. Thus ORB implementations differ considerably in their programming interfaces. This complicates writing of maintainable software, especially in multi-platform environments. The IDL mappings to implementation languages aim to address this issue. As not all parts of the ORB architecture are specified in IDL the products differ in their usage. It seems therefore to be vital for future ORB implementations to have a standardised application interface as well. Specification of the Portable Object Adapter with all the policies and parameters is a step in this direction. Unfortunately CORBA does not have the notion of an object adapter in the client. This prohibits uniform configuration on both the sender and the receiver side.

Although not yet well suited for high performance interprocess communication or fast control systems, CORBA provides features that credits it for other applications, namely the management of the computing cluster:

• Language and system independence due to the use of IDL for defining interfaces.

• Good performance for computing bound servants due to multithreaded operation of the ORB server.

• Abstraction of location due to the use of portable object identifiers. As those can be obtained through name services or traders an extensible environment and transparent configuration management are provided.

We will explain the possibilities of CORBA for building a cluster management system in greater detail in chapter 6.3.

Although we have to face the fact that current ORB technology is not suitable for deployment in high-speed data acquisition system, the object-oriented communication paradigm is still applicable. It is a natural link between distributed object-oriented components. In the next chapter, we present a custom toolkit for remote object invocation. We apply what we have learned from the CORBA evaluation to shrink the performance gap between the application and the bare communication channel. Furthermore, we have learned that we have to take independence of the transport layer into consideration from the beginning on. Providing efficient models for concurrent server architectures will also be an issue that is tackled in the next chapter. It has to be included as we learned that the scaling of CORBA is also limited by it's concurrency policies.