On Day 2 you learned about the details of the CORBA architecture and attained an understanding of the various CORBA application components and their purposes. One chief component of the CORBA architecture, as you saw, is the use of the Interface Definition Language (IDL). IDL is used to describe the interfaces between CORBA objects. You also learned that IDL is neutral with respect to implementation language; in other words, IDL interfaces can be implemented in any language for which a language mapping exists, such as Java, C, C++, and a number of others.
Today you'll explore the various constructs of IDL and learn their uses. You'll start with the primitive data types, such as Booleans, floating point types, integer types, and characters and character strings, which you will find similar to data types found in most programming languages. You'll then move on to constructed types--the enumerated type, the structure type, the union type, and the interface type--which are simply types constructed from other types. Finally, you'll learn about advanced types, such as container types (sequences and arrays), exceptions, and others. By the end of the chapter you'll have covered virtually all there is to know about IDL.
Before you begin with IDL data types and other constructs, you'll want to cover a few ground rules of IDL syntax and other aspects of the IDL language. In particular, IDL has rules regarding case sensitivity, definition syntax, comment syntax, and C preprocessor usage.
In IDL, identifiers (such as names of interfaces and operations) are case sensitive. In other words, an interface called myObject cannot be referred to later as myOBJECT. Besides these identifiers being case sensitive, IDL imposes another restriction: The names of identifiers in the same scope (for instance, two interfaces in the same module or two operations in the same interface) cannot differ in case only. For example, in the myObject interface, IDL would not allow an operation named anOperation and another operation named anOPERATION to be defined simultaneously. Obviously, you haven't yet been exposed to modules, interfaces, and operations; stay tuned to this chapter for more details on these constructs.
Note:What the OMG refers to as operations, you might know as methods, member functions, or even messages. Whatever name you know it by, an operation defines a particular behavior of an interface, including the input and output parameters of that particular behavior. Throughout this book, the terms operation and method will be used interchangeably, because they refer to exactly the same concept.
All definitions in IDL are terminated by a semicolon (;), much as they are in C, C++, and Java. Definitions that enclose other definitions (such as modules and interfaces) do so with braces ({}), again like C, C++, and Java. When a closing brace also appears at the end of a definition, it is also followed by a semicolon. An example of this syntax appears in Listing 3.2 in the section, "The Module."
Comments in IDL follow the same conventions as Java and C++. Both C-style and C++-style comments are allowed, as illustrated in Listing 3.1. (Note that the second comment in the listing contains embedded comment characters; these are for description purposes only and are not actually allowed by IDL.)
1: // This is a C++-style comment. Anything following the "//"
2: // characters, to the end of the line, is treated as part of the
3: // comment.
4: /* This is a C-style comment. Anything between the beginning
5: "/*" characters and the trailing "*/" characters is treated
6: as part of the comment. */
IDL assumes the existence of a C preprocessor to process constructs such as macro definitions and conditional compilation. If the IDL you write does not make use of these features, you can do without a C preprocessor, but you should recognize that IDL can make use of C preprocessor features.
Note: The C preprocessor, included with C and C++ compilers and with some operating systems, is a tool that is essential to the use of those languages. (The Java language does not use a preprocessor.) Before a C or C++ compiler compiles code, it runs the preprocessor on that code. The preprocessor, among other things, resolves macros, processes directives such as #ifdef...#endif and #include, and performs substitutions of #defined symbols. For more information on the C preprocessor, consult a C or C++ text, or if you have access to a UNIX system, try man cpp.
The first IDL language construct to examine is the module. The module construct is used to group together IDL definitions that share a common purpose. The use of the module construct is simple: A module declaration specifies the module name and encloses its members in braces, as illustrated in Listing 3.2.
New Term: The grouping together of similar interfaces, constant values, and the like is commonly referred to as partitioning and is a typical step in the system design process (particularly in more complex systems). Partitions are also often referred to as modules (which should be no surprise) or as packages (in fact, the IDL module concept closely resembles the Java package concept--or the other way around, because IDL came first).
1: module Bank {
2: interface Customer {
3: ...
4: };
5: interface Account {
6: ...
7: };
8: ...
9: };
The example in Listing 3.2 defines a module called Bank, which contains two interfaces called Customer and Account (ellipses are used to indicate that the actual definitions are omitted). The examples get ahead of themselves somewhat by using the interface construct here; interfaces are described later in this chapter.
New Term: So, now that you have the ability to group interfaces together, how do you decide which interfaces to group together? This is really a question of system design and would be best answered in a text dedicated to that subject. (There are plenty of excellent books available on the subject of object-oriented analysis and design.) However, an overall guideline is that a good design generally exhibits two attributes: loose coupling and tight cohesion. The first means that components in separate modules are not tightly integrated with each other; an application using components in one module generally need not know about components in another module. (Of course, there is often some overlap between modules for various reasons, such as the need to share data between modules or to facilitate common functionality between modules.) When there is little or no dependency between components, they are said to be loosely coupled.
On the other hand, within a single module it is advantageous for a design to achieve tight cohesion. This means that interfaces within the module are tightly integrated with each other. For example, a module called InternalCombustionEngine might contain interfaces such as CylinderHead, TimingChain, Crankshaft, Piston, and many others. It is difficult to describe the purpose of one of these components without referring to the others; hence, one might say that the components are tightly cohesive. By way of comparison, you would probably find very little in common between the components of InternalCombustionEngine and, for instance, AudioSystem; InternalCombustionEngine components such as OilFilter and SparkPlug are loosely coupled to AudioSystem components such as CompactDiscPlayer and Subwoofer.
Figure 3.1 illustrates the concepts of coupling and cohesion; note that there are many relationships between components within the same module, whereas there are few relationships between components within separate modules. The figure also illustrates the advantage of loose coupling between modules: Imagine if, when you installed a new CD player in your car, you had to change the spark plugs and replace your timing chain! Loose coupling of components reduces the possibility that changes to one component will require changes to another.
Figure 3.1. Coupling and cohesion.
Like most programmin