april, 2017 using corba
TRANSCRIPT
Author
Melanie Donabauer, BSc
Submission
Department of
Telecooperation
Thesis Supervisor
Univ.-Prof. Dr. Gabriele
Anderst-Kotsis
April, 2017
DEVELOPING AN
APPLICATION
INFRASTRUCTURE
USING CORBA
Evaluation and Prototypical Implementation
Master’s Thesis
to confer the academic degree of
Diplom-Ingenieurin
in the Master’s Program
Computer Science
JOHANNES KEPLER
UNIVERSITY LINZ
Altenberger Str. 69
4040 Linz, Austria
www.jku.at
DVR 0093696
2
Abstract
In real-time systems, executions of programs depend on a given timing constraint. Real-time APIs
allow to define the starting time, set the deadline for acquiring results, and specify periodic execution.
Distributed systems consist of components which may be located on different nodes in a network.
Therefore, distributed object computing (DCE) technologies are required to handle all method
invocations uniformly regardless of whether they are accessed on local or remote objects.
This thesis focuses on the Common Object Request Broker Architecture (CORBA) which is a
middleware for real-time distributed object computing. The CORBA standard was specified by the
Object Management Group (OMG). There are a lot of CORBA implementations available (open-source
and commercial), which makes it difficult to determine the CORBA implementation that fits the
requirements of a system best. This work presents an evaluation on various CORBA implementations.
For that purpose, a list of criteria is elaborated that covers a company’s as well as personal requirements.
The criteria are used to evaluate some of the existing CORBA implementations. In doing so, suitable
CORBA implementations are determined and are then further evaluated by implementing a prototype
and measuring the performance.
3
Kurzfassung
In Real-Time Systemen sind Ausführungen von Programmen von einer gegebenen
Zeitbeschränkung abhängig. Real-Time APIs erlauben die Definition einer Startzeit, das Setzen einer
Deadline, um Ergebnisse zu erhalten, und das Spezifizieren von periodischen Ausführungen.
Verteilte Systeme bestehen aus Komponenten, die sich auf unterschiedlichen Knoten in einem
Netzwerk befinden können. Daher werden Technologien für Distributed Object Computing (DCE)
benötigt, um Methodenaufrufe einheitlich zu behandeln, unabhängig davon, ob diese auf lokalen oder
entfernten Objekten zugegriffen werden.
Diese These behandelt die Common Object Request Broker Architecture (CORBA), die eine
Middleware für Real-Time Distributed Object Computing ist. Der CORBA Standard wurde von der
Object Management Group (OMG) spezifiziert. Es existieren viele unterschiedliche CORBA
Implementierungen (Open-Source und Kommerzielle), daher ist es schwierig, eine CORBA
Implementierung zu finden, die den Anforderungen an das System gerecht wird. Diese Arbeit präsentiert
die Evaluierung von unterschiedlichen CORBA Implementierungen. Für diesen Zweck wurden
Kriterien erarbeitet, die die Anforderungen eines Unternehmens aber auch Persönliche abdecken. Die
Kriterien werden zur Evaluierung von existierenden CORBA Implementierungen verwendet. Es werden
passende CORBA Implementierungen bestimmt und näher evaluiert, indem ein Prototyp entwickelt und
die Performance gemessen wird.
4
Contents
1 Introduction ....................................................................................................................... 6
1.1 Issues of the Current System ........................................................................................... 6
1.2 Real-Time Systems .......................................................................................................... 7
1.3 Real-Time Distributed Object Programming APIs ......................................................... 8
1.3.1 Distributed Real-Time Specification for Java ......................................................... 8
1.3.2 Time-triggered Message-triggered Object ............................................................... 9
1.4 Structure ........................................................................................................................ 10
2 Related Work ................................................................................................................... 11
3 Approach .......................................................................................................................... 16
3.1 Real-Time CORBA ....................................................................................................... 17
3.1.1 Definition of CORBA ............................................................................................ 17
3.1.2 Middleware ............................................................................................................ 18
3.1.3 Object Request Broker .......................................................................................... 19
3.1.4 CORBA Architecture ............................................................................................ 20
3.1.5 CORBA Real-Time Extension .............................................................................. 23
3.2 Criteria Elaboration ....................................................................................................... 25
3.3 Selection of CORBA Implementations ......................................................................... 27
3.4 Criteria Evaluation......................................................................................................... 27
3.4.1 Results of the Criteria Evaluation .......................................................................... 28
3.4.2 CORBA Implementations ..................................................................................... 30
3.4.2.1 The ACE ORB (TAO) ..................................................................................... 30
3.4.2.2 omniORB ......................................................................................................... 34
3.4.2.3 MICO IS CORBA (MICO) .............................................................................. 37
3.4.2.4 VisiBroker ........................................................................................................ 39
3.5 Development of the Reference Implementation ............................................................ 40
3.5.1 Setting up the Testing System ............................................................................... 41
5
3.5.1.1 Computer Hardware ......................................................................................... 41
3.5.1.2 Xubuntu and the RT-Preempt Patch ................................................................. 42
3.5.1.3 Comedi and Arduino ........................................................................................ 43
3.5.1.4 HALCON ......................................................................................................... 44
3.5.2 Application Use Case Scenario ............................................................................. 45
3.5.3 Development of Reference Implementation without CORBA .............................. 46
3.5.3.1 Qt ...................................................................................................................... 47
3.5.3.2 Development of Reference Implementation with Qt ....................................... 47
3.5.4 Development of Reference Implementation using CORBA.................................. 49
3.5.4.1 Interface Definition Language ......................................................................... 50
3.5.4.2 IDL Compiler ................................................................................................... 53
3.5.4.3 Programming Language Mapping .................................................................... 53
3.5.4.4 Servant.............................................................................................................. 56
3.5.4.5 Client and Server Application .......................................................................... 58
3.6 Performance Evaluation ................................................................................................ 62
3.6.1 Measuring the Performance ................................................................................... 62
3.6.1.1 Benchmark System ........................................................................................... 63
3.6.1.2 Performance Results ......................................................................................... 66
3.6.2 Performance Optimization ..................................................................................... 74
3.6.2.1 Collocation ....................................................................................................... 76
3.6.2.2 Pluggable Protocols .......................................................................................... 80
4 Conclusion and Future Work ......................................................................................... 85
4.1 Conclusion ..................................................................................................................... 85
4.2 Future Work .................................................................................................................. 86
References .................................................................................................................................. 87
List of Figures ............................................................................................................................ 92
List of Tables ............................................................................................................................. 93
Lebenslauf .................................................................................................................................. 94
Eidesstattliche Erklärung ......................................................................................................... 95
6
1 Introduction
This master’s thesis dwells on the evaluation and prototypical development of reference
implementations using CORBA in order to identify a suitable technology for the adaption of an existing
system. This section describes the issues of the system and elaborates the objectives of this master’s
thesis. CORBA is a technology for real-time distributed object computing. This section provides a brief
overview on distributed real-time systems. Of course, there are other approaches for real-time distributed
APIs besides CORBA. They are examined in this chapter to identify the differences to CORBA and
highlight why they are not suitable for the adaption of the system.
1.1 Issues of the Current System
The image processing department of voestalpine Stahl plans to renew an existing image
processing system. In a simplified view, it consists of a camera and an image processing component.
The camera frequently takes images of steel slabs which are processed and interpreted by applying
specific image filters on them. The system is used for assuring the quality of the steel slabs. Additionally,
it supports the responsible employees in achieving knowledge about their respective process. The
software was developed in C++ and makes use of the open-source library Qt.
One of the main issues of the current software is that it does not support real-time capabilities.
This is an essential aspect because the system cannot guarantee that the image processing is completed
before a given deadline, e.g., it could be interrupted by a software update by the IT department. The
architecture of the current system is not built component-based. Therefore, it is not possible for external
project partners to simply extend the system without getting access to the complete source code. It is
desirable to develop an application that allows external project partners to develop their own components
by providing them only with parts of the source code. These components could then simply be added to
the system.
OMG’s middleware Real-Time CORBA fulfills those requirements. It does not only provide real-
time capabilities but also supports distributed object computing which is of advantage if computationally
intensive operations need to be swapped out to high-performance computers. Another benefit of
CORBA is that it enforces component-based development of applications which enables external
partners to extend the software by only having access to the interface.
The main objective of this master’s thesis is to determine whether CORBA is a suitable
technology for the given requirements and tasks. For that purpose, a research on existing CORBA
7
implementations is conducted. Each of them is evaluated regarding specific criteria like the quality of
the documentation, the programming language, etc. The CORBA implementations that seem to be most
appropriate are then further evaluated by developing reference implementations. These implement a
representative example of an image processing step using CORBA. Their performances are then
measured and compared to the performance of a monolithic system to identify the overhead that is
induced by CORBA.
1.2 Real-Time Systems
In real-time systems executions depend on a given timing constraint [1], e.g., the application must
process a request and return the results before a specific deadline. Real-time systems need to offer end-
to-end support for Quality of Service (QoS) like latency, jitter, dependability, throughput guarantees,
scalability, availability, etc. [2]. In real-time systems, all QoS properties must be guaranteed at the same
time. Predictability is more important than high speed and high performance. In other words, it is
sufficient to know that a given timing constraint is met. Typically, real-time systems provide availability
during a specific interval of time and respond to any incoming inputs [3].
A real-time application comprises a set of tasks for which timing constraints can be defined in
three different ways. It can be specified that a task may not start before a specific absolute time. A task
can also be constrained so that it must start before a given absolute time. The third timing constraint is
the definition of a deadline in which a task must be completed. Tasks can either be periodic or aperiodic.
Periodic tasks are specified by their earliest start time and their deadline and are repeated in regular time
intervals. Aperiodic tasks have a deadline and may be executed at irregular times.
Real-time systems are distinguished by hard and soft real-time constraints. If hard real-time
systems do not meet their timing constraints it might lead to fatal consequences. This is especially true
for life-critical systems, e.g., nuclear systems or anti-lock braking system. Those systems usually have
a short latency, i.e., the time between a triggering event and the beginning or completion of a response
[4]. For soft real-time systems, there are usually no further consequences involved if the system violates
the given timing constraints and it continues to function properly. The software is usually programmed
in a way to compensate for missed timing constraints [5].
There exist specific scheduling algorithms for real-time systems. Each task is assigned a priority
which determines their order in the schedule. Whenever a scheduling decision is made the task with the
highest priority is given the resource next. A typical problem that occurs during scheduling tasks that
access shared resources is priority inversion. It occurs if a task with a higher priority requests a resource
8
that is currently occupied by a lower priority task. The higher priority task is then obliged to wait until
the lower priority task releases the shared resource [6].
1.3 Real-Time Distributed Object Programming APIs
As already mentioned, Real-Time CORBA is an Application Programming Interface (API) that
supports both real-time capabilities and distributed object programming. Real-time distributed object
programming approaches specify both how distributed components interact with each other and the
timing constraints of tasks [6]. They usually hide low-level features like priorities, threads, and processes
from the developer. Such APIs isolate network-related features, the operating system, and hardware-
dependent features, so that the developer is not responsible for handling them. They take care of
scheduling and executing resources like CPU, network, and memory [7]. Therefore, the developer is
able to focus on the development of the application without managing network or QoS related features.
Distributed real-time APIs handle the execution of method invocations uniformly regardless of whether
they are accessed on local or remote objects. They also support non-blocking invocation of object
methods, i.e., the client calls a server method and can proceed with the following tasks without waiting
for the return of the results. Real-time distributed object programming APIs allow to concurrently
execute server methods that do not interfere with each other.
There are a few APIs available that are similar to Real-Time CORBA. This section dwells on
different approaches for real-time distributed object programming technologies. One of the approaches
is the distributed real-time specification for Java (DRTSJ) [8]. There is also the time-triggered message-
triggered object (TMO) technology that is rather promising for the development of such applications.
Another approach is the model-driven generation of a middleware [7]. It is possible to design real-time
distributed applications with the Unified Modeling Language (UML) [9]. By using a model-driven
approach, it is possible to generate code from an UML model.
1.3.1 Distributed Real-Time Specification for Java
Java is a programming language that runs on the Java Virtual Machine (JVM). Unfortunately, it does
not support any real-time requirements. However, the Real-Time Specification for Java (RTSJ) [10]
extends the functionality of Java with predictable execution of tasks by defining timing constraints. One
issue of RTSJ is that it is not possible to define real-time constraints in a distributed computing
environment [11]. For that reason, the Distributed Real-Time Specification for Java (DRTSJ) was
9
defined that supports predictable end-to-end timeliness for distributed computing object programming.
The DRTSJ was developed by the Java Community Process (JCP) [12] under the project name Java
Specification Request 50 (JSR-50). It extends the RTSJ and its distributed object model is based on the
Java RMI specification. For Java programmers, the DRTSJ is easy to use because there are only a few
modifications to the syntax and the semantics of Java and the RTSJ.
The issue with DRTSJ is that there is a specification available but hardly any information on the
status of its implementation, development of plugins or tools, and the integration in the Java Runtime
Environment. Because of that and the fact that the current image processing system is based on C++,
the DRTSJ cannot be considered for an adaption of the system.
1.3.2 Time-triggered Message-triggered Object
The time-triggered message-triggered object (TMO) [6] extends the semantics of conventional
objects by a real-time object model for distributed computing. TMO hides the low-level features from
the developer so that no manipulation of processes, threads, and priorities is necessary. It also supports
the developer by taking care of any network or hardware related accesses. The TMO does not directly
allow the specification of timing constraints, but to set start-windows and completion deadlines. TMOs
can be distributed on nodes over the network. They are able to interact with each other by calling remote
functions. TMOs are defined with C++ macros by mapping native threads to functions.
TMO’s are executed on the TMO Support Middleware (TMOSM) which is supported on
Windows and Linux platforms. There also exists a CORBA service that allows the development of
applications that are compliant to the CORBA specification. For developing TMO applications, the
TMO Support Library (TMOSL) is provided. Additionally, a Linux-based operating system is available
called TMO Linux [13] that allows to execute TMO instances as an embedded service. The benefit of
TMO Linux is that it offers better timing accuracy and performance because the deadline scheduler and
distributed IPC module are embedded into the Linux kernel.
The advantage of TMO compared to the DRTSJ is that it supports C++. However, TMO does not
allow to specify the priorities of tasks. Another reason why TMO is not suitable for the new system is
that it is a rather old technology and unlike CORBA not developed any further.
10
1.4 Structure
Chapter 2 summarizes similar work that also deals with evaluation on real-time distributed object
computing technologies. They are used to identify significant evaluation criteria and possibilities for
comparing the performances of the technologies to each other. The approach of this master’s thesis is
described in chapter 3. First, in chapter 3.1 the Real-Time CORBA standard is explained. In chapter 3.2
the different criteria for the evaluation are elaborated to determine CORBA implementations that match
the requirements of the company. The list of selected CORBA implementations that are evaluated is
shown in chapter 3.3. The results of the criteria evaluation and the CORBA implementations that were
chosen based on the results can be looked up in chapter 3.4. In chapter 3.5 the development of the
reference implementation is dwelled on. The performance measurement of the chosen CORBA
implementations and the results of the performance evaluation can be looked up in chapter 3.6. The
conclusion and future work are presented in chapter 4.
11
2 Related Work
In order to identify appropriate criteria for evaluating existing CORBA implementations a
research on similar approaches was conducted. They also served as basis for measuring the performance
and comparing the different implementations to each other.
Vassilopoulos et al. [14] compared the distributed technologies CORBA 3.0, Enterprise
JavaBeans 2.1, and Web Services. They evaluated those technologies against the following criteria:
• Programming Language Support
• Simplicity
• Data Representation
• Transport Protocols Support
• Service Description
• Publication and Discovery Services
• Security Issues and Performance
The distributed technology should support more than one high level programming language.
Whether it is easy to develop a client/server program contributes to Simplicity. Data Representation
describes how the representation of the data looks like when exchanged between a server and a client.
The Supported Transport Protocol corresponds to the format of messages between a client and a server
process. The Service Description means how a vendor describes the service it provides like information
about syntax, semantics and QoS. The Publication and Discovery Services concern how available
services are published and discovered. They also evaluated the performance of those technologies by
performing two tests. For the first test, they invoked a method with type void and no arguments. For
the second test, they implemented a method that accepts an argument of type String and returns an
object. They did not implement any business logic because otherwise the results might be biased. They
performed the evaluation by varying the tests with one, two and five clients running on the same machine
at the same time. Each client called each method 1000 times and the whole test was repeated 100 times.
After that they calculated the maximum, minimum and mean time that was spent for the tests. Then
they calculated the average time for each method call from these results.
Gokhale et al. [15] compared the CORBA distributions Orbix 2.1 and VisiBroker for C++ 2.0.
They evaluated their performance by the following criteria:
• Latency
12
• Scalability
The latency is the time needed for the execution of a task and the return of its results. In order to
identify the latency, they measured the performance of a test program for both CORBA
implementations. For that purpose, they sent data of different types and sizes by using static and dynamic
invocation, respectively. They determined the scalability by measuring the change of performance when
increasing the number of objects in a server process. Both CORBA implementations were tested on
ATM which is a high-speed network. Gokhale et al. compared the latency of the two CORBA
implementations against an application based on ACE that uses TCP/IP for communication over
network. They presented the results in a bar plot diagram that is shown in Figure 1. The advantage of
the bar plot is that it offers a good insight on the performance of each technology.
Figure 1: Bar Plot for Latency Comparison [15]
Khan et al. [16] evaluated the performance of the distributed technologies ICE, HORB, CORBA,
and .NET Remoting. In doing so they conducted the following performance evaluations:
• Generated Overhead
• Latency
• Scalability
13
The overhead generation test provides information about the amount of additional traffic that is
generated by the middleware when transferring the actual data. For testing purposes, they set up a client-
server environment with Windows XP computers and connected the nodes over a 100 Mbit network.
They performed two tests for overhead generation and round trip latency respectively by first
using primitive data types and then using arrays with different sizes. For comparing the overhead and
the latency they used dot diagrams with lines as shown in Figure 2. It represents the increase in overhead
and latency of the different distributed technologies if the number of clients is raised.
Figure 2: Point Diagram for Comparing the Latency [16]
Nimmagadda et al. [17] evaluated the performance of omniORB and The ACE ORB (TAO).
Since most benchmarking systems only measure the performance of the ORB on the endsystem or on a
specific operating system they decided to implement their own benchmarking system based on existing
benchmarking frameworks. They evaluated the following performance characteristics:
• Cubit Behaviour
• Throughput
The cubit behavior depicts the time that is needed for a CORBA function invocation. The
throughput describes the amount of data per second, in this case they calculated the number of megabytes
per second. They represented the number of calls for different data types, for example short, octet,
long, struct, etc., in a bar plot diagram as shown in Figure 3. For the comparison of the throughput
14
for both ORBs they used a dot diagram with lines (see Figure 4) that shows the throughput with
increasing data size.
Figure 3: Cubit Test for omniORB and TAO [17]
Figure 4: Throughput Test for TAO [17]
15
Another approach [18] evaluated standardized functionalities of CORBA, additional nonstandard
extensions, the scalability, and the robustness of different CORBA implementations.
Reitz et al. [19] conducted an evaluation on different supported CORBA services, the
programming language mapping, and the supported operating system.
The research on related evaluation approaches showed that the general evaluation criteria
included among others the programming language support, operating system support, simplicity, data
representation, transport protocols support, service description, publication and discovery services,
security issues, robustness. Most of the approaches measured the performance regarding the latency,
scalability, and throughput. For comparing the results of the performance measurement of different
technologies bar plot diagrams and dot diagrams with lines were used.
16
3 Approach
In this section the main part of this master’s thesis is described. In the following, the structure of
the approach is outlined for achieving the objectives of this master’s thesis. First, a brief overview of
Real-Time CORBA is given in chapter 3.1 that highlights the reasons why it was decided to rely on
CORBA as a real-time distributed object API for the adaption of the image processing system. Chapter
3.2 dwells on the most significant criteria to identify which CORBA implementations match the
requirements that were imposed by voestalpine Stahl. The reasons for choosing each criterion are
explained and they are described in detail. The criteria were used to identify the advantages as well as
the disadvantages of each ORB and to narrow the number of various CORBA implementations down to
a selected few. That approach allowed to compare the selected ORBs to each other and to focus on
evaluating them thoroughly. The evaluation against the criteria is dwelled on in chapter 3.4. In chapter
3.4.2 the resulting list of selected CORBA implementations is presented that were chosen based on the
criteria evaluation.
Once the ORBs that should be evaluated in detail were selected, reference implementations based
on each of them were developed. The reference implementations constitute representative examples for
the usage of CORBA in the image processing area and their deployment in the image processing system.
However, for the purpose of this master’s thesis they only implement simple image processing steps.
This approach should show whether CORBA is a suitable technology for the adaption of the current
image processing system and which ORB meets the requirements best. Therefore, the performance of
each reference implementation is measured and they are compared to each other (see 3.6.1). In order to
find out to which extent the overhead of CORBA influences the performance, the same example
application was developed without CORBA which is described in chapter 3.5.3. For that purpose, the
open source library Qt was used because the current image processing framework of the company is
also based on it. The development of the reference implementation using CORBA is explained in detail
in chapter 3.5.4. There are various possibilities to enhance an application that was developed using
CORBA. Some opportunities for optimization are explained in chapter 3.6.2. Based on the results of the
performance evaluation it will be decided whether the use of CORBA is suitable for the adaption of the
image processing framework and which ORB meets the requirements of the company best.
For testing purposes, a Linux system with real-time extensions was set up. Additionally, the
system was expanded with a data acquisition card that supports real-time access. An Arduino
microcontroller is used for measuring the performance of the reference implementations. The
17
applications process an image by using the image processing library HALCON. The details on the setup
of the testing environment are explained in chapter 3.5.1.
3.1 Real-Time CORBA
This section describes the specification of Real-Time CORBA. In chapter 3.1.1 a brief overview
of the original CORBA standard without real-time extensions and on its development team, the Object
Management Group (OMG) is given. It also highlights the benefits of using CORBA for the image
processing system. Chapter 3.1.2 explains the definition of a middleware, and in chapter 3.1.3 a
description on Object Request Brokers (ORBs) is given. The architecture of the CORBA specification
is illustrated in chapter 3.1.4. Finally, chapter 3.1.5 dwells on the real-time extension of CORBA.
3.1.1 Definition of CORBA
CORBA [1] is a specification for a distributed object computing middleware that was created by
the Object Management Group (OMG). The OMG [20] is a consortium for open technology standards
that was founded in 1989. New standards are constantly released by OMG since vendors, end-users,
academic institutions, and government agencies drive their development. Among others, the OMG
develops specifications for applications that can be distributed over the network in heterogeneous
systems [21]. The aim of the consortium is to define standards with high-level abstractions that
encapsulate low-level details, so that the developer does not have to bother with them and is able to
focus on the development of the business logic of applications. CORBA is one of the first specifications
that was released by the OMG, along with the Object Management Architecture (OMA) that describes
the architecture of distributed and object-oriented applications that are based on CORBA.
The specification of CORBA was first released in 1992 but did not contain any means for defining
real-time constraints. The CORBA standard enables the developer to establish transparent client-server
interactions in distributed systems, i.e., the server and its clients are not executed on the same computer.
CORBA is based on the object-oriented paradigm, where the focus lies on abstract real life objects that
encapsulate specific characteristics. The standard OMA [21] specifies two models: (1) the Object Model
and (2) the Reference Model, for defining objects that are distributed in a heterogeneous system and for
describing how they interact with each other respectively. The Object Model specifies encapsulated
objects which are located on servers. These objects offer services that may be requested by clients
through interfaces. Clients do not know about the implementation or the location of the objects and are
18
not able to modify them in any way. The Reference Model describes the Interface Categories that are
connected by the Object Request Broker (ORB) which is explained in chapter 3.1.3 in detail.
As discussed in chapter 1.3 there do exist some other approaches for real-time distributed
programming. However, they are not as well established as CORBA. An outstanding benefit of CORBA
is that its implementations must comply to OMG’s specification. For other real-time distributed
technologies, this constraint does not apply because there does not exist a common specification that
must be satisfied. Therefore, CORBA implementations are more reliable than other approaches for real-
time distributed object computing. There are a lot of other advantages of CORBA that contributed to the
decision to use CORBA for the new image processing framework. Using CORBA for client-server
applications improves the flexibility because it allows to execute applications locally or remotely
without the necessity of adapting the code accordingly [22]. The CORBA specification also enhances
the portability of distributed applications because it is possible to use different ORBs for the client and
server applications. CORBA automatically generates code that takes care of networking tasks like data
marshalling and de-marshalling, and other tasks that are usually implemented by the developer in low-
level programming languages such as C. The automatic generation of these functionalities contributes
to the reliability of the standard because less programming errors emerge and the developer can focus
on the development of the application logic. Another advantage is that the use of CORBA reduces the
amount of time that is required to develop high-quality systems. The basic concept of CORBA is to
make use of well-defined existing software components instead of having to implement them all over
again.
3.1.2 Middleware
CORBA is a so-called distribution middleware [6] that expands the network programming
capabilities of the operating system. A middleware lies on top of the operating system, the protocol
stacks, and the hardware [23]. It reduces the complexity of the development of distributed applications
by hiding low-level details [21]. Developers do not need to know about the underlying layers of the
middleware because CORBA takes care of handling them appropriately. Developers are able to create
applications with disregard of dependencies like the location of objects, the programming language, the
operating system, communication protocols, or hardware characteristics. Therefore, developers can
focus on the problem at hand and let CORBA handle details that lie under the middleware. The core of
the middleware is an Object Request Broker (ORB) that enables objects to interact with each other over
the network independent of their platform or programming language.
19
3.1.3 Object Request Broker
The Object Request Broker (ORB) constitutes the base for developing distributed applications
and for enabling interoperability in hetero- and homogeneous environments [24]. It serves as the
middleware between client and server objects [25]. The main functionalities of the ORB include locating
the object implementation, activating the object, sending the client’s request to the object, and returning
any results to the client. It consists of network interfaces, I/O subsystems, network protocols and
CORBA components. The ORB is responsible for establishing a connection to objects on a server [21]
and for enabling requests and responses in a distributed environment [24]. Figure 5 illustrates how a
request from a client to a specific service of an object is handled. The ORB locates the corresponding
object implementation and delivers the request including the data. When a request is sent to an object,
the ORB automatically activates that object if it is not running.
Figure 5: Request from Client to Object [26]
The object implementation is hidden from the client. Therefore, the client is only aware of the
interface of the object which is independent of the location, the programming language, or other aspects
of the object implementation. The interface for enabling communication between clients and objects is
offered by the ORB. Figure 6 illustrates the Reference Model that describes the kinds of interfaces which
provide the functionalities for activation and communication. The Reference Model describes the
interaction between the ORB and Application Interfaces, Domain Interfaces, Common Facilities, and
Object Services.
Object Services [24] provide basic functionalities for interactions between client and server
applications. For instance, the Naming Service is responsible for obtaining an object reference from an
object for accessing its public functions. Object Services are independent of the application domain, so
the CORBA specification does not describe how they should be implemented.
20
Figure 6: Interface Categories
Some of the specified object services are:
• Naming
• Event
• Persistent Object
• Life Cycle
• Concurrency Control
• Transaction
• Time
Unlike Object Services, Domain interfaces [21] are dependent of the domain. They offer
functionalities for applications in certain domains like industrial processes. They are expected to be
implemented by the user. Common Facilities [27] provide functionalities for common uses, e.g., for
language localization. Application Interfaces [21] are specific for certain applications. If they are used
in several different applications, they might be added to the CORBA specification.
The CORBA standard only contains conventions and does not describe how to implement them.
For that reason, the implementation of ORBs from different vendors differ from each other in regards
of properties and qualities [26]. Therefore, it is necessary to evaluate various ORBs to determine which
is suitable for the image processing system.
3.1.4 CORBA Architecture
This section describes the architecture of the CORBA specification that must be complied to by
CORBA implementations. Figure 7 illustrates an overview of the CORBA architecture. The CORBA
21
specification [22] [25] defines an interface definition language (IDL) which is a declarative language
that allows to specify interfaces of server objects. The grammar of IDL does not contain means for
implementing methods, but it allows to describe the signature of functions which may be called by the
client. The concrete implementation of CORBA objects can be written in different programming
languages, depending on the supported language mappings of the ORB. There are IDL mappings for
various programming languages available including C, C++, and Java.
Figure 7: CORBA Architecture
The IDL compiler processes the IDL code and generates a header file for the CORBA object, the
client-side stubs, and the server-side skeletons. Figure 7 shows the client-side stubs and server-side
skeletons and how they interact with other components of CORBA. Client-side stubs forward method
calls of clients transparently to the ORB. The ORB uses the server-side skeletons to send method calls
to the server and return the results to the corresponding client that made the request. Client-side stubs
and server-side skeletons are responsible for object registration, object activation, object location,
request demultiplexing, framing-handling, error-handling, parameter marshalling, and parameter de-
marshalling. Request demultiplexing is the transformation of requests into C++ functions. Parameter
marshalling and de-marshalling means the transformation from higher-level representations into binary
presentations and vice versa when sending them over the network.
22
As Figure 7 depicts, the client can retrieve references to CORBA objects that are arranged on the
server and invoke operations on them. The client is only aware of the method signature defined in the
IDL file and does not know about the implementation. The function call is transparent to the client and
is not affected by the location of the object implementation.
The Dynamic Invocation Interface (DII) can be used to dynamically send requests from clients to
objects instead of relying on the client-side stubs. The advantage of the DII is that it also allows to send
non-blocking synchronous and one-way requests. The Dynamic Skeleton Interface (DSI) is responsible
for dynamically sending requests from an ORB to an object implementation. For the object
implementation, it is not necessary to have any information on the object it is implementing at compile-
time. The client is also not aware whether the ORB uses the server-side skeletons or the DSI for
forwarding requests to the object implementation.
The ORB makes use of the Object Adapter to activate and send requests to the corresponding
object. Object adapters are responsible for the communication between the ORB and the servant [21]. It
offers functionalities for creating CORBA objects, associates them with object references, and forwards
requests to corresponding servants. Earlier versions of the CORBA specification provided the Basic
Object Adapter (BOA) that was replaced by the Portable Object Adapter (POA) in CORBA version 2.2.
The server ORB sends requests from clients to the POA that dispatches them to servants. Any return
values of the remote function are sent back to the client through the POA and ORB the same way.
The ORB Interface hides implementation details to simplify the development of CORBA
applications. It offers utility functionalities like converting object references to String.
The CORBA specification defines the General Inter-ORB Protocol (GIOP) [25] that is used for
communication between ORBs. The default protocol is the Internet Inter-ORB Protocol (IIOP). Figure
8 shows how a client and a server application interact with each other by using the IIOP.
Figure 8: Communication between different ORBs on different computers [28]
23
Each component of the CORBA architecture may be implemented differently by various vendors.
Each CORBA implementation might provide different qualities and properties for IDL compilers,
repositories, and Object Adapters [26].
3.1.5 CORBA Real-Time Extension
The real-time extension Real-Time CORBA (RT CORBA) was added later to the specification in
1996. It allows to specify timing constraints and priorities. The development of a real-time extension
for CORBA was inevitable because several application domains demanded real-time support, e.g.
telecommunication, aerospace, medical systems, manufacturing sectors [23]. These areas require real-
time systems that depend on stringent Quality of Service (QoS) requirements like bandwidth, latency,
jitter, and dependability [2]. For that purpose, the OMG formed a Special Interest Group (SIG) that was
assigned to develop real-time support across a distributed system in the CORBA standard.
Figure 9 shows the real-time extension of the CORBA specification.
Figure 9: Architecture of Real-Time CORBA [2]
24
The extension defines policies and mechanisms that enable hard real-time requirements for
CORBA applications. RT CORBA is able to engage in the scheduling process of the operating system.
It allows CORBA applications to define the resources that are required for tasks which contributes to
their efficiency, scalability, and predictability. They can allocate and manage resources such as thread
priorities, buffers for message queuing, transport-level connections, and network signaling. For that
purpose, the specification includes functionalities like thread pools, priority mechanisms, intra-process
mutexes, and a global scheduling service. Thread pools define the amount of memory space required by
the application and may optionally also contain buffered requests. They are usually statically allocated
with a fixed number of threads and can dynamically increase their size if needed. Intra-process mutexes
allow to synchronize critical code sections and minimize priority inversions.
RT CORBA allows to define scheduling policies and priorities for tasks. The standard focuses on
fixed-priority applications where each task is assigned a priority beforehand. The priority of each task
in a CORBA application can be mapped to priorities of the native operating system which reduces the
chance of priority inversion. CORBA defines different priority mappings for each operating system.
Tasks can be assigned with priorities in range from 0 to 32767 (215). Figure 10 shows how priorities of
tasks are mapped to different native operating system priorities.
Figure 10: Mapping of CORBA Priorities to Native Priorities
25
RT CORBA supports two different kinds of priority models to specify the priorities of tasks: (1)
the server declared priorities and (2) the client propagated priorities. With server declared priorities, a
server is able to determine the priority of an invocation on a specific CORBA object. Priorities are
encapsulated into the references of such objects. Whereas the client propagated priorities model allows
clients to specify the priorities of invocations on CORBA objects. For this model, each invocation to an
object contains its priority and is mapped to a priority of the native operating system.
Of course, RT CORBA cannot add any real-time capabilities to an operating system that does not
support them to begin with. For that reason, it is necessary to set up an environment that supports QoS
requirements. Chapter 3.5.1 deals with the set-up of the testing environment and describes which
operating system was chosen to support real-time requirements.
3.2 Criteria Elaboration
In this section, the most significant criteria of CORBA implementations are elaborated. The
criteria are used for an evaluation on different CORBA implementations to identify which of them
matches the requirements of the company best. The criteria are classified into requirements that are
demanded by the company and personal requirements that facilitate the development process.
The following requirements were given by voestalpine Stahl:
• Programming Language
• Real-Time Support
• OS Support
• Prerequisites
Voestalpine Stahl prefers a CORBA implementation that supports language mappings for C++
since the previous image processing framework was also developed in C++. This will make it easier to
integrate the functionality of the current system into the new one. Another advantage is that the
developers are not required to get familiar with another programming language. The new system should
be able to process images in real-time. Currently, the image processing system is not able to evade
updates from the IT department. It should be possible to define deadlines and assign priorities to image
processing tasks in order to avoid the interruption by updates or slowdown by other programs. The
CORBA implementation should also offer support for the Linux operation system. The reason for this
is that Linux is faster, more secure, and more stable than Windows operating systems. The programming
26
language, the real-time support, and the OS support are criteria for exclusion, i.e., if the CORBA
implementation does not support them it is not suitable for the adaption of the image processing system.
The CORBA implementation should not require to install additional software like the Java
Development Kit (JDK) or the Java Runtime Environment (JRE).
Personal requirements concern characteristics of a CORBA implementation that simplify the
development of a CORBA application. The criteria for personal reasons are:
• Open Source / Commercial CORBA Implementation
• Quality of the Documentation
• Quality of the Tutorials
• (Commercial) Support
• CORBA Version
• Interesting Features
Voestalpine Stahl does not favor open source over commercial ORBs, but for the purpose of this
master’s thesis it is easier to perform an evaluation on freely available CORBA implementations. Most
commercial CORBA implementations offer a free evaluation license, that lasts about 30 days. However,
in some cases the vendors do not easily distribute them if they do not expect any benefit from it. A free
evaluation license of 30 days does usually not suffice because it might be necessary to evaluate the ORB
again at the end of the evaluation period. For the development of CORBA applications, it is of advantage
if useful documentation and tutorials are available. This would greatly simplify the development process
and provide information on features that are explicit for a specific ORB. Any form of support,
commercial or non-commercial, would be appreciated. So, if there arise any questions or problems on
the ORB, it should be possible to expect a quick answer and constructive help. The CORBA version
determines which features might be supported and which are not. Of course, it is also possible that the
ORB is not fully compliant with the CORBA specification, i.e., not all features are implemented. It is
desirable to use an ORB that implements as many features as possible to be able to utilize the full
potential of CORBA. The ORB should be frequently improved and updated so it will not be necessary
to change to another one any time soon. Therefore, an ORB that implements a higher version of the
CORBA specification is preferred. An optional criterion is whether the CORBA implementation
supports any outstanding features that none of the others offer and which are not included in the CORBA
specification either.
27
3.3 Selection of CORBA Implementations
There are several ORBs available that implement OMG’s CORBA specification. However, many
of them, especially the open-source CORBA distributions, are not fully compliant to the standard.
Therefore, most of them do not implement all features that are specified by the standard. The goal of
this evaluation is to find an ORB that supports the most important features.
The CORBA specification does not provide information on how features should be implemented.
So, it might be the case that applications that share the same source code but are based on different
ORBs vary in terms of performance [17]. There might also be the case that different ORBs perform
better or worse depending on the run-time environment. For those reasons, it is necessary to determine
suitable CORBA implementations based on the criteria elaborated in chapter 3.2. The evaluation against
the specified criteria is described in chapter 3.4. Additionally, a performance evaluation is conducted on
them in order to determine which ORB is suitable and performs well in the given environment. Chapter
3.6 elaborates on how the performance of each ORB was measured and undertakes a closer examination
of the results.
The ORBs that were chosen for the criteria evaluation are:
• JACORB
• VBOrb
• MICO IS CORBA (MICO)
• The ACE ORB (TAO)
• TAOX11
• omniORB
• VisiBroker
The reason for selecting the ORBs above is to identify a variety of different CORBA
implementations. Of course, this list is not exhaustive, there exist a lot more CORBA implementations
that might be suitable for the future image processing system. However, for the purpose of this master’s
thesis it suffices to evaluate only a selection of existing ORBs.
3.4 Criteria Evaluation
This chapter dwells on the evaluation of the selected CORBA implementations. The results of the
evaluation (see chapter 3.4.1) determine which ORBs can be considered for the new system and are
28
candidates for further performance measurements. Only a few CORBA implementations are evaluated
further to research whether CORBA is an appropriate technology for the new system. The ORBs that
were chosen for a performance evaluation are listed in chapter 3.4.2. For each ORB the background, the
advantages, the disadvantages, and the reasons why they were selected are explained.
3.4.1 Results of the Criteria Evaluation
The results of the evaluation against the criteria are shown in Table 1. Most of the CORBA
implementations support a mapping to the programming language C++ as required except for JacORB
and VBOrb. JacORB only supports Java and VBOrb provides language mappings for Visual Basic. The
ORBs TAO, TAOX11, omniORB, and VisiBroker support real-time requirements. As for MICO, it is
not explicitly mentioned whether it offers functionalities for defining real-time constraints. Except for
VBOrb which is only supported on Windows operating systems, all of the selected ORBs run on Linux
platforms. The CORBA implementations JacORB, VBOrb, MICO, TAO, and omniORB are freely
available and were released under the GNU General Public License (GPL) or under the GNU Lesser
General Public License (LGPL), respectively [29]. Among the selected ORBs, only TAOX11 and
VisiBroker are commercial ones. However, they offer free licenses that last for 30 days for evaluation
purposes. Almost all of the ORBs come with a good documentation and useful tutorials, except for
VBOrb which only offers an instruction for the installation. TAOX11 does not provide any
documentation or tutorials on the internet, but deliver them with a valid testing license or commercial
license. JacORB and VBOrb offer free support in form of email or bug tracking. The other ORBs only
provide commercial support or offer support in combination with a commercial license. TAO, TAOX11
and VisiBroker implement CORBA version 3, so they offer features that were released in recent years.
TAOX11 implements the latest CORBA specification version 3.3 which was released in November,
2012. JacORB, VBOrb, and VisiBroker require the JDK/JRE which is not preferred by the company.
VBOrb additionally needs Visual Basic installed on the run-time environment and omniORB depends
on Python.
VisiBroker offers an additional feature called custom marshalling that allows to integrate external
libraries and user-defined types that were not declared in CORBA. For that purpose, VisiBroker offers
the type custom valuetype. It ignores the default marshalling and de-marshalling mechanism and
allows developers to implement their own encoding and decoding functions. Custom marshalling would
be a great advantage for the future system since the image processing library HALCON could be
integrated without the need of transforming HALCON objects into CORBA objects and vice-versa.
29
JacORB VBOrb MICO TAO TAOX11 omniORB VisiBroker
Programming
Language
Java Visual Basic C++ C++ C++11 C++
Python
C++
Java
C# .NET
Real Time
Support
no no ? yes yes yes yes
OS Support MAC OS X
Windows
Linux
Windows Oracle
Solaris
Linux
Windows
MAC OS X
Windows
Linux
Windows
Linux
Android
Windows
Unix
Windows
Unix
Android
Prerequisites Java JDK
1.6 or above
VB 5 or VB
6
JRE/JDK
1.1 or above
- Perl - Python 2.7 Java JDK
Java JRE
Open Source /
Commercial
GNU
GPLv2
GNU GPL GNU GPL open
source
commercial
(free
evaluation
license)
GNU
LGPL
commercial
(free evaluation
license)
Documentation good almost non-
existent
good extensive,
good
full
documentat
ion
available
with valid
license
good extensive, good
Tutorials good minimal good good tutorials
available
with valid
license
ok good
Support mailing
lists, bug
tracking
system
email commercial
support
commerci
al support
full support
with valid
license
mailing
lists,
commercia
l support
commercial
support
CORBA
version
2.3 2.3 2.3 3.1 3.3 2.6 3.0
Interesting
Features
Custom
Marshalling
Table 1: Criteria Evaluation
30
3.4.2 CORBA Implementations
In order to conduct a performance evaluation on different CORBA implementations, it is first
necessary to narrow them down because the effort would be too big to develop reference
implementations for all ORBs that match the criteria for exclusion. This makes it possible to test them
thoroughly and evaluate them in detail. In the following the ORBs that seemed most appropriate for the
given requirements of the company based on the results of the criteria evaluation are listed. This section
also explains why specific ORBs were chosen. The order of the ORB simply reflects in which order
they were evaluated. The ORBs that were selected are:
• The ACE ORB (TAO)
• omniORB
• MICO
• VisiBroker
In the following, a brief introduction on each of the selected CORBA implementation is given.
Additionally, a few remarks on compilation and development of applications are made. The
development of CORBA applications is described in chapter 3.5.4 in detail, this section only dwells on
the compilation and development of the specific CORBA implementations.
3.4.2.1 The ACE ORB (TAO)
TAO [25] was developed by the Distributed Object Computing (DOC) Group. It is based on the
Adaptive Communication Environment (ACE) which is a host infrastructure middleware. ACE extends
the operating system, networking, and inter-process communication facilities with object-oriented
abstraction [30]. Figure 11 illustrates the architecture of TAO where the ORB core is built upon ACE.
It also shows TAO’s real-time extension to the CORBA specification.
TAO provides language mappings for C++ and is one of the few CORBA implementations that
support hard real-time requirements. It implements functionalities for avoiding end-to-end priority
inversion. Like most of the ORBs, TAO is compatible with Linux. It is an open-source software which
makes it easier to evaluate since it is not required to request an evaluation license. An extensive and
good documentation is available and the tutorials are easy to reproduce. If there ever happen to be
problems with TAO, commercial support is offered from the vendors. The current TAO version is
compliant with the CORBA version 3.1. It does not require any special prerequisites which makes it
31
easy to compile the ORB on the testing environment without the need to install any additional software.
In order to build applications, TAO provides the Makefile, Project and Workspace Creator (MPC) which
requires the installation of Perl. The MPC is elaborated in detail later this chapter.
Figure 11: TAO Architecture
TAO uses an open source software model which enables any user to contribute to the source code,
starting from academics to end-users. TAO is applied in several commercial application areas like
defense, telecommunication, multimedia, finance, manufacturing, information and system management,
etc. Especially in commercial sectors, the developers depend on a reliable ORB and expect it to be stable,
well documented, and commercially supported. For that reason, TAO benefits most from contributions
of developers from commercial sectors. Additionally, there are a lot of organizations that donate to the
development of TAO. Therefore, the ORB is constantly improved and maintained which leads to a
mature CORBA implementation.
One of the greatest advantages of TAO is that it promises a high performance which is essential
for image processing tasks. The developers of TAO claim that it can even keep up with lower-level
networking APIs, e.g. sockets. The ORB offers good throughput, latency, and jitter and is particularly
suitable for performance-sensitive applications. It optimizes most of the key functionalities of CORBA
which include request demultiplexing, operation dispatching, presentation layer conversions,
synchronization, context switching, memory management, and data copying. The Portable Object
32
Adapter (POA) is responsible for improving the request demultiplexing and operating dispatching
mechanisms [25]. This contributes to the predictability of the ORB because it guarantees that the time
needed for operation dispatching stays constant independent of the number of connections, activated
servers, and defined operations.
TAO enables developers to customize and extend the ORB by offering the Pluggable Protocol
Framework [31]. The advantage of pluggable protocols is that the functionality of the ORB can be
extended without changing the ORB core directly. For example, it is possible to use a different
transmission protocol for a CORBA application such as UDP.
The documentation explains well how to install ACE and TAO and build sample programs. It
also describes important functionalities of the ORB as well as possibilities for optimizing applications.
The download package comes with source files of ACE and TAO. Since TAO depends on ACE,
it is necessary to compile ACE first. The compiling process of ACE and TAO require to define the
environment variables ACE_ROOT, TAO_ROOT, PATH, and LD_LIBRARY_PATH. These can be specified,
for instance in a profile configuration file .profile_TAO:
export ACE_ROOT=/opt/ACE_wrappers
export TAO_ROOT=$ACE_ROOT/TAO
export PATH=$PATH:$ACE_ROOT/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ACE_ROOT/lib
The variables ACE_ROOT and TAO_ROOT depict the path to the ACE directory and the TAO
directory, respectively. The path of the binary directory of TAO is added to the PATH environment
variable. Additionally, it is necessary to add the libraries directory to LD_LIBRARY_PATH. The path to
the libraries is also needed when compiling TAO applications.
After writing an IDL file that is for instance called ImageFilter.idl, the IDL compiler of TAO
can be executed to generate the server-side skeletons and the client-side stubs as already explained in
chapter 3.1.4. The corresponding IDL file ImageFilter.idl is shown in chapter 3.5.4.1. The TAO
IDL compiler is executed by using the following line in a bash shell:
tao_idl -GI ImageFilter.idl
The option -GI instructs the compiler to additionally generate a placeholder file for the object
implementation from an IDL interface. The names and the number of the generated files is different for
each ORB. Based on the IDL interface ImageFilter.idl, the TAO IDL compiler creates header and
33
source files ImageFilterI.* for the object implementation class, the server-side skeletons
ImageFilterS.*, and the client-side stubs ImageFilterC.*.
As already mentioned, TAO comes with the Makefile, Project and Workspace Creator (MPC)
which takes care of generating GNU makefiles. This simplifies the process of developing CORBA
applications because the developer is not responsible for creating executable applications. For that
purpose, a MPC file (.mpc) is required that contains information on the necessary source files for
building the specific applications. The following code snippet of the MPC file creates a project called
ImageFilter_idl that is responsible for processing the IDL and is required by both the client and the
server applications.
project(*idl): taoidldefaults {
IDL_Files {
ImageFilter.idl
}
custom_only = 1
}
In order to create an executable server application, the following code should be contained in the
MPC file:
project(*Server): taoserver {
exename = ImageFilterServer
after += *idl
Source_Files {
ImageFilterI.cpp
ImageFilterServer.cpp
}
Source_Files {
ImageFilterC.cpp
ImageFilterS.cpp
}
IDL_Files {
}
}
The server application includes the object implementation, the client-side stubs and server-side
skeletons, and the server’s main program. The client application only requires the client-side stubs and
the client’s main program. It is generated with the following code snippet:
project(*Client): taoclient {
exename = ImageFilterClient
34
after += *idl
Source_Files {
ImageFilterClient.cpp
}
Source_Files {
ImageFilterC.cpp
}
IDL_Files {
}
}
The MPC takes the MPC file as input and generates GNU makefiles that are responsible for
building the applications by using the program mwc.pl in the shell:
mwc.pl -type gnuace
Based on the MPC file described above, the MPC generates the following GNU makefiles:
• GNUmakefile
• GNUmakefile.ImageFilterClient_Idl
• GNUmakefile.ImageFilter_Server
• GNUmakefile.ImageFilter_Client
The building process is called with the command make, that uses the information from the GNU
makefiles for building the server and client applications.
3.4.2.2 omniORB
omniORB [32] was first developed as an ORB for embedded systems at Olivetti Research Ltd
(ORL), later also known as AT&T Laboratories Cambridge. It soon became available for other systems
as well because it offered better performance than other commercial ORBs at the time it was released.
It is now developed by Apasphere Ltd and there are frequent releases almost every year. The ORB
promises a high performance and offers soft real-time requirements for specifying deadlines and
timeouts.
omniORB offers language mappings for C++ and Python. omniORB is an open-source CORBA
implementation that is supported on different platforms including Linux. There is commercial support
available for omniORB for solving specific problems. omniORB implements the CORBA version 2.6
[33], which might result in missing crucial features. Additionally, the CORBA implementation does not
35
fully support CORBA 2.6. However, for the development of the image processing system the supported
functionality should be sufficient. Since the ORB was developed in Python, the installation of Python is
required for the compiling process of omniORB.
The documentation is useful and provides a good overview on omniORB’s features. The tutorials
show how to implement sample applications but miss some crucial points like which libraries are
necessary to build an application with omniORB. Additionally, the documentation does not describe
which of the source files that are generated by the omniORB IDL compiler should be included in the
client application and in the server application, respectively. This might be challenging for developers
that are new to CORBA, but also for experienced users since the output of each IDL compiler of various
CORBA implementations differs in number and names of files.
Before compiling omniORB, the environment variable OMNIORB_TOP needs to be set with the
path to the root directory of omniORB as shown in the following code snippet:
export OMNIORB_TOP=/opt/omniORB-4.2.1
The building process for omniORB is explained in the installation guide. The omniORB IDL
compiler is executed by using omniidl with a given IDL interface file in the shell:
omniidl -bcxx ImageFilter.idl
The option -bcxx instructs the IDL compiler to generate C++ header and source code files,
namely the two files ImageFilter.hh and ImageFilterSK.cc that contain the client-side stubs and
server-side skeletons. However, omniORB allows to change the output files by providing additional IDL
compiler options. For example, the options -Wbh and -Wbs change the filename extension for the header
file and the source code file, respectively. The option -Wbexample tells the IDL compiler to generate a
placeholder file for the object implementation Executing the following instruction generates the output
files ImageFilter.h, ImageFilterSK.cpp, and ImageFilter_i.cc.
omniidl -bcxx -Wbh=′.h′ -Wbs=′SK.cpp′ -Wbexample ImageFilter.idl
Since omniORB does not provide any means for simplifying the building process of applications
like the MPC for TAO, it is helpful to write a makefile or use a development environment like NetBeans
IDE [34] or Eclipse [35]. A makefile may contain information about the compiler that is used for
36
building the application, the source files that should be included, and the required libraries. Writing a
makefile simplifies the process of building applications, because it contains all the information needed
for the compilation and can simply be called by using the command make in a Linux shell. Of course,
the execution of the IDL compiler can be added to a makefile as well. The following code snippet should
be included in a makefile to execute the omniORB IDL compiler:
OMNIORB_PATH = /usr/local
OMNIORB_BIN = $(OMNIORB_PATH)/bin
IDL = $(OMNIORB_BIN)/omniidl
IDL_FLAGS = -bcxx
ImageFilter.hh ImageFilterSK.cc: ImageFilter.idl
$(IDL) $(IDL_FLAGS) ImageFilter.idl
This part of the makefile specifies to use the omniORB IDL compiler omniidl that is located in
the bin directory of the root directory of omniORB. It also determines the options used for compiling
the IDL file. In this case, only the option -bcxx is used for generating C++ stubs. As soon as all
prerequisites are met, the client and server applications can be compiled. The following code snippet
shows the part of the makefile that is responsible for compiling these applications.
CXX = g++ -D__USE_OMNIORB
LD = g++
OMNIORB_PATH = /usr/local
OMNIORB_INC = $(OMNIORB_PATH)/include
OMNIORB_LIBPATH = $(OMNIORB_PATH)/lib
OMNIORB_LIB = -lomniORB4 -lomnithread -lomniDynamic4
CXXFLAGS = -c -Wall -I$(OMNIORB_INC) -g -I./
LD_FLAGS = -g
LIBS = -L$(OMNIORB_LIBPATH) $(OMNIORB_LIB) -pthread
PROG = ImageFilterClient ImageFilterServer
all: $(PROG)
ImageFilterClient: ImageFilterClient.o ImageFilterSK.o
$(LD) ImageFilterClient.o ImageFilterSK.o $(LD_FLAGS) $(LIBS) -o
ImageFilterClient
ImageFilterServer: ImageFilterServer.o ImageFilterSK.o
$(LD) ImageFilterServer.o ImageFilterSK.o $(LD_FLAGS) $(LIBS) -o
ImageFilterServer
ImageFilterClient.o: ImageFilter.hh
37
$(CXX) $(CXXFLAGS) ImageFilterClient.cc
ImageFilterServer.o: ImageFilter.hh
$(CXX) $(CXXFLAGS) ImageFilterServer.cc
ImageFilterSK.o: ImageFilter.hh
$(CXX) $(CXXFLAGS) ImageFilterSK.cc
The compilation process requires the paths to the include and lib directories of omniORB, that
contain the source files and the libraries, respectively.
The complete makefile can be executed by using the command make all. First, the object files
ImageFilterClient.o, ImageFilterServer.o, and ImageFilterSK.o are compiled with the
corresponding source files. The client and server object files are linked together with the stubs object
file (ImageFilterSK.o) and the omniORB libraries lomniORB4, lomnithread, and
lomniDynamic4 to create the executables for the client and server application. The GNU C++ compiler
(g++) is used for compilation and linking.
3.4.2.3 MICO IS CORBA (MICO)
MICO [36] was developed at the University of Frankfurt in 1996. MICO offers language
mappings for the programming language C++. MICO is supported on many different operating systems
including Linux. It is an open-source CORBA implementation, but also offers commercial support.
Unfortunately, MICO only supports the CORBA version 2.3. However, it is fully compliant to the
CORBA specification [37], i.e., it implements the complete CORBA version 2.3. The vendors of MICO
focus on always providing updates for the latest CORBA specification. However, they have not released
a new version since 2008.
MICO is a multi-threaded ORB that supports asynchronous calls. Unfortunately, it does not
support RT CORBA extensions like avoiding priority inversion and is thus not suitable for systems with
stringent QoS requirements. However, Selvakumar et al. [38] present an approach where they have
successfully expanded the MICO ORB with real-time extensions. Real-time MICO assigns each client-
to-server connection with a priority that avoids the possibility of end-to-end priority inversion. They
also added an interface that allows to define timing constraints and deadlines. Selvakumar et al.
conducted a performance evaluation on their extension and obtained good results in comparison to the
original MICO ORB.
38
MICO is based on standard UNIX API [36] and does not make use of any proprietary libraries or
tools. Another reason why MICO is of interest is that it is used in different commercial application
scenarios by several companies. The vendors advertise MICO as a very robust and secure ORB.
The documentation and tutorials are quite useful and explain in detail how to compile MICO and
develop a simple CORBA application. The documentation also gives a good insight on the supported
features of MICO.
The building process of MICO is very easy because it does not afford any prerequisites and it
does not require the definition of any environment variables.
After defining an IDL interface the IDL compiler of MICO can be executed with the program
idl:
idl ImageFilter.idl
For a given IDL interface file ImageFilter.idl, the IDL compiler creates two files
ImageFilter.h and ImageFilter.cc that contain the stubs and skeletons.
Like most ORBs, the IDL compiler of MICO also offers additional options. For instance, the
option –c++-impl is used to specify that the IDL compiler should generate a placeholder file for the
object implementation. The name of the generated stubs can be changed by using the options c++-
suffix and hh-suffix:
idl --c++-suffix=′.cpp′ --hh-suffix=′.h′ --c++-impl ImageFilter.idl
The IDL compiler offers more options that can be looked up in the MICO documentation [36].
Like omniORB, MICO does not offer any means to simplify the compilation of applications.
Therefore, the makefile written for omniORB as shown in the previous chapter was reused and adapted
for MICO. The content of the makefile is shown in the following code snippet:
CXX = mico-c++
LD = mico-ld
MICO_PATH = /usr/local
MICO_BIN = $(MICO_PATH)/bin
MICO_INC = $(MICO_PATH)/include
MICO_LIBPATH = $(MICO_PATH)/lib
MICO_LIB = -lmico2.3.13
39
IDL = $(MICO_BIN)/idl
IDL_FLAGS = --c++-impl
CXXFLAGS = -c -Wall -I$(MICO_INC) -g -I./
LD_FLAGS = -g
LIBS = -L$(MICO_LIBPATH) $(MICO_LIB)
PROG = ImageFilterServer ImageFilterClient
all: $(PROG)
ImageFilterServer: ImageFilterServer.o ImageFilter.o
$(LD) ImageFilterServer.o ImageFilter.o $(LD_FLAGS) $(LIBS) -o
ImageFilterServer
ImageFilterClient: ImageFilterClient.o ImageFilter.o
$(LD) ImageFilterClient.o ImageFilter.o $(LD_FLAGS) $(LIBS) -o
ImageFilterClient
ImageFilterServer.o: ImageFilter_impl.h ImageFilter.h
$(CXX) $(CXXFLAGS) ImageFilterServer.cc
ImageFilterClient.o: ImageFilter_impl.h ImageFilter.h
$(CXX) $(CXXFLAGS) ImageFilterClient.cc
ImageFilter.o: ImageFilter.h
$(CXX) $(CXXFLAGS) ImageFilter.cc
ImageFilter.h ImageFilter.cc: ImageFilter.idl
$(IDL) $(IDL_FLAGS) ImageFilter.idl
MICO provides the compiler mico-c++ for compiling source files. The executable server and
client applications are created by linking the object files and the MICO library lmico2.3.13 together.
For that purpose, the linker mico-ld from MICO is used.
3.4.2.4 VisiBroker
VisiBroker [39] is a commercial ORB that was developed by Micro Focus. It promises high
performance and fits especially well for low-latency, complex, data-oriented, transaction-intensive, and
mission-critical systems. VisiBroker supports a huge number of clients and servers concurrently due to
its high scalability. The ORB provides interoperability with other technologies like Web Services, .NET
and J2EE applications. VisiBroker offers language mappings to several programming languages, namely
to C++, Java, and C# .NET. The CORBA implementation allows to define real-time constraints which
makes it a promising candidate for the new image processing system. Among other platforms,
VisiBroker is also available on Linux operating systems. For evaluation purposes, VisiBroker offers a
40
free trial license that lasts for 30 days. The documentation and tutorials are very extensive and cover
pretty much all aspects of the ORB. It is compliant to the CORBA version 3.0, so it supports most of
the latest features. VisiBroker offers a very interesting feature which is not included in the CORBA
specification: it implements custom marshalling which allows to include external libraries in the IDL
file and access defined datatypes with the keyword custom valuetype. For that reason, VisiBroker
seemed to be very promising for the use in the new image processing system. Since the system depends
on the library HALCON which defines customized data types like HObject for storing image data, it
would be very useful to simply integrate objects of that type into an IDL interface. In order to use third
party libraries in CORBA applications, it is necessary to transform HALCON objects into CORBA data
types and vice-versa. This might increase the development time but also the time needed for the
execution of the program. By defining variables with the custom valuetype, the developer is able to
implement the corresponding marshalling and de-marshalling operations. Hence, the responsibility for
defining an operation that transforms, for instance an object HObject into a CORBA data type is handed
to the developer.
Micro Focus offers an extensive description on how to install VisiBroker on different platforms.
It provides a graphical installation wizard which simplifies the installation. Unfortunately, the Java
Runtime Environment (JRE) and the Java Development Kit (JDK) are required for the installation of
VisiBroker. The company decided to avoid depending on Java for the future image processing system
because it holds to much of an overhead. But since VisiBroker offers such an interesting feature as
custom marshalling it was decided to evaluate the ORB anyway. Another obstacle was reached at the
end of the installation: In addition to achieving an evaluation license, VisiBroker requires the user to
register the product. The product registration is inevitable at the end of the installation wizard. However,
when trying to install VisiBroker on the testing computer, the wizard closes right before the product
registration. It is also not possible to return to the product registration without reinstalling VisiBroker.
Trying to reinstall VisiBroker also leads to the same results. Through a detour, it is possible to register
and activate the product manually. Because of the problems that were encountered and due to the fact
that VisiBroker depends on Java which should be avoided for the image processing system it was
decided to stop the evaluation.
3.5 Development of the Reference Implementation
This section describes the approach for developing reference implementations. The first step of
the approach is the setup of the testing environment where the performances of the different ORBs are
41
measured. Chapter 3.5.1 describes which hardware and software was used for setting up the test
computer. The reference implementations should implement the same application scenario. Therefore,
a suitable example was prepared that is representative for image processing tasks in voestalpine Stahl.
A detailed description on the application scenario is given in chapter 3.5.2. The CORBA specification
implies some overhead due to the abstraction and marshalling mechanisms. It was decided to include a
non-CORBA application in the performance evaluation to determine to which extent that overhead
influences the performance of applications. Since the current image processing framework was
developed with the open source library Qt, it was obvious to use it for the reference implementation as
well. The details of the reference implementation without CORBA are explained in chapter 3.5.3 as well
as a brief description of the open-source library Qt. Chapter 3.5.4 elaborates the development of
applications with the selected CORBA implementations. The most important components for building
a CORBA application are highlighted and explained in detail.
3.5.1 Setting up the Testing System
This section describes the setup of the testing environment for the prototypical implementation of
CORBA applications. The testing environment is used for conducting performance measurements on
each ORB. The testing system is set up with the Linux-based operating system Xubuntu [40]. Since the
standard Linux kernel only supports soft real-time requirements and cannot guarantee hard real-time
deadlines, the system is extended with the RT-Preempt patch [41]. For measuring the performance of
the applications, a data acquisition board is used which allows to, among others, read and write signals.
In order to calculate the time between two signals an Arduino microcontroller and the Arduino IDE are
used.
3.5.1.1 Computer Hardware
The performance evaluations that are described in chapter 3.6 were conducted on a HP Z840
Workstation with two Intel Xeon Processor E5-2643 v3 with six cores and a frequency of 3,70 GHz
each. For fast image processing, the workstation includes two NVIDIA GeForce GTX TITAN X graphic
cards with 12 GB 5GDDR memory each. In order to enhance the performance of the CORBA
applications, a 32 GB DDR4 RAM main memory and a 256 GB SSD hard drive were assembled.
The performance evaluation on each ORB is conducted by measuring the time needed for calling
a specific operation on the server until the results are returned to the client. For that purpose, a data
acquisition card National Instruments PCI E-6521 and a microcontroller Arduino Mega 2560 were used.
42
A corresponding driver is required to enable to send signals to the hardware I/O card. Possible APIs for
accessing the National Instruments card are the National Instruments API and the open-source driver
and library Comedi [42]. The National Instruments API does not support real-time well on the Linux
operating system and is not suitable for Linux in general. Additionally, the API does not offer a good
usability. Comedi does not possess those problems and does not depend on a specific vendor. Therefore,
it was decided to use Comedi for the testing system.
The Arduino microcontroller can be programmed with the Arduino IDE to interpret signals from
a data acquisition card and write user-defined output to the serial port. For instance, the output may
contain the time measured between two signals. Chapter 3.5.4.5 describes how signals are sent to the
digital channel of the I/O card and how they are interpreted by the Arduino microcontroller.
3.5.1.2 Xubuntu and the RT-Preempt Patch
The testing environment is set up with the latest Xubuntu version 16.04.1 LTS [40] which is a
Linux-based operating system. It offers the configurable desktop environment Xfce which enhances the
usability for the user. The reason for choosing Xubuntu 16.04.1 LTS is that as a Linux distribution it is
stable, secure, and efficient. Another reason why it was decided to use Xubuntu 16.04.1 LTS is that it is
a platform that will offer long-term support.
However, the Linux standard kernel does not allow to define hard real-time constraints, it only
supports soft real-time requirements. Using an ORB with hard real-time requirements does not implicitly
enable the creation of CORBA applications with hard real-time behavior if the OS does not support it
[2]. Because of that, it was necessary to extend Xubuntu with the RT-Preemption Patch [41] [43], which
is also called RT-Preempt Patch. The RT-Preempt Patch is an open source extension for the Linux
standard kernel. It is very stable and has already been used in a lot of reference implementations. Some
features that were supposed to be implemented in the RT-Preempt Patch were realized in the Linux
standard kernel instead, which is a sign for the good quality of the real-time extension.
The interrupt handler is one of the features of the Linux standard kernel that support soft real-
time requirements. It takes care of interrupting tasks of a running system. Real-time tasks are assigned
a processing time that depends on their priority and are able to interrupt other tasks. Each task is assigned
a priority from 1 to 99, which enables them to interrupt tasks with a smaller priority. Normal tasks are
processed only after real-time tasks have used up their processing time.
43
3.5.1.3 Comedi and Arduino
The Comedi project [42] offers open source drivers, tools, and libraries for data acquisition like
reading and writing of digital inputs and outputs, pulse and frequency counting, pulse generation, etc.
The Comedi project consists of Comedi, Comedilib, and Kcomedilib. Comedi offers drivers for various
data acquisition boards, including the National Instruments PCI E-6521 card. Comedilib provides the
interface to access data acquisition cards that are supported by Comedi. Kcomedilib is a library that
allows the use of Comedi from a real-time task.
In Comedi, the data acquisition boards are referred to as devices. A device contains a set of
subdevices which is a set of functionally identical channels, e.g. a set of digital inputs. Comedi supports
different kinds of signals, like digital input, digital output, pulse input, pulse output, etc.
After the installation process of Comedi, it is necessary to load the Comedi driver into the Linux
kernel and configure the device manually. The driver can be loaded into the kernel by using the
command modprobe in the shell. However, the command requires the name of the driver. It can be
looked up by using comedi_board_info -v which results in the following information:
overall info:
version code: 0x00074c
driver name: ni_pcimio
board name: pcie-6251
number of subdevices: 14
…
subdevice 2:
type: 5 (digital I/O)
flags: 0x10035000
SDF_CMD_WRITE:can do asynchronous output commands
SDF_READABLE:subdevice can be read
SDF_WRITABLE:subdevice can be written
SDF_LSAMPL:subdevice uses 32-bit samples for commands
number of channels: 8
max data value: 1
ranges:
all chans: [0 V,5 V]
…
The output reveals the name of the board ni_pcimio and describes its subdevices. subdevice
2 is used for digital input and output. It offers 8 channels, where each channel can hold a signal that is
either 0 or 1.
With the gathered information, it is now possible to load the driver into the kernel by using
modprobe with the driver name:
44
modprobe ni_pcimio
After the kernel is successfully loaded into the kernel, the board can be configured with
comedi_config:
comedi_config /dev/comedi0 ni_pcimio
The Comedi driver is only installed for the owner root and group root. Therefore, it is necessary
to grant the permission to read and write on the Comedi device to all users. On most Linux distributions,
this can be done by defining a rule. For that purpose, a new file, e.g., 99-comedi.rules is created in
the path /etc/udev/rules.d with the following content:
KERNEL=="comedi*", GROUP="uucp", MODE="0666"
If the kernel information of a device has the prefix comedi, this rule sets the group to uucp and
grants permission to read and write on the device.
The Arduino Mega 2560 is connected to the digital input/output subdevice (subdevice 2). In
order to program the Arduino microcontroller, the open source Arduino Software IDE must be installed
on the computer and correctly configured. It is necessary to set the proper board and the port in the
settings in order to connect to the Arduino microcontroller.
3.5.1.4 HALCON
The current image processing system uses the machine vision software HALCON [44] [45] for
filtering images taken of steel slabs. The advantage of HALCON is that it also offers interfaces for
handling different image acquisition hardware, i.e., cameras directly which allows to automate the image
processing task. Additionally, it is supported by many operating systems like Windows or Linux based
platforms which makes it easy to migrate applications to other platforms. Since the main functionality
of the image processing system should not be changed, voestalpine Stahl decided not to dispense with
HALCON. Therefore, it should come into operation for the new system as well. For those reasons, the
reference implementation should perform some filtering steps on an image by making use of the
45
HALCON library. The application scenario and the image processing tasks that are applied are described
in chapter 3.5.2.
HALCON comes with an integrated development environment (IDE) that contains HDevelop and
HDevEngine. HDevelop is a tool for the simple development of image processing tasks with
HALCON’s programming language. HDevEngine provides libraries for executing HALCON operations
in applications that were developed with programming languages like C++. For the purpose of this
master’s thesis, the HALCON libraries were integrated into the CORBA applications to make use of
their functionality.
3.5.2 Application Use Case Scenario
As already mentioned, the image processing library HALCON is in use for the current image
processing system. Since HALCON is not dispensable for the image processes in voestalpine Stahl, it
should be possible to integrate HALCON in a CORBA application. Unfortunately, most ORBs do not
offer means for directly using data types of external libraries.
The application use case scenario described in this chapter should give insight on whether it is
possible to use HALCON in CORBA applications. It should also allow to determine the extent of the
overhead of CORBA due to the additional transformation of HALCON objects, the marshalling and de-
marshalling operations, and the abstractions of the CORBA architecture. For that reason, a small
representative example that applies some image processing steps is performed as shown in the following:
ReadImage(&image, "Flower");
SobelAmp(image, &ho_EdgeAmplitude, "sum_abs", 3);
Threshold(ho_EdgeAmplitude, &ho_Region, 30, 255);
GetImageSize(image, &hv_Width, &hv_Height);
GenImageConst(&ho_Image1, "byte", hv_Width, hv_Height);
PaintRegion(ho_Region, ho_Image1, &ho_ImageResult, 255, "fill");
WriteImage(ho_ImageResult, "tiff", 0, "Flower_processed");
The image filters were defined with HDevelop and then transformed into C++ code. By importing
the HALCON library, the transformed code can be called without performing any additional steps.
First a JPG file called Flower is read in and the image is stored in a HALCON object HObject.
The function SobelAmp is applied on it, to retrieve the edges and the amplitude. The Threshold
returns a region of pixels from the edges and the amplitude where the gray value is between 30 and 255.
46
The function GetImageSize returns the width and height of the input image. By using
GenImageConst an empty image with constant gray value in the range of 0 to 255 is generated.
PaintRegion is applied on the retrieved region and stores the edges of the input image into the empty
image. The result of these image processing steps is a grayscale picture which is written to a new file by
calling the function WriteImage.
Figure 12: Application Scenario
The image that was used as input for this case study and the result of applying the described image
filters are shown in Figure 12. The result is a grayscale picture that omits details of the original image
and only shows its edges. This application use case scenario is used as a representative example for both
the reference implementation without CORBA and its pendant an application based on CORBA.
3.5.3 Development of Reference Implementation without CORBA
In order to determine the loss in performance due to the overhead of CORBA in comparison with
the current system, a reference implementation was developed that is similar to the current image
processing system. For that purpose, a monolithic system based on Qt was created that performs the
image processing tasks described in chapter 3.5.2. This section first describes the library Qt and then
dwells on the development of the monolithic application.
47
3.5.3.1 Qt
Qt [46] is a widely-used framework for developing platform independent applications with
graphical user interfaces (GUI) on desktop, mobile, and embedded systems. It was developed by the Qt
Company in cooperation with the Qt Project Community. Qt supports, among others, Windows, Linux
based operating systems, macOS, Embedded Linux, and mobile operating systems like Android or iOS.
It both offers an open-source license but also a commercial product that comes with additional support.
Another benefit of the commercial product is that the developer is able to create and distribute software
without the need to comply with the GPL and LGPLv3 open source licenses. For the purpose of this
master’s thesis, it was sufficient to use the open source license of Qt.
Qt comes with the Qt Creator IDE that is also supported on the above-named platforms. The Qt
Creator enhances and simplifies the development of applications by providing a code editor for C++
with code completion. Additionally, Qt provides a plug-in for Microsoft Visual Studio that allows to
develop applications based on Qt.
3.5.3.2 Development of Reference Implementation with Qt
The Qt Creator provided by Qt was used for the development of the reference implementation
without CORBA. Besides directly supporting the Qt library, it also simplified the development process
because there are only a few decent IDEs for C++ available on Linux based operating systems. For
instance, alternatives to the Qt Creator are NetBeans [34] or Eclipse [35].
The program reads in the file Flower.jpg shown in Figure 12 and stores the image in a
HALCON object HObject like described in chapter 3.5.2. In CORBA applications, it is necessary to
convert HALCON objects because they are not compatible with CORBA objects. However, the
transformation of HALCON objects might contribute to a loss in performance. In order to determine the
overhead of CORBA applications, the monolithic system should have the same behavior. Therefore, a
filter function FilterImage is defined that expects a dynamic character array containing the pixels of
the image instead of a HALCON object. The processed image is also returned as a dynamic array.
static const unsigned char* FilterImage(unsigned char *imageBuffer,
long width, long height);
The following code snippet shows the transformation of a HObject into a C++ data type and how
the filter function FilterImage is called:
48
HObject image;
ReadImage(&image, "Flower.jpg");
HTuple width, height, ptr, type;
GetImagePointer1(image, &ptr, &type, &width, &height);
unsigned char *imagePtr = (unsigned char*)ptr[0].L();
long size = width * height;
unsigned char* buffer = (unsigned char*)calloc(size, sizeof(char));
memcpy(buffer, imagePtr, size * sizeof(char));
const unsigned char *retImage = FilterImage(buffer, width, height);
The function GetImagePointer1 returns a pointer of type HTuple to the first channel of the
image which is stored in the HALCON database. HALCON offers the function L which is used to
retrieve a pointer to the value of the first pixel of the image. In order to develop a monolithic system
that resembles the CORBA application as much as possible, the image pointer is copied to another
dynamic character array by using memcpy.
The processed image is then converted back to a HObject in order to write it to an image file
Flower_processed.tiff:
HObject processedImage;
GenImage1(&processedImage, "byte", (Hlong)width, (Hlong)height,
(Hlong)retImage);
WriteImage(processedImage, "tiff", 0, "Flower_processed");
For that purpose, the HALCON function GenImage1 is used that generates a HALCON object
from a pointer to a dynamic array. The following code snippet shows the image filter function
FilterImage that is applied on the image:
const unsigned char* FilterImage(unsigned char *imageBuffer, long width,
long height)
{
HObject image, ho_EdgeAmplitude, ho_Region, ho_Image1,
ho_ImageResult;
49
GenImage1(&image, "byte", (Hlong)width, (Hlong)height,
(Hlong)imageBuffer);
...
// HALCON image processing steps (see chapter 3.5.2)
...
unsigned char *imagePtr;
HTuple hwidth, hheight, ptr, type;
GetImagePointer1(ho_ImageResult, &ptr, &type, &hwidth, &hheight);
imagePtr = (unsigned char*)ptr[0].L();
long size = width * height;
unsigned char* buffer = (char*)calloc(size, sizeof(char));
memcpy(buffer, imagePtr, size * sizeof(char));
return buffer;
}
Before applying the image processing steps that were described in chapter 3.5.2 the dynamic
character array must be converted back to a HObject the same way explained above. The function must
return a dynamic character array. In order to do so, the pointer to the HObject is retrieved as already
described above and copied to another dynamic array.
3.5.4 Development of Reference Implementation using CORBA
In order to evaluate the performance of the selected ORBs (see chapter 3.4.2), it is necessary to
develop representative applications that are based on these ORBs. Each of them should implement the
same application scenario which is described in chapter 3.5.2. This makes it possible to compare the
performance of the reference implementations to each other and determine the most suitable ORB for
the image processing system of voestalpine Stahl.
This section dwells on the stepwise implementation of a CORBA application. The ORBs are
already described in detail in chapter 3.4.2, therefore this section only explains the development of
CORBA applications in general. ORBs that comply to OMG’s CORBA specification must implement
the same functionality. Therefore, it is not necessary to adapt the source code for each ORB. In order to
port applications to other ORBs, the developer is only required to use the corresponding IDL compiler
and libraries.
First, each of the selected ORBs was compiled and installed on the testing environment. Figure
13 illustrates the architecture of a CORBA application and the dependencies between its components.
The initial step of developing a CORBA application is to define the interface that describes the servant
50
objects. The interface is specified in a separate file by using the Interface Definition Language (IDL).
The syntax of the IDL and the interface of the reference implementation are elaborated in chapter 3.5.4.1.
The basics of an IDL compiler that generates the server-side skeletons and the client-side stubs is
explained in chapter 3.5.4.2. The language mapping to C++ is elaborated in chapter 3.5.4.3. Chapter
3.5.4.4 describes the implementation of CORBA objects and shows the servant function of the reference
implementation. Finally, in chapter 3.5.4.5. the client and server applications and the interaction between
them are dwelled on.
Figure 13: CORBA Applications Architecture [26]
3.5.4.1 Interface Definition Language
The interface of a CORBA object is defined with OMG’s Interface Definition Language (IDL).
The IDL [21] [47] is used for encapsulating an object interface from its concrete implementation. The
separation of the object definition and its implementation leads to more flexible and less complex
applications and facilitates the distribution over the network. The IDL forms a contract between the
server and its clients. That contract specifies the interface for accessing the server object, i.e., it describes
which operations may be called by the client and specifies the return type, the input and output
parameters, and the data types. CORBA objects are not directly delivered over the network, they need
to be transformed into low-level data types first. When the data reaches its target, it must be converted
back to a CORBA object. The interface provides information on how to marshal and de-marshal the
51
data correctly. This mechanism allows to develop server and client objects independent of the platform,
the programming language, and the network characteristics.
IDL only provides the syntax for declaring the interfaces, i.e., the data types, the operations, and
the exceptions that might be thrown. The IDL does not provide any syntax for implementing interfaces,
so it is not possible to use statements or assignments. CORBA only allows to send data types over the
network that were defined in the CORBA specification or in an IDL file. It is not possible to send any
language specific data types, e.g., C++ data types over the network. This constraint allows to use
different programming languages for the client and server application. The CORBA specification does
not offer means for integrating any external libraries or user-defined data types into the IDL file. Of
course, it is possible to work around that by defining an interface that matches the specific data type.
However, this increases the workload of the developer.
Most of the IDL syntax is based on C++ with additional data types and syntax for defining the
interfaces. The following code snippet shows the interface of the reference implementation:
typedef sequence<char> Image;
interface ImageFilter
{
Image FilterImage(in Image im, in long width, in long height);
};
The name of the interface corresponds to the name of the CORBA object [47], which is in this
case ImageFilter. A CORBA object contains the variables, operations, and the data types that are
defined in the interface. Like C++, IDL allows to define new types by using the keyword typedef. In
the sample above, an unbounded sequence of characters was defined as type Image. Defining a new
type makes it more readable and easier to use. The IDL syntax provides the keywords in and out for
specifying input and output parameters, respectively. The operation FilterImage takes a user-defined
type Image as well as the width and the height of the image as input parameters and returns a processed
image of type Image.
An interface may also be declared in a module that defines a scope where all declared interfaces
are accessible from anywhere within the module. The following code snippet shows how modules are
used in IDL:
module ImageProcessing
{
typedef sequence<char> Image;
52
interface ImageFilter
{
Image FilterImage(in Image im, in long width, in long height);
};
};
As already mentioned, CORBA only accepts the data types that are provided by the IDL. The
supported data types are listed in Table 2.
Type Description
short integer value
ranges from -215 to 215-1
long integer value
ranges from -231 to 231-1
float IEEE single-precision value
double IEEE double-precision value
char character from ISO Latin-1 character set
string character sequence from ISO Latin-1 character set, except ASCII NUL
boolean assumes TRUE or FALSE
octet used for binary values
ranges from 0-255
is the only type that does not undergo any changes of the representation
any used for arbitrary data types that are not known at compile-time
can assume any IDL type, even another any
struct can contain a number of various IDL types
enum allows to define an enumeration very much like the C++ enumeration type, but
cannot ensure that the defined enumerators are assigned with ordinal values
array allows single- as well as multi-dimensional arrays
ranges of the array must be specified since IDL does not support dynamic arrays
sequence may hold any IDL type
they can be unbounded or limited to a specific number of elements
object reference reference to a CORBA object
valuetype may contain data members and operations
Table 2: IDL Basic and Complex Types
53
The valuetype can be used to pass objects by value, i.e., if a variable of type valuetype is
passed as parameter, a copy of the variable is created that is independent of the original variable.
IDL does not support pointers to data because they are not supported in many programming
languages, e.g., Java. Instead, it provides the IDL type object reference, which may contain a
reference to a CORBA object.
3.5.4.2 IDL Compiler
The interfaces defined in IDL are independent of any programming language which improves the
portability of CORBA. However, in order to develop programs that interact with the ORB it is necessary
to create language-specific type definitions and APIs. For that purpose, an IDL compiler is used that
transforms the interfaces defined in IDL into language-specific code [21] [47]. The mechanism for the
transformation is also called language mapping. The CORBA specification supports standardized
mappings for different programming languages including C, C++, C++11, and Java. However, there are
a lot of other approaches that implement mappings for additional programming languages like Eiffel,
Modula 3, Lisp, or Visual Basic. IDL types are translated into a language type, e.g., a class in C++. IDL
operations are transformed into a language-specific method.
Every CORBA distribution is delivered with at least one IDL compiler. For each language
mapping a separate IDL compiler is required. The mappings for programming languages are usually
standardized except for those that are not included in the specification. Therefore, every IDL compiler
generates equal code for a specific programming language if they use the same IDL file as input. An
IDL compiler creates at least two files, a header and a source file, from an interface that contain the
client-side stubs and the server-side skeletons. The number of files and their names are not standardized
in CORBA, it depends on which ORB is used as already explained in chapter 3.4.2. Most ORBs offer
IDL compiler options for changing the name and number of the generated files.
3.5.4.3 Programming Language Mapping
This chapter describes the translation of IDL to C++ that is performed by the IDL compiler. As
already mentioned, the CORBA specification includes standardized language mappings for many
programming languages. The IDL to C++ mapping is equal for all CORBA implementations that support
this programming language mapping [21].
Modules that were declared in the IDL file are mapped to C++ namespaces which allows to easily
include other IDL modules with the keyword using. Identifiers are not renamed in the generated C++
54
stubs, so the data type Image that was defined in chapter 3.5.4.1 is adopted without any change. The
mapping of basic IDL types is shown in Table 3. Each of them is mapped to a type defined in the
CORBA namespace which constrains them to the specified size (see Table 2). The only exception is
string which is mapped to char*.
IDL type C++ type
short CORBA::Short
long CORBA::Long
float CORBA::Float
double CORBA::Double
char CORBA::Char
string char*
boolean CORBA::Boolean
octet CORBA::Octet
any CORBA::Any
Table 3: Mapping of Basic IDL Types
The CORBA IDL specification provides various variable-length types, including strings and
sequences. They must be dynamically allocated at run time because their size is not known at compile
time and might as well increase. For convenience reasons, the IDL compiler creates auxiliary functions
for allocating, copying, and deallocating strings which are shown in the following code snippet. They
handle the memory management of strings and relieve the developer from allocating and freeing
memory.
static char * string_alloc(ULong len);
static char* string_dup(const char *);
static void string_free(char *);
The IDL compiler generates smart pointer classes with the suffix _var that take care of allocating
variable-length types. If the variable goes out of scope, it also handles the deallocation of the object
automatically. Of course, the developer can always choose to handle memory management by himself.
However, _var types simplify the development process and are easy to use.
55
The following code snippet shows parts of the header file that is generated by the TAO IDL
compiler based on the type Image defined in the IDL file. It maps sequences to C++ classes that behave
like variable-length vectors.
class Image;
typedef ::TAO_FixedSeq_Var_T<Image> Image_var;
class Image : public ::TAO::unbounded_value_sequence<::CORBA::Char>
{
public:
Image (void);
Image (::CORBA::ULong max);
Image (::CORBA::ULong max, ::CORBA::ULong length, ::CORBA::Char* buffer,
::CORBA::Boolean release = false);
Image (const Image &);
virtual ~Image (void);
typedef Image_var _var_type;
};
The type Image_var is declared which can be used for creating a variable-length sequence of
characters. IDL types that are defined with the keyword typedef are mapped to C++ typedef.
For the client’s side, the IDL compiler generates a class for each interface defined in the IDL file.
These classes are called client-side stubs or proxy classes. The interface ImageFilter is mapped to a
new class ImageFilter. The IDL compiler usually generates a header file and a source code file,
depending on the CORBA implementation. In the code snippet below, the essential parts of the
generated header file that are necessary for the client application (see chapter 3.5.4.5) are shown.
class ImageFilter;
typedef ImageFilter *ImageFilter_ptr;
typedef TAO_Objref_Var_T<ImageFilter> ImageFilter_var;
class ImageFilter
: public virtual ::CORBA::Object
{
public:
typedef ImageFilter_ptr _ptr_type;
typedef ImageFilter_var _var_type;
virtual ::Image * FilterImage (const ::Image & im, ::CORBA::Long width,
::CORBA::Long height);
};
56
In addition to the proxy class ImageFilter, the IDL compiler also defines the two types
ImageFilter_ptr and ImageFilter_var. The type ImageFilter_ptr is a C++ pointer to a
ImageFilter object. ImageFilter_var is an object reference that behaves like a C++ smart pointer
by additionally providing memory management. The developer is free to choose which types are used.
However, with ImageFilter_var, the developer does not have to worry about deallocating the
instance.
The server-side C++ mapping offers means for implementing the CORBA objects. Like the client-
side stubs, the server-side skeletons map to IDL interfaces as described above. The reason why they are
called server-side skeletons is that they only provide a skeleton and are required to be implemented by
the developer. They are used as a base class for the CORBA object implementation. The generated
header-file of the server-side C++ mapping is shown in the following code snippet.
class POA_ImageFilter;
typedef POA_ImageFilter *POA_ImageFilter_ptr;
class POA_ImageFilter
: public virtual PortableServer::ServantBase
{
protected:
POA_ImageFilter (void);
public:
POA_ImageFilter (const POA_ImageFilter& rhs);
virtual ~POA_ImageFilter (void);
::ImageFilter *_this (void);
virtual ::Image * FilterImage (const ::Image & im , ::CORBA::Long width, ::CORBA::Long height) = 0;
};
Based on the interface ImageFilter, a skeleton class called POA_ImageFilter is generated.
The servant class must derive from POA_ImageFilter. Details on the servant class can be found in
chapter 3.5.4.4.
3.5.4.4 Servant
Since the developer is not required to take care of handling network connections between the
server and its clients, they can focus on the concrete implementation of the CORBA object, i.e., the
servant. This greatly simplifies the development process and reduces the development time. Servant
classes contain the concrete implementation of a CORBA object. The instances of servant classes
57
incarnate the CORBA object. Therefore, in order to create an instance of the CORBA object
ImageFilter, it is necessary to implement a servant class. The IDL compiler can optionally generate
a placeholder file for the servant class, but it can also be created manually by the developer. Servant
classes must redeclare the inherited functions of the server-side skeletons. This gives rise to potential
mistakes because function names, signatures, or exception specifications might be written differently
than they were defined in the base class. Therefore, it might be the case that the virtual functions are not
implemented at all. For that reason, it is recommended to automatically generate the skeleton classes if
the IDL compiler supports it.
The naming convention for servant classes prescribes to add the suffix _impl to the name of the
CORBA object. However, it does not affect the functionality of the CORBA application if they are
named differently. As the servant of the reference implementation, a class called ImageFilter_i is
created that derives from the base class POA_ImageFilter as described in the previous chapter. The
code snippet below shows the header file of the servant class.
class ImageFilter_i : public virtual POA_ImageFilter
{
public:
virtual ::Image * FilterImage (const ::Image & im, ::CORBA::Long width,
::CORBA::Long height);
};
The servant class must implement all virtual functions that were declared in the server-side
skeletons. In the case of the sample application, only the function FilterImage must be implemented.
The function anticipates the image stored in the sequence Image, the width and the height of the image.
Since HALCON operations are designed to perform on HALCON objects only, it is necessary to convert
the user-defined CORBA data type Image into a HALCON object HObject first. By using the function
get_buffer a pointer to the data of the sequence is retrieved. The HALCON object can be constructed
by passing the acquired pointer the HALCON function GenImage1 as shown in the code snippet below.
HObject halconImage;
GenImage1(&halconImage, "byte", (Hlong)width, (Hlong)height,
(Hlong)im.get_buffer());
However, such transformations might have an impact on the performance of the CORBA
application.
58
It is now possible to perform the predefined image processing steps on the converted HALCON
object. The image filters are already described in detail in chapter 3.5.2.
HObject ho_EdgeAmplitude, ho_Region;
HObject ho_Image1, ho_ImageResult;
HTuple hv_Width, hv_Height;
SobelAmp(halconImage, &ho_EdgeAmplitude, "sum_abs", 3);
Threshold(ho_EdgeAmplitude, &ho_Region, 30, 255);
GetImageSize(halconImage, &hv_Width, &hv_Height);
GenImageConst(&ho_Image1, "byte", hv_Width, hv_Height);
PaintRegion(ho_Region, ho_Image1, &ho_ImageResult, 255, "fill");
The servant function returns an object of type Image, therefore the resulting HALCON object
ho_ImageResult must be converted back to the type Image before it can be returned to the client. For
that purpose, the function GetImagePointer1 is used to return the pointer to the HALCON object in
the HALCON database. The function L returns a pointer to the data of the object. The sequence
retImage is filled by first retrieving a pointer to the data with get_buffer and then copying the
content of the HALCON object.
unsigned char *imagePtr;
HTuple hwidth, hheight, HTuple ptr;
HTuple type;
GetImagePointer1(ho_ImageResult, &ptr, &type, &hwidth, &hheight);
imagePtr = (unsigned char*)ptr[0].L();
Image *retImage = new Image; // create empty sequence
long size = im.length();
char* buffer = retImage->get_buffer();
memcpy(buffer, imagePtr, size * sizeof(char));
return retImage;
3.5.4.5 Client and Server Application
In order to invoke operations on CORBA objects, it is necessary to develop client and server
applications. These applications are required to implement a main function that incarnates the defined
CORBA objects.
59
The server application waits for clients to send requests which are dispatched through the POA to
the servant implementation. In order to do so, first an object reference to the ORB is initialized with
ORB_init:
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
The function anticipates the program arguments that are passed to the main program. The ORB
is used to retrieve an object reference to the POA which can be used for obtaining the POAManager. By
activating the POAManager, the Root POA is able to process requests from clients as soon as the ORB
listens for them.
CORBA::Object_var obj = orb->resolve_initial_references("RootPOA");
PortableServer::POA_var poa = PortableServer::POA::_narrow(obj.in());
PortableServer::POAManager_var mgr = poa->the_POAManager();
mgr->activate();
The type PortableServer::Servant_var<ImageFilter_i> returns a safe counted
reference of the servant class ImageFilter_i, i.e., if the object instance goes out of scope, it is
deallocated automatically.
PortableServer::Servant_var<ImageFilter_i> servant = new ImageFilter_i();
A CORBA client application requires an object reference of the CORBA object in order to
connect and invoke operations on it. For that purpose, the Interoperable Object Reference (IOR) is
retrieved. The IOR must be converted to a string to make it available for client applications.
PortableServer::ObjectId_var oid = poa->activate_object(servant.in());
obj = poa->id_to_reference(oid.in());
CORBA::String_var str = orb->object_to_string(obj.in());
The stringified object reference can either be written to the standard output or a file. In this case,
the object reference is written to the file ImageFilter.ior.
ofstream iorFile("ImageFilter.ior");
iorFile << str.in() << std::endl;
iorFile.close();
60
The content of the IOR file looks like the following:
IOR:010000001400000049444c3a496d61676546696c7465723a312e3000010000000
00000008800000001010200270000006b6572736368692d48502d5a3834302d576f72
6b73746174696f6e2e6d73686f6d652e6e65740000e08800001b00000014010f00525
354bebea1589d79060000000000010000000100000000020000000000000008000000
01000000004f415401000000180000000100000001000100010000000100010509010
10000000000
Finally, the server ORB can be executed by calling the function run to enable it to listen to clients’
requests.
orb->run();
Just like the server application, the client also must initialize an object reference of the ORB.
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
As already mentioned, the client application uses the stringified object reference to connect to a
servant and invoke operations on it. The IOR is retrieved from the IOR file with the function
string_to_object. The function _narrow returns the object reference of the CORBA object
ImageFilter. To be more precise, _narrow returns a copy of the object that is converted to the type
ImageFilter_var which can be used to invoke operations on the CORBA object.
CORBA::Object_var obj = orb->string_to_object("file://ImageFilter.ior");
ImageFilter_var imageFilter = ImageFilter::_narrow(obj.in());
The client application reads in the image file Flower.jpg and stores it into a HALCON object
HObject.
HObject image;
ReadImage(&image, "Flower.jpg");
61
The stored image must be converted into a CORBA object. In order to do so, the pointer to the
image is retrieved with the HALCON functions GetImagePointer1 and L as already explained in
chapter 3.5.3.
unsigned char *imagePtr;
HTuple width, height, ptr, type;
GetImagePointer1(image, &ptr, &type, &width, &height);
imagePtr = (unsigned char*)ptr[0].L();
A new instance of the CORBA sequence Image is created and allocated with the size of the
image. In order to fill the Image object with the image, the functions get_buffer and memcpy are used
as already explained in chapter 3.5.4.4.
long size = width * height;
Image * newImage = new Image;
newImage->length(size);
char* buffer = newImage->get_buffer();
memcpy(buffer, imagePtr, size * sizeof(char));
After converting the HALCON object HObject to Image, it is possible to call the servant function on
the CORBA object ImageFilter.
Image * retImage = imageFilter->FilterImage(*newImage, width, height);
The function returns the processed image which must be transformed back to a HALCON object. For
that purpose, the pointer to the data of the processed image is passed to the HALCON function
GenImage1 which generates a HALCON object. WriteImage writes the processed image to the file
Flower_processed.tiff.
HObject processedImage;
GenImage1(&processedImage, "byte", (Hlong)width, (Hlong)height,
(Hlong)retImage->get_buffer());
WriteImage(processedImage, "tiff", 0, "Flower_processed");
62
After creating the necessary components IDL file, server-side skeletons, client-side stubs, and the
client- and server applications, the developer is able to compile the CORBA applications and link the
required libraries to it. As already mentioned in chapter 3.4.2, it depends on the ORB which libraries
must be linked to the application. If all prerequisites are met, the server application can be started. It is
important to note, that the client cannot connect if the server is not running. The server writes the IOR
to the standard output or a file and waits for any clients to connect with the correct IOR.
3.6 Performance Evaluation
The main objective of this master’s thesis is to determine a technology that allows the distribution
over the network and supports stringent real-time requirements. A camera is part of the image processing
system which takes photos of steel slabs several times per second. The new system should be able to
process those images immediately in real time. Therefore, an additional requirement on the CORBA
implementation is that it offers a high performance. This section dwells on the performance evaluation
of the developed CORBA applications to identify which ORB matches those requirements best.
Additionally, the overhead of the CORBA applications is determined by comparing their performance
with the monolithic system that was developed with Qt. In order to utilize the full potential of an ORB,
some possibilities for optimizing the performance are elaborated and applied on the CORBA application.
Chapter 3.6.1 dwells on the performance evaluation of CORBA applications. It describes how the
performance is measured and presents the results. The different approaches for optimization and their
results are described in chapter 3.6.2.
3.6.1 Measuring the Performance
The ORBs have different performances because the CORBA specification does not describe how
the standards must be implemented [17]. Additionally, each ORB might show varying performances on
different platforms. For that purpose, a performance evaluation is conducted on the selected ORBs.
Based on the evaluation it will be decided which ORB fits best for the requirements of the system.
In order to compare the performances of the different ORBs and the monolithic system to each
other, the computational latency is measured. The computational latency identifies the time needed for
calling the filter function on the CORBA object until the results are returned, i.e., the time needed for
completing the task. The reason for measuring the computational latency is to determine the overhead
of CORBA applications due to marshalling and de-marshalling of the data that is exchanged between
63
the server and client ORBs. The marshalling and de-marshalling operation are implemented differently
for each CORBA implementation. Therefore, overhead of the data transformation might vary between
them.
3.6.1.1 Benchmark System
There are several benchmark environments available for evaluating the performance of CORBA
applications [17] [48]. However, in order to accurately measure the computational latency, it was
decided to build a proprietary benchmark system. For that purpose, a data acquisition card and a
microcontroller were used as described in chapter 3.5.1.1. The benchmark system should start the
measurement of the latency before calling the function FilterImage on the CORBA object and stop
it as soon as the processed image is returned.
By using the Comedi driver and Comedi library (see chapter 3.5.1.3), two signals are sent to the
data acquisition card before calling the function on the CORBA object and after returning the results.
The microcontroller is triggered whenever a rising signal is sent to the hardware I/O card and calculates
the time difference between them. In order to access a Comedi device, i.e., the data acquisition card, it
must first be opened with comedi_open which returns a pointer to it.
comedi_t * it;
it = comedi_open("/dev/comedi0");
Before writing to a specific channel on the Comedi device, it must first be configured with
comedi_dio_config. The function expects a pointer to the device as well as the subdevice, the
channel, and whether it is used as input or output.
int comedi_dio_config (comedi_t * device,
unsigned int subdevice,
unsigned int channel,
unsigned int direction);
As already explained in chapter 3.5.1.3, the sub-device used for digital input/output is
subdevice 2. Channel 0 and channel 1 are connected to the Arduino pins number 2 and number
3 respectively. The following code snippet configures channel 0 and channel 1 of subdevice 2
as output.
64
comedi_dio_config(it, 2, 0, COMEDI_OUTPUT);
comedi_dio_config(it, 2, 1, COMEDI_OUTPUT);
In order to measure the computational latency of remote functions, the signals are sent to the data
acquisition card before and after calling the function. For that purpose, Comedilib offers the function
comedi_dio_write [42] which allows to write a rising or falling signal to a specific channel to the
hardware I/O card. The signature of the function is shown in the code snippet below.
int comedi_dio_write(comedi_t * device,
unsigned int subdevice,
unsigned int channel,
unsigned int bit);
The first rising signal is sent to channel 0 before calling the function FilterImage on the
CORBA object. After the result is returned, the second rising signal is sent to channel 1.
comedi_dio_write(it, 2, 0, 1);
Image * retImage = imageFilter->FilterImage(*newImage, width, height);
comedi_dio_write(it, 2, 1, 1);
The Arduino microcontroller can be programmed with the open source tool Arduino IDE [49].
The microcontroller allows to define interrupts [50] for several pins that are triggered if the value of a
pin changes. The advantage of interrupts is that it is possible to define some functionality that should be
executed automatically whenever they are triggered by a certain signal. Interrupts [51] can be triggered
on rising or falling signal edges. The user is able to define the pins where interrupts should be triggered,
the mode when they are triggered, e.g., rising or falling signal edges, and how to handle them. For that
purpose, the function attachInterrupt is provided.
attachInterrupt(<interruptNumber>, <ISR>, <mode>)
The Arduino Mega 2560 board offers the digital pins 2, 3, 18, 19, 20, 21 for the definition of
interrupts. It is possible to pass the pin number or the interrupt number as parameter to the
attachInterrupt function. However, this is not recommended because the same program might not
work with another Arduino board. The reason is that the pin numbers and the mapping of interrupt
numbers are different for each board (see Figure 14).
65
Figure 14: Pins and Interrupt Numbers of Arduino Boards [50]
Therefore, the function digitalPinToInterrupt is provided which returns the interrupt
number for a corresponding pin number. However, for the purpose of this master’s thesis it is sufficient
to simply use the interrupt number because the microcontroller will not be changed.
Interrupt Service Routines (ISRs) enable the developer to define the functionality that should be
performed when an interrupt is called. They are functions that must not have any parameters or a return
value. There may only run one ISR at the same time. Therefore, other interrupts have to wait until the
execution of the ISR is completed and are then called in the order depending on their priority. The mode
defines when an interrupt should be called. It is possible to set four different constants: (1) LOW, (2)
CHANGE, (3) RISING, and (4) FALLING. When using the constant LOW the interrupt is triggered if the
value of the pin is low. RISING and FALLING can be used to trigger an interrupt for a rising or a
falling signal edge, respectively. CHANGE calls the interrupt if the value of the pin changes. The ISR is
used to retrieve the time when an interrupt is called.
In the following, the Arduino program for measuring the computation latency is described. In
order to pass data between interrupts, global variables are used which should be declared as volatile.
This allows to change the value of the global variables outside of the program. For that purpose, two
global variables were defined that are responsible for storing the current time when the interrupts are
triggered.
volatile unsigned long time0;
volatile unsigned long time1;
An Arduino program must contain the two functions setup and loop as shown in the code
snippet below. The setup function opens a serial output with a baud rate of 9600 which is used for
writing the calculated time difference. The two global variables time0 and time1 are initialized with
the current time in microseconds. Additionally, the interrupts isr0 and isr1 are attached. The first
66
interrupt isr0 is triggered if a rising signal is sent to pin number 2 and isr1 is called if pin number 3
has a rising signal. The function loop may remain empty.
void setup() {
Serial.begin(9600);
time0 = micros();
time1 = time0;
attachInterrupt(0, isr0, RISING);
attachInterrupt(1, isr1, RISING);
}
void loop()
{ }
Both ISRs determine the current time in microseconds by using the built-in function micros().
isr1 calculates the time difference of the two signals and writes it to the serial port.
void isr0()
{
time0 = micros();
}
void isr1()
{
time1 = micros();
Serial.print(time1-time0);
Serial.print(";");
time0=time1;
}
The output of the serial port can be viewed with any program for serial communication. In order
to statistically interpret the results, it should additionally be possible to write the output to a file. For that
purpose, it was decided to use moserial [52].
3.6.1.2 Performance Results
The time difference of the first and the second rising signal represents the computational latency
of the filter function. The computational latency was measured for the monolithic system and for each
of the chosen CORBA implementations. Since the performance varies between a certain range for each
invocation, the filter function was executed 400 times. The computational latency of the different
67
approaches was statistically evaluated by calculating the mean value, the minimum, the maximum, and
the median. Additionally, line diagrams and boxplot diagrams were drawn for a better presentation of
the results of the different approaches. For the calculation of the statistical values, the programming
language R was used with the open-source software RStudio [53]. The performance evaluation was
conducted with collocated server and client applications, i.e., the client and server were executed in the
same address space (see chapter 3.6.2.1 for more information on collocation).
The computational latency of TAO fluctuates between 9.8 and 27 milliseconds. As expected, the
first invocation of the filter function has the worst latency with 27 milliseconds because the program
must allocate the data in the memory. The median of the computation latency is 11 milliseconds which
represents the typical time needed for invoking the function FilterImage on the CORBA object.
Figure 15 represents the performance trend of TAO for 400 iterations.
Figure 15: TAO Performance Trend
The computational latency of omniORB varies between 46 and 123 milliseconds which is
significantly slower than the TAO application. The typical time needed for calling the servant function
FilterImage is 49 milliseconds. The performance trend of omniORB illustrated in Figure 16 shows
several extreme fluctuations between the minimum and the maximum computational latency.
68
Figure 16: omniORB Performance Trend
For the first invocation of the filter function, MICO has a computational latency of 29.6
milliseconds which is also the maximum value. The minimum computational latency of MICO is 8.6
milliseconds. The performance trend of MICO shows that most invocations tend to take about 10
milliseconds.
Figure 17: MICO Performance Trend
69
The results of Table 4 and Table 5 depict that the monolithic system that is based on Qt performs
better than the CORBA applications. omniORB performs by far the worst with a mean computational
latency of 54 milliseconds and a difference of 49 milliseconds to the monolithic system. Therefore,
omniORB is obviously not suitable for the image processing system, since it is necessary to transfer
rather big image files over the network. The fastest ORB is MICO with 11 milliseconds and only a
difference of 5 milliseconds to the Qt implementation. The computational latency of TAO is 12
milliseconds and shows a difference of 7 milliseconds to Qt. Since the client and server applications are
executed in the same address space, it is not necessary to marshal and de-marshal the data. Therefore,
the overhead of the CORBA application only results from the abstraction of the CORBA architecture
and the invocation of the servant function through the POA.
For the image processing system, an overhead of 5-7 milliseconds is acceptable. The results proof
that CORBA is a suitable technology for the adaption of the new system.
Qt TAO omniORB MICO
Mean [µs] 5360.9 12283.18 54355.03 10784.14
Minimum [µs] 3764 9840 46168 8632
Maximum [µs] 22436 27016 123492 29696
Median [µs] 5326 11136 49232 10110
Table 4: Performance Evaluation Qt, TAO, omniORB, MICO
The performance of an ORB depends on how well it works together with the system environment
including the operating system, the network, and the hardware [17]. The results above do not show that
MICO has the best performance among the selected CORBA implementations. The performance
evaluation simply represents that it might be best suited for the given setup and the specific application
scenario. The differences of mean values compared to the monolithic implementation with Qt are shown
in Table 5. In Figure 18, the differences between the different reference implementations are clearly
depicted using a boxplot diagram.
TAO omniORB MICO
Δt [µs] 6922.28 48994.13 5423.24
Table 5: Difference of Mean to Monolithic System (Δt)
70
Figure 18: Performance Evaluation Qt, TAO, omniORB, MICO
Since the architecture of the new image processing system will require the distribution over the
network, a performance evaluation was conducted where the client and the server application are
executed on different computers. Table 6 shows the mean computational latency, the minimum, the
maximum, and the median value. The computational latency ranges from 59 to 75 milliseconds. A
71
typical invocation of the filter function on the CORBA object that is not arranged in the same address
space as the client takes 62 milliseconds.
Mean [µs] Minimum [µs] Maximum [µs] Median [µs]
61801.48 58524 75416 61518
Table 6: TAO Network Performance Evaluation
The loss in performance compared to the collocated TAO application is mainly because of the
transmission of the image over the network. By using the tool Wireshark [54], it is possible to determine
that the time needed for transferring an image over the network is about 25 milliseconds. The image is
sent over a Gigabit Ethernet network connection which allows to transfer 125 Mbit per seconds, i.e., it
takes 0.008 seconds to send 1 MB. The application processes an image with a size of 2.5 MB which
would require 20 milliseconds for the transmission over the network. Therefore, it is reproducible that
it takes about 25 milliseconds until the image reaches its target considering that requests and responses
exchanged between the server and client application are also included. Based on the assumptions above,
it takes about 50 milliseconds to send the request including the image to the server and to receive the
response by the client. The remainder of the computational latency make up about 12 milliseconds for
invoking the function on the CORBA object and processing the image on the server-side. Figure 19
shows the performance trend for the invocation of the servant function in a distributed system.
Figure 19: TAO Network Performance Trend
72
Gokhale et al. [22] conducted a research on reasons for the inferior performance of
communication middleware like CORBA compared to low-level technologies like sockets. One reason
is that the mechanisms for marshalling and de-marshalling data, data copying, and memory management
are not optimized. Additionally, request and response messages that are exchanged between the client
and server ORBs contain a lot of control information. The overhead also results from operations for
demultiplexing and dispatching that are not efficient enough. They also found out, that CORBA
performs several intra-ORB function calls that contribute to the overhead. Another issue is that CORBA
implementations do not make use of mechanisms of the operating system that would improve the
performance. Gokhale et al. [15] also sum up that the scalability for current CORBA implementations
is rather bad as the number of objects increase drastically. Khan et al. [16] also come up with the same
conclusion. They conducted a performance evaluation on different middleware technologies including
ICE, HORB, CORBA, and .NET Remoting. Among them, CORBA has the worst latency that
significantly rises as the number of clients increases as shown in Figure 20.
Figure 20: Latency Comparison for Primitive Data Types [16]
CORBA generates more network overhead than other distributed technologies according to Khan
et al. [16] as can be seen in Figure 21. The reason is that the standard Internet Inter-ORB Protocol (IIOP)
uses the Common Data Representation (CDR) which performs padding on messages that are exchanged
between the client and server.
73
Figure 21: Overhead comparison for primitive data types [16]
In order to determine, whether CORBA is an appropriate technology for the development of the
new system, the real-time capabilities should be evaluated as well. Even though the testing environment
has a real-time kernel, the CORBA applications are not automatically executed as real-time applications.
It is possible to configure a real-time application by making use of the execution scheduling header
sched.h [55] which offers functionalities for specifying the priority and the scheduling policy. The
following code snippet represents a simple example on how to simply configure a real-time server
application.
int main(int argc, char * argv[])
{
struct sched_param param;
param.sched_priority = 49;
if(sched_setscheduler(0, SCHED_FIFO, ¶m) == -1)
{
perror("sched_setscheduler failed");
return -1;
}
...
// CORBA Server Source Code
...
}
The real-time scheduling parameters sched_param are defined at the beginning of the server’s
main function. Kernel tasks and the interrupt handler run with the priority 50 [41]. Therefore, the
74
application’s priority is set to 49 so that it will not take any computing capacity away from them. The
scheduler for the server application is configured with sched_setscheduler. The function expects
the scheduling parameters and the scheduling policy. The scheduling policy is set to SCHED_FIFO that
obliges to the so called First In - First Out scheduling principle.
If this program is executed normally with the usual CPU utilization, there is little difference in
performance compared to a non-real-time TAO application as shown in Table 7. However, if the
computer is fully utilized with for instance a benchmarking tool like Prime95 [56], the non-real-time
TAO application reaches a mean value of about 26 milliseconds, whereas the real-time application even
performs faster than usual with a mean computational latency of 11 milliseconds. The differences in
performance are illustrated in Figure 22 using a boxplot diagram.
No Stresstest /
no RT
Stresstest / no RT Stresstest / RT
Mean [µs] 12283.18 26019.45 10659.92
Minimum [µs] 9840 11068 9640
Maximum [µs] 27016 143472 16620
Median [µs] 11136 22696 10416
Table 7: Performance Evaluation of Stresstest RT
3.6.2 Performance Optimization
As shown in the last chapter, CORBA applications that are based on TAO or MICO perform
rather good when compared to the monolithic system. The mean value of the computational latencies
only differs by 5-7 milliseconds. The results are satisfying, but there are some optimization techniques
offered by CORBA to improve the performance even further. TAO implicitly offers means for
improving the performance of CORBA applications. Among the evaluated ORBs, TAO is considered
the most appropriate for the image processing system because of its high performance and the support
of hard real-time requirements. Therefore, it was decided to focus on the optimization techniques of
TAO and to bring out the best of the CORBA implementation.
TAO offers techniques for optimizing the performance if the client and the server application
reside in the same address space, i.e., collocation which is further described in chapter 3.6.2.1. It also
comes with another possibility to enhance the performance by introducing the pluggable protocol
factories [25] which are dwelled on in chapter 3.6.2.2.
75
Figure 22: Performance Evaluation Stresstest RT
The feature allows to change the default transport protocol (IIOP). For that purpose, TAO offers
a set of pre-defined transport protocols, like shared memory, collocation, secure transport, etc. The
developer can choose to either use pre-defined protocols or to develop user-defined protocols that might
be more suitable for a specific application context.
Aside from the implicit optimization possibilities that TAO offers, there are quite a few other
approaches for improving the performance of CORBA applications. In [17], research has been
76
conducted on optimizing the IDL compiler. The CORBA specification imposes a huge performance loss
due to marshalling and de-marshalling data. The Flick project offers an IDL compiler that allows to
generate stubs that improve the marshalling and de-marshalling process drastically.
3.6.2.1 Collocation
There is the possibility that server and client applications are executed on the same ORB, i.e.,
they run in the same address space. Figure 23 depicts such a case where the server and the client interact
with each other without sending data to another ORB. For clients and servers that are executed on the
same ORB the additional overhead that results from marshalling and de-marshalling data is omitted.
CORBA offers a mechanism called collocation [57] which allows to transparently optimize applications
that run on the same ORB.
Figure 23: Communication on the same ORB [28]
The developer is not required to change the source code because TAO takes care of handling
collocation. The reference to a CORBA object can be retrieved through different ways, e.g. from the
CORBA Naming Service or by converting the interoperable object reference (IOR) into an object
reference. Independent of how the object reference is retrieved, the ORB core is able to determine if the
server and client application are in the same address space and in that case, obtains a collocated stub and
proxy. The ORB core uses a collocation table in order to identify whether an object reference is
collocated. TAO offers two possibilities for transparent collocation optimization: (1) the standard
collocation that calls servant functions through the POA, and (2) the direct collocation that bypasses the
POA.
The standard collocation strategy retrieves a collocation-safe stub in case of collocation that
guarantees that no invalid state is reached. For instance, by using collocation-safe stubs CORBA ensures
that the server ORB, the servant of the collocated object, and the POA which handles access to the
77
servant are still running. It also guarantees thread-safety by using the required locks. Only if an
invocation of an operation is safe, the request is sent to the servant operation by going through the POA.
By doing so, the stub downcasts the servant to a concrete servant type and directly calls the servant
operation without marshalling/de-marshalling the data.
For the direct collocation strategy, requests are sent directly to the servant without relying on the
POA. This option might impose some risks, because the assurances that are valid for the standard
collocation strategy are not met. The direct collocation strategy is particularly of use for real-time
applications that afford stringent latency requirements. Figure 24 shows which classes are involved for
both collocation strategies in TAO.
Figure 24: TAO Collocation [57]
The ORB provides an additional collocation class that is not specified in the CORBA standard.
This class cannot be accessed by the developer and is only implicitly used by the ORB if the client and
the server application are arranged in the same address space. The whole process of calling an operation
of a collocated CORBA object is described in Figure 25.
There is one issue that comes with TAO’s collocation strategies, namely, that collocated CORBA
applications execute servant operations in the client’s thread with the client’s priority. This might cause
priority inversion, which is not desired for real-time applications. In the first place, the great benefit of
Real-time CORBA is, that it is able to avoid priority inversion which is one of the requirements of the
new image processing system. However, TAO provides access policies that can be assigned to endpoints
78
which makes it possible to avoid priority inversion by hiding the fact that they are collocated from other
priority groups.
Figure 25: Operation Call of a Collocated Object [57].
The TAO IDL compiler is able to generate collocated stubs depending on which option is used.
The option -Gp tells the IDL compiler to generate stubs for invoking operations through the POA which
is used by TAO by default. The option -Gd is used for the direct collocation strategy. The collocation
strategy that should be used by TAO is set by passing the program option ORBCollocationStrategy
with the value direct or thru_POA to the server and client ORB when initializing them. The code
snippet below shows the execution of the client and server applications using the direct collocation
strategy.
./ImageFilterClient -ORBCollocationStrategy direct
./ImageFilterServer -ORBCollocationStrategy direct
Table 8 and Figure 26 present the results of the performance evaluation for the collocation
strategies described above. They present the mean computational latency, the minimum, the maximum,
and the median of both collocation strategies and compare them to an invocation over the network when
no collocation is used. The direct collocation strategy slightly improves the performance by 1.5
milliseconds. However, as already explained in detail above, the direct collocation strategy is not as safe
79
as when dispatching requests through the POA. Since there is only a marginal improvement, the standard
collocation strategy is preferred over the direct one.
No Collocation (over Network) Through POA Direct
Mean [µs] 61801.48 12283.18 10822.46
Minimum [µs] 58524 9840 9916
Maximum [µs] 75416 27016 23628
Median [µs] 61518 11136 10522
Table 8: Performance Evaluation of Collocation Strategies
Figure 26: Performance Evaluation of Collocation Strategies
80
3.6.2.2 Pluggable Protocols
The CORBA specification defines a messaging protocol for inter-ORB communication which is
called General Inter-ORB protocol (GIOP) [25]. The Internet Inter-ORB Protocol (IIOP) is based on the
GIOP and uses the Transmission Control Protocol/Internet Protocol (TCP/IP) for communication
between ORBs from the same or different vendors. In addition to GIOP, the CORBA specification
supports the DCE Environment Specific Inter-ORB Protocol (ESIOP) which allows to implement user-
defined protocols for inter-ORB communication. TAO comes with some pre-defined ESIOPs that are
listed in Table 9.
Pluggable Protocol Description
IIOP Internet Inter-ORB protocol
Default
UIOP Local IPC socket-based transport protocol
SHMIOP Shared memory transport protocol
DIOP Datagram (UDP) transport protocol
SSLIOP IIOP over Secure Sockets Layer session protocol
SCIOP SCTP Inter-ORB protocol (UNIX only)
HTIOP HTTP Tunneling Inter-ORB Protocol
Asymmetric protocol for communication across firewall
using HTTP tunnels
MIOP/UIPMC Multicast Inter-ORB Protocol (MIOP)
Unreliable IP Multicast protocol (UIPMC)
ZIOP IIOP-variant with compression of the messages
COIOP Collocated-Only Inter-ORB Protocol
Table 9: Pre-defined Pluggable Protocols
Since evaluating all of the pre-defined ESIOPs would go beyond the scope of the master’s thesis,
only a few were selected that seemed to be of interest. The IIOP is used by default by all CORBA
implementations. The ESIOPs that were evaluated in addition to the IIOP are (1) UIOP, (2) SHMIOP,
and (3) COIOP.
UIOP allows to invoke functions on CORBA objects over Unix Domain Sockets. Unix Domain
Sockets are also called local IPC. They improve the performance of communication between processes
81
if they run on the same host. The UIOP protocol can be dynamically loaded through the service
configurator, by specifying a file called svc.conf in the application’s directory with the following
content:
dynamic UIOP_Factory Service_Object
*TAO_Strategies:_make_TAO_UIOP_Protocol_Factory () ""
dynamic Advanced_Resource_Factory Service_Object *
TAO_Strategies:_make_TAO_Advanced_Resource_Factory ()
"-ORBProtocolFactory UIOP_Factory"
The dynamic keyword takes care of dynamically loading and initializing service objects from
libraries. In the code snippet above, it loads and initializes the UIOP_Factory.
When calling the server application, it is necessary to define an endpoint where the ORB will
listen for requests. For that purpose, the CORBA specification provides the option
ORBListenEndpoints. For the specification of the endpoint the prefix uiop:// is followed by a Unix
domain rendezvous point. It is possible to explicitly define the rendezvous point or leave it empty and
use an ephemeral rendezvous point. If the rendezvous point is not explicitly given, TAO generates a file
in a temporary directory like tempnam() or tmpnam() depending on the current platform. Ephemeral
rendezvous points are removed when the ORB is destroyed. The UIOP endpoint is specified as a
program option when executing the server application as shown in the code snippet below:
./ImageFilterServer -ORBListenEndpoints uiop://
SHMIOP allows to invoke functions on a servant object by using shared memory between the
client and the server application. The ESIOP only works for CORBA applications that run on the same
host and are able to access data through shared memory. SHMIOP does not make use of the System V
Unix shared-memory IPC mechanism.
Like the UIOP protocol, the SHMIOP protocol can be loaded by defining a service configurator
file that contains the following code:
dynamic SHMIOP_Factory Service_Object
*TAO_Strategies:_make_TAO_SHMIOP_Protocol_Factory () ""
dynamic Advanced_Resource_Factory Service_Object *
TAO_Strategies:_make_TAO_Advanced_Resource_Factory ()
"-ORBProtocolFactory SHMIOP_Factory"
82
Additionally, SHMIOP requires to specify the maximum size of messages with the option
MMAPFileSize. TAO restricts the maximum size of messages to only 10k bytes. It includes the
message size of the request and the size of the reply. It is recommended to use the following
calculation formula for the definition of the maximum size:
(MAX_REQUEST_SIZE + MAX_REPLY_SIZE) * SAFETY_FACTOR
The size of the sample image sent to the server and the resulting image that is returned to the
client are both about 2.5 MB. Therefore, the following maximum size of messages can be assumed:
(2.5 MB + 2.5 MB) * 3 = 15 MB = 15000000 bytes
The maximum size can also be specified in the service configurator file by adding the following
line:
static SHMIOP_Factory "-MMAPFileSize 15000000"
Like the UIP endpoint, the SHMIOP endpoint must be defined as well. For that purpose, the
option ORBListenEndpoints is used with the value shmiop:// and an optional port number as
shown in the code snippet below:
./ImageFilterServer -ORBListenEndpoints shmiop://
COIOP is used on systems with no network interfaces or if both the client and the server
application should run on the same ORB to improve the performance. The difference to the evaluated
ESIOPs above is that it requires TAO to be compiled explicitly with the definition TAO_HAS_COIOP
because it is not built by default. Additionally, other ESIOPs should be excluded from the installation
process. This can be done by adding the following code in the config.h file before starting the
compilation process of TAO:
#define TAO_HAS_IIOP 0
#define TAO_HAS_UIOP 0
#define TAO_HAS_DIOP 0
#define TAO_HAS_SHMIOP 0
83
#define TAO_HAS_COIOP 1
One more requirement is that the library TAO_Strategies must be linked to the CORBA
application. As soon as those prerequisites are met, the server and client applications can be executed.
However, if they are not running on the same ORB, an exception is thrown. COIOP optimizes the
application depending on the specified collocation strategy. If collocation is turned off by using the
option -ORBCollocationStrategy no, the application also terminates with an exception.
Table 10 shows the mean, the minimum, the maximum, and the medianof the computational
latency of the evaluated ESIOPs. SHMIOP performs the best with a mean computational latency of 10.9
milliseconds. The UIOP protocol scarcely improves the performance in comparison to the IIOP with the
standard collocation strategy. The performance improvement of COIOP is about 0.6 milliseconds. Since
COIOP makes use of TAO’s collocation optimizations it is not very surprising that the performance is
about the same compared to when using the standard collocation strategy. To summarize, the overall
performance improvement is only marginal when using the evaluated ESIOPs. However, if the
performance of the TAO application should be improved a little, then the SHMIOP protocol is
recommended.
IIOP UIOP SHMIOP COIOP
Mean [µs] 12283.18 12130.53 10931.77 11630.76
Minimum [µs] 9840 9348 10040 10080
Maximum [µs] 27016 27128 25480 26420
Median [µs] 11136 11184 10494 11016
Table 10: Performance Evaluation of ESIOPs
84
Figure 27: Performance Evaluation of ESIOPs
85
4 Conclusion and Future Work
4.1 Conclusion
This master’s thesis evaluated different ORBs to determine whether CORBA is a suitable
technology for the adaption of the existing image processing system at voestalpine Stahl. An ORB
should fulfill certain criteria that are of significance for the company, but also personal requirements to
simplify the development of CORBA applications. An additional requirement to an ORB is that it should
offer a high performance that can compete with a low-level application, e.g. C++ sockets. For the
performance evaluation, the computational latency of the invocation of a function on a CORBA object
was measured. It determines the time needed for calling a servant function until the results are returned
to the client. For that purpose, a list of various CORBA implementations was elaborated that seemed to
be of interest. A criteria evaluation was conducted on them regarding requirements like programming
language, real-time support, quality of documentation and tutorials, kind of license (commercial or open-
source), etc. There were quite a few CORBA implementations that passed the criteria evaluation.
However, within the scope of this master’s thesis, not all of them could be evaluated further to measure
their performance. Therefore, only a few were selected from the list of suitable ORBs: (1) The ACE
ORB (TAO), (2) omniORB, (3) MICO IS CORBA (MICO), and (4) VisiBroker.
The performance of omniORB is not satisfying because it performs about 54 milliseconds slower
than the monolithic system which is not acceptable for the adaption of the image processing system.
Additionally, omniORB does not support hard real-time requirements. Therefore, omniORB is not
considered a candidate for the development of the new system.
Surprisingly, MICO offers the best performance among the evaluated ORBs. The computational
latency of a CORBA application based on MICO is only 5 milliseconds higher than that of the
monolithic system. Unfortunately, MICO does not support the definition of hard real-time constraints.
VisiBroker requires the installation of the JDK and JRE which is not in the favor of the company.
However, VisiBroker supports custom marshalling which would be an asset. Therefore, it was evaluated
anyway to determine whether that feature could compensate for the prerequisites. However, the
installation of VisiBroker was troublesome on the target operating system. Therefore, it was not possible
to conduct a performance evaluation on the ORB.
TAO is the most promising ORB because it supports hard real-time requirements and possesses
a high performance. The performance evaluation showed that if the client and server applications are
86
executed in the same address space, it can compete with a monolithic system with a difference of about
7 milliseconds. This master’s thesis has also shown that it is possible to optimize TAO applications by
1-2 milliseconds. TAO offers two collocation strategies, the standard and the direct one. The standard
collocation strategy is used by TAO by default. Researches were also conducted on TAO’s Pluggable
Protocol Factory. The ESIOPs UIOP, SHMIOP, and COIOP were evaluated which improved the
computational latency slightly if the client and server application are executed on the same computer.
However, since the main objective for the new image processing system is to distribute the server and
client over the network, a performance evaluation with non-collocated applications was conducted as
well. The computational latency of TAO over the network is about 61 milliseconds. The results are
reasonable: it takes about 25 milliseconds each to exchange the request and the response between the
client and the server application. Considering an image of 2.5 MB is sent over a Gigabit network
connection, the result is acceptable. There are possibilities to decrease the time needed for exchanging
data between the client and server application, e.g., by compressing the images. The requirements for
the new system also include the support of real-time functionalities. For that reason, a performance
evaluation was additionally conducted on a real-time TAO application to proof that it is possible to
prioritize CORBA applications. The performance evaluation of a real-time TAO application depicts that
on a fully utilized testing computer it performs better than a non-real-time TAO application.
The results of the performance evaluation show that CORBA implementations can compete with
low-level technologies like C++ sockets. Therefore, CORBA is considered a suitable technology for the
adaption of the image processing system.
4.2 Future Work
This master’s thesis focused on evaluating different CORBA implementations and their possible
use for the adaption of an existing system. However, it does not cover the real-time functionalities of
CORBA. Therefore, this part will be included in future work.
In this master’s thesis, only performance evaluations on open-source CORBA implementations
are included. This is because it is easier to conduct a performance evaluation on open-source ORBs
since their access is not restricted as with commercial ones. As a future work, it would be possible to
evaluate commercial ORBs because they offer better support.
Since CORBA, especially TAO proofed to be very promising, the development of the new image
processing system based on TAO is planned. The results of this master’s thesis will contribute to the
decision planning for the new system.
87
References
[1] V. Fay-Wolfe, L. DiPippo, G. Cooper, R. Johnston, P. Kortmann, B. Thuraisingham. Real-Time
CORBA. In IEEE Transactions on Parallel and Distributed Systems, Vol. 11, No. 10, October
2000.
[2] D. Schmidt, F. Kuhns. An Overview of the Real-Time CORBA Specification. In Computer, Vol.
33, No. 6, June 2000.
[3] B. Selic. Turning Clockwise: Using UML in the Real-Time Domain. In Communications of the
ACM, Vol. 42, No. 10, October 1999.
[4] B. Goetz, R. Eckstein, ORACLE. An Introduction to Real-Time Java Technology: Part 1, The
Real-Time Specification for Java (JSR 1).
http://www.oracle.com/technetwork/articles/javase/index-137216.html, last visited on March 12th
2017.
[5] K. Nilsen, ORACLE. Developing Real-Time Software with Java SE APIs: Part 1.
http://www.oracle.com/technetwork/articles/java/nilsen-realtime-pt1-2264405.html, last visited on
March 12th 2017.
[6] K. H. Kim. Object-Oriented Real-Time Distributed Programming and Support Middleware. In
Proceedings Seventh International Conference on Parallel and Distributed Systems, July 2000.
[7] A. Gokhale, K. Balasubramanian, A. S. Krishna, J. Balasubramanian, G. Edwards, G. Deng, E.
Turkay, J. Parsons, D. Schmidt. Model driven middleware: A new paradigm for developing
distributed real-time and embedded systems. In Science of Computer Programming, Vol. 73, No.
1, September 2008.
[8] K. H. Kim. APIs for Real-Time Distributed Object Programming. In Computer, Vol. 33, No. 6,
June 2000.
[9] H. Gomaa. Designing Concurrent, Distributed, and Real-Time Applications with UML. In
Proceedings – International Conference on Software Engineering, Vol. 28, May 2006.
[10] P. Basanta-Val, M. García-Valls. A Distributed Real-Time Java-Centric Architecture for
Industrial Systems. In IEEE Transactions on Industrial Informatics, Vol. 10, No. 1, February 2014.
[11] P. Basanta-Val, J. S. Anderson. Using Real-Time Java in Distributed Systems: Problems and
Solutions. In Distributed, Embedded and Real-time Java Systems, December 2011.
88
[12] J. S. Anderson, E. D. Jensen. Distributed Real-Time Specification for Java. In Proceedings of
the 4th International workshop on Java technologies for real-time and embedded systems. October
2006.
[13] H. Kim, S. Park, J. Kim. TMO-Linux: A Linux-based Real-time Operating System Supporting
Execution of TMOs. In Proceedings of the 5th IEEE International Symposium on Object-Oriented
Real-Time Distributed Computing, April 2002.
[14] D. Vassilopoulos, T. Pilioura, A. Tsalgatidou. Distributed Technologies – CORBA,
Enterprise Java Beans, Web Services – A Comparative Presentation. In Proceedings of the
14th Euromicro International Conference on Parallel, Distributed, and Network-Based
Processings. February 2006.
[15] A. S. Gokhale, D. Schmidth. Evaluating CORBA Latency and Scalability Over High-Speed
ATM Networks. In Proceedings of the 17th International Conference on Distributed Computing
Systems, May 1997.
[16] S. Khan, K. Qureshi, H. Rashid. Performance Comparison of ICE, HORB, CORBA and Dot
Net Remoting Middleware Technologies. In International Journal of Computer Applications, Vol.
3, No. 11, July 2010.
[17] S. Nimmagadda, C. Liyanaarachchi, D. Niehaus, A. Gopinath, A. Kaushal. Performance
Patterns: Automated Scenario-Based ORB Performance Evaluation. In 5th USENIX Conference
on Object-Oriented Technologies and Systems. May 1999.
[18] Department of Distributed and Dependable Systems, Faculty of Mathematics and Physics,
Charles University. CORBA Comparison Project – Final Project Report.
http://d3s.mff.cuni.cz/publications/download/CORBA-report98.pdf, last visited on March 12th
2017.
[19] D. Reitz, R. Dumke. Qualitätsbewertung CORBA-basierter Software-Systeme. In Software-
Messung und -Bewertung, Part of the series Information Engineering und IV-Controlling, 2002.
[20] OMG, The Object Management Group. http://www.omg.org/, last visited 13th March 2017.
[21] M. Henning, S. Vinoski. Advanced CORBA Programming with C++. Addison-Wesley
Professional Computing Series, ISBN 0-201-37927-9, 1999.
[22] A. Gokhale, D. Schmidt. Measuring the Performance of Communication Middleware on High-
Speed Networks. In ACM SIGCOMM Computer Communication Review, Vol. 26, No. 4,
October 1996.
89
[23] D. Schmidt, D. Levine. Developing Standard Real-time CORBA Applications using the TAO
Object Request Broker – A Proposal for a TAO Real-time CORBA Developers Guide.
http://www.cs.wustl.edu/~schmidt/PDF/RT-CORBA-proposal.pdf, last visited 13th March 2017.
[24] Object Management Group. CORBAservices: Common Object Services Specification.
http://www.omg.org/cgi-bin/doc?formal/97-06-18.pdf, last visited 13th March 2017.
[25] TAO Developer’s Guide. OCI TAO Version 2.2a updated for patch 7.
https://store.ociweb.com/, last visited 13th March 2017.
[26] Object Management Group. Common Object Request Broker Architecture (CORBA)
Specification, Version 3.3, Part 1: CORBA Interfaces.
http://www.omg.org/spec/CORBA/3.3/Interfaces/PDF/, last visited 13th March 2017.
[27] IBM. Internationalization, Time Operations, and Related Facilities.
http://doc.omg.org/formal/2000-01-01.pdf, last visited 13th March 2017.
[28] Object Management Group. CORBA Basics.
http://www.omg.org/gettingstarted/corbafaq.htm#HowWork, last visited 13th March 2017.
[29] GNU. Licenses. https://www.gnu.org/licenses/licenses.en.html, last visited 13th March 2017.
[30] D. C. Schmidt. Middleware for Real-Time and Embedded Systems. In Communications of the
ACM, Vol. 45, No. 6, June 2002.
[31] C. O’Ryan, F. Kuhns, D. C. Schmidt, O. Othman, J. Parsons. The Design and Performance of
a Pluggable Protocols Framework for Real-Time Distributed Object Computing Middleware. In
Lecture Notes in Computer Science, Vol. 1795, 2000.
[32] omniORB. http://www.omniorb-support.com, last visited 13th March 2017.
[33] D. Grisby, omniORB. The omniORB version 4.2 Users’ Guide. http://www.omniorb-
support.com/omni42/omniORB.pdf, last visited 13th March 2017.
[34] NetBeans IDE. https://netbeans.org/, last visited 13th March 2017.
[35] Eclipse. https://eclipse.org/downloads/, last visited 13th March 2017.
[36] MICO IS CORBA. Documentation, Version 2.3.13. http://www.mico.org/docu.html, last
visited 13th March 2017.
[37] A. Puder, K. Römer, MICO: An Open Source CORBA implementation.
http://dpunkt.de/mico/, last visited 13th March 2017.
[38] A. D. Selvakumar, R. Pitchiah. Real-time CORBA on MICO-MT – Design, Implementation,
Performance and Application.
90
https://pdfs.semanticscholar.org/d7b2/782461082ddc8ec28e0705a2d6fec2252713.pdf, last visited
13th March 2017.
[39] Micro Focus, VisiBroker. https://www.microfocus.com/products/corba/visibroker, last visited
13th March 2017.
[40] Xubuntu. http://xubuntu.org/, last visited 13th March 2017.
[41] Real-Time Linux Wiki. RT PREEMPT HOWTO.
https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO, last visited 13th March 2017.
[42] Comedi. The Control and Measurement Device Interface handbook for Comedilib 0.10.2.
http://www.comedi.org/doc/index.html, last visited 13th March 2017.
[43] Elektronik Praxis. Echtzeit unter Linux mit dem RT-Preemption-Patch.
http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/implementierung/arti
cles/149175/, last visited 13th March 2017.
[44] HALCON – the Power of Machine Vision. http://www.mvtec.com/products/halcon, last
visited 13th March 2017.
[45] HALCON – the Power of Machine Vision. Quick Guide. http://download.mvtec.com/halcon-
10.0-quick-guide.pdf, last visited 13th March 2017.
[46] Qt. https://www.qt.io/, last visited 13th March 2017.
[47] Object Management Group. OMG IDL: Details.
http://www.omg.org/gettingstarted/omg_idl.htm, last visited 13th March 2017.
[48] P. Tuma, A. Buble. Open CORBA Benchmarking.
http://d3s.mff.cuni.cz/publications/download/TumaBuble-OpenCORBABenchmarking.pdf, last
visited 13th March 2017.
[49] Arduino. Arduino IDE. https://www.arduino.cc/en/main/software, last visited 13th March
2017.
[50] Arduino. attachInterrupt(). https://www.arduino.cc/en/Reference/attachInterrupt, last visited
13th March 2017.
[51] Arduino. Interrupts. http://playground.arduino.cc/Code/Interrupts, last visited 13th March
2017.
[52] GNOME.org. The moserial Project. https://wiki.gnome.org/moserial, last visited 13th March
2017.
[53] RStudio. https://www.rstudio.com, last visited 13th March 2017.
[54] Wireshark. https://www.wireshark.org/, last visited 16th March 2017.
91
[55] The Open Group. The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004
Edition, sched.h. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sched.h.html, last
visited 13th March 2017.
[56] Great Internet Mersenne Prime Search. Prime 95. https://www.mersenne.org/download/, last
visited 13th March 2017.
[57] D. C. Schmidt, N. Wang, S. Vinoski. Object Interconnections – Collocation Optimizations for
CORBA (Colum 18). In SIGS C++ Report magazine, September 1999.
92
List of Figures
Figure 1: Bar Plot for Latency Comparison [15] ................................................................................... 12
Figure 2: Point Diagram for Comparing the Latency [16] .................................................................... 13
Figure 3: Cubit Test for omniORB and TAO [17] ................................................................................ 14
Figure 4: Throughput Test for TAO [17] .............................................................................................. 14
Figure 5: Request from Client to Object [26] ........................................................................................ 19
Figure 6: Interface Categories ............................................................................................................... 20
Figure 7: CORBA Architecture ............................................................................................................. 21
Figure 8: Communication between different ORBs on different computers [28] ................................. 22
Figure 9: Architecture of Real-Time CORBA [2] ................................................................................. 23
Figure 10: Mapping of CORBA Priorities to Native Priorities ............................................................. 24
Figure 11: TAO Architecture ................................................................................................................ 31
Figure 12: Application Scenario ............................................................................................................ 46
Figure 13: CORBA Applications Architecture [26] .............................................................................. 50
Figure 14: Pins and Interrupt Numbers of Arduino Boards [50] ........................................................... 65
Figure 15: TAO Performance Trend ..................................................................................................... 67
Figure 16: omniORB Performance Trend ............................................................................................. 68
Figure 17: MICO Performance Trend ................................................................................................... 68
Figure 18: Performance Evaluation Qt, TAO, omniORB, MICO ......................................................... 70
Figure 19: TAO Network Performance Trend ...................................................................................... 71
Figure 20: Latency Comparison for Primitive Data Types [16] ............................................................ 72
Figure 21: Overhead comparison for primitive data types [16] ............................................................ 73
Figure 22: Performance Evaluation Stresstest RT ................................................................................. 75
Figure 23: Communication on the same ORB [28] ............................................................................... 76
Figure 24: TAO Collocation [57] .......................................................................................................... 77
Figure 25: Operation Call of a Collocated Object [57]. ........................................................................ 78
Figure 26: Performance Evaluation of Collocation Strategies .............................................................. 79
Figure 27: Performance Evaluation of ESIOPs ..................................................................................... 84
93
List of Tables
Table 1: Criteria Evaluation .................................................................................................................. 29
Table 2: IDL Basic and Complex Types ............................................................................................... 52
Table 3: Mapping of Basic IDL Types .................................................................................................. 54
Table 4: Performance Evaluation Qt, TAO, omniORB, MICO ............................................................ 69
Table 5: Difference of Mean to Monolithic System (Δt) ...................................................................... 69
Table 6: TAO Network Performance Evaluation .................................................................................. 71
Table 7: Performance Evaluation of Stresstest RT ................................................................................ 74
Table 8: Performance Evaluation of Collocation Strategies ................................................................. 79
Table 9: Pre-defined Pluggable Protocols ............................................................................................. 80
Table 10: Performance Evaluation of ESIOPs ...................................................................................... 83
94
Lebenslauf
Melanie Donabauer, BSc
12. April 1992
Salzburger Straße 33
4030 Linz
Ausbildung:
5 Jahre an der Höheren Technischen Bundeslehranstalt Leonding,
Abteilung EDV und Organisation von 2006 bis 2011
Matura am 17. Juni 2011 bestanden
Bachelorstudium Informatik an der Johannes Kepler Universität von
2011 bis 2015
Seit 2015 Masterstudium Computer Science an der Johannes Kepler
Universität
Berufliche Erfahrungen: Ferialpraktikum bei der VKB Zweigstelle Traun, Juli 2008
Ferialpraktikum bei der Brauunion Österreich AG, August 2010
Diplomarbeit bei der Brauunion Österreich AG, abgeschlossen Mai
2011
Ferialpraktikum bei voestalpine Stahl GmbH, Forschung &
Entwicklung – TWE, 11. Februar – 1. März 2013, 5. August – 27.
September 2013
Von 1.10.2013 bis 30.06.2014 geringfügig beschäftigt bei voestalpine
Stahl GmbH, Forschung & Entwicklung – TWE
Ferialpraktikum bei voestalpine Stahl GmbH, Forschung &
Entwicklung – TWE, 4. August – 28. September 2014
Von 27.10.2014 bis 30.09.2016 geringfügig beschäftigt bei
voestalpine Stahl GmbH, Forschung & Entwicklung – CTE
95
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Masterarbeit selbstständig und ohne fremde
Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder
sinngemäß entnommenen Stellen als solche kenntlich gemacht habe. Die vorliegende Masterarbeit ist
mit dem elektronisch übermittelten Textdokument identisch.
Ort, Datum
Unterschrift