This tutorial belongs to a series on parallel and distributed computing. It focuses on using CORBA for implementing distributed objects. It includes a couple of working code samples that illustrate particular features of the typical work flow. It also lists strengths and possible weaknesses that a developer should be aware of before deciding to use CORBA. The sample codes are also available on the software page for direct download.
CORBA is a middleware that supports distributed objects. It is quite complex and possibly more difficult to learn than other communication infrastructures. On the other hand it is extremely powerful and gives access to a lot of functionality including independence of the programming language and the operating system. The bindings to a wide choice of programming languages are standardized as is the format of the communication. The latter feature means that programs written using different CORBA vendors are fully interoperable.
A distinct advantage of CORBA is its level of maturity. CORBA has been standardized by the OMG (Object Management Group). The standard has matured for two decades now (since 1991) and is neither too restrictive (which might limit portability and room for optimization) nor too lax (which endangers interoperability of different products). In fact, it provides a real-world-proven and tested compromise with respect to both flexibility, power and performance.
However, there is also criticism. The main complaint is complexity of the architecture and that the official specification still leaves several implementation details unaddressed. This thread on StackOverflow summarizes different perspectives of developers regarding several practical aspects of CORBA.
It should be pointed out that some of the power CORBA offers targets niche markets. Such features are typically referred to as “vertical” markets. Vertical features are of interest for a specific group of users and/or applications, whereas horizontal features are of interest to all users of a technology. Thus, it is sufficient to only focus on the features that a specific application demands – there is generally no need to know about all of CORBA. This makes the complexity of CORBA less intimidating.
This tutorial is organized as follows: First, we will look at the work flow of designing and implementing a distributed system. Next, we look at a set of four example programs that illustrate particular features of CORBA — the first goes from local to distributed method calls, the second illustrates a more involved interface. We then test the portability and platform independence of CORBA. The last example introduces the Naming service. This article then lists a few advanced features of CORBA. Finally, references and pointers for further reading are given.
In general, debugging and optimization becomes much more complicated when code is run remotely. This makes a good design of the system imperative! Thus, designing the communication pattern is probably the most important decision; any flaws made in the design phase are substantially more costly when they need to be repaired later on!
In general, the work flow looks as follows:
In the following we will see how this is done in practice for a series of example programs.
This section links to four parts: First, we present a simple example of a single method that provides an
echo service. This example is inspired by the Orbit2 echo example. Next, we present the more complicated interface of a protocol service that extends
echo's service to a global enterprise-wide protocol facility. The third case demonstrates how this facility is accessed by clients written in different programming languages and different ORBs. Finally, the fourth case illustrates use of the Naming service, an example of a distributed object that is standardized together with CORBA.
The specific examples given above illustrate a range of uses of CORBA. There are other topics that are useful to have heard about:
Protocolfacility one could have one implementation that writes the information to a log file, another that publishes them on a website and a third one that prints the data on a local printer. A client can decide which implementation to work with. Since the implementation is not dependent on any particular programming language, one could even imagine writing a debugging version in C++ and replace it later by a proper implementation written in Common Lisp.
void. The type can be dynamically assigned and thus be used to communicate dynamic applications. It is not always the best choice – e.g. it may be better to package a list as an array for communication instead of constructing a list using the
anymeans. In any case it is a powerful way to add dynamism.
Finally, all the issues mentioned in the parallel computing tutorial might be a concern for distributed systems, too. As individual parts of the entire program flow may happen concurrently, all issues arising from interdependency are potential pitfalls. This is a concern that matters most at the design level of the object system. It is for this reason that I stress so adamantly and repeatedly that the design stage is the most important step of all since any mistakes at this stage will translate to very costly corrections later on during the implementation, debugging or deploying phase of a project!
We have seen what distributing application logic means, what the work flow of designing a system looks like and then looked at four examples which highlighted specific aspects of distributed programming. What I have intentionally left out is the question of how CORBA works internally and how the initialization logic works in detail. I believe that these parts are not as important as the other aspects and I also point the reader to a couple of excellent introductions on the web that cover these topics in sufficient detail.
Most important are the general design of object distribution and the implementation of the application logic. I believe that anybody who reads this page understands the latter. What often provides a bigger challenge is the former since it necessitates a non-trivial understanding of both the technical limitations, the problem at hand and proper object design. In real-world applications these demands may be conflicting — just remember the example in Part 2 where breaking encapsulation can lead to improved performance. The “art” of designing distributed system lies in understanding that sometimes rules must be broken and the judgment of what rules that should be in a given situation.
Beyond the basic understanding I hope that you have grasped the particular strengths and also challenges of working with CORBA. Granted, it is not the best choice in all situations, but it is my goal to show where it really excels and put you in a position to make an adequate choice for your real-world challenges!
There are a couple of good books available on the net for free and there are also some good tutorials and sample codes out there. However, many of them focus on the part that's least important: the way the CORBA middleware works. I have largely left this part out in this tutorial and merely referred to “boilerplate init” code wherever appropriate. This part looks and feels the same in many circumstances and can easily be adapted in the others.
These resources provide excellent overviews on other aspects of CORBA:
CORBA explained simply is a free online book that is both up-to-date and quite thorough. It does not focus on code examples, though, but rather explains the concepts underlying a CORBA application. A minus is that there are no exercises and thus it is hard to get “hands-on” experience by using this book alone.
Teach Yourself CORBA In 14 Days is a well-written, but slightly dated introduction which goes into a lot of technical details yet is very broad in scope. With this resource alone you are in an excellent position to apprehend many of the technical aspects that you will encounter as a developer. A plus are the questions and assignments at the end of each day, making those two weeks a very good investment, indeed.
The Orbix manual is another useful introduction to CORBA. It is thorough and well-written. Although the manual contains some information that is specific to Orbix, most of it applies to any other implementation, too. After reading it, maybe you will decide using Orbix for your upcoming project?
Imprint / Impressum
© 1997-2013 Dr. Wolfram Schroers. This site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Additional permissions available at http://www.field-theory.org/editorial/index.html.
Wolfram is a leading software engineer focused on Enterprise and B2B apps on iOS. His clients rank from small independent studios to companies in the German DAX index.
He has worked at top Universities on three continents in the past decade and is a popular speaker at conferences. He is currently working in Berlin, Germany, and can be reached at his company website.