OMG® IDL: Details
|
Or, you can download it from OMG's
website, here
where it's Chapter 3. |
How does OMG IDL enable distribution?
Encapsulation is the principle of object-orientation that
enables seamless distribution. By encapsulating the internal structure
and mechanism of our objects inside a boundary that the client is not
allowed to penetrate, we gain not only flexibility but also a
simplicity of architecture that could not be achieved any other way.
We use OMG IDL to define the interface that sits on the outside of the
boundary, allowing the only communication that the object conducts
with the outside world.
For distribution to work in this architecture, we need to define
interfaces that both client and server object understand and can use
easily, regardless of their platform, operating system, programming
language, network connection, or other characteristics. (Keep in mind
that we will use this same interface definition language for embedded
systems and unreliable wireless links, as well as for clients and
servers connected by robust copper and fiber.) An interface definition
must specify the operation to be performed, and all of the input and
output parameters with their types, allowing client and server to
encode and decode values for their travel over the network. The
language should also enforce the architecture - for CORBA, object
orientation - that we've chosen as the basis for our distributed
system. And finally, since it's always possible for something to go
wrong when we make an invocation, the language should support robust
exception handling.
Top
|
OMG IDL is strongly
typed: Typing is enforced at compile time (if you use an
object-oriented language for your implementation). The any type
provides flexibility. |
Tell me about IDL's type system
IDL Types work at two levels:
First, every CORBA object has a type name, which is the same as the
interface name you assign in its IDL declaration. The
operations that it can perform, and the variables (and their types!)
that it understands, are all part of its type. Every time you define a
new kind of CORBA object as you write OMG IDL (by declaring a new interface),
you create a new CORBA type.
Second (and as we had to mention already), IDL variables are typed
but not in the same way as CORBA objects. You don't create types for
variables; instead you have to choose from the official list of types
allowed by the IDL specification. It's a full list; base types include
three different precisions of integers and floating-point numbers plus
fixed-point; standard and wide characters and strings; boolean;
valuetype (we'll write a separate page about the valuetype soon); and
octet for when you absolutely have to send a binary value that only
your application understands. Constructed types include the structure
("struct"), union, and enum. You can declare either
fixed or variable length structs, arrays, strings, and
wstrings.
There's an any type that can be assume any legal IDL type at
runtime. The CORBA object reference is also an IDL
type - you can (and will!) pass CORBA object references around your
system as parameters to invocations.
If you implement in an object-oriented language (using the language
mappings that we'll talk about next), IDL and the mechanisms of your
language work together to enforce the type system. Attempts to invoke
an operation on an object type that doesn't support it will produce
errors at compile time instead of run time, speeding development and enhancing code
correctness.
Top
|
|
How are these type definitions scoped?
IDL defines scopes that delimit where your type definitions
may be used. If you use namespaces in C++, you're already
familiar with the concept.
There's a global scope, which encompasses your entire compilation
unit. (If you include multiple files in your compilation, the global
scope spans all of them. No scope corresponds to a file.) Next, you
can declare a module delimited by curly braces { };
types declared at module level are valid anywhere within it. interface
defines the next level and gives you another opportunity to declare
types, and each operation does the same. valuetypes, structs,
unions,
and exceptions also define scopes.
You can import a definition from the scope that defines it to any
other scope with the importation operator, :: (double
colon).
Top
|
Interfaces for OMG's standard CORBAservices,
CORBAfacilities,
and Domain
Facilities are all specified in OMG IDL. Under the MDA,
these services and facilities will also be specified in other middleware
platforms. |
What does IDL look like?
IDL interface definitions are elegant and (usually!) easy to write
and understand.
Here's an interface from the programming example in the book CORBA®
3 Fundamentals and Programming:
interface salestax {
float calculate_tax ( in float
taxable_amount );
}
This is the interface to an object that calculates sales tax in a
store's computing system. The object's type is salestax, and it
can perform one operation: calculate_tax. The object takes one
input parameter, taxable_amount, which is a float. The
return value, which does not need a name, is also a float.
This very simple example doesn't show any of IDL's more
sophisticated features and capabilities. Experienced CORBA programmers
use structs, sequences, attributes, valuetypes, and other IDL types
and constructs to create very flexible data structures for their
interfaces. In this brief tutorial, this simple one-line example is about as far as we can go. To learn more about coding IDL,
check this non-OMG resource
page for books and tutorials, and our training
page for courses.
Top
|
|
How does this work in My programming language?
In order to integrate the heterogeneous computing environment that
we've built up over the years, CORBA® needs to work in just about every
programming language. IDL is not a programming language - it's
great for defining interfaces, but it doesn't have the constructs
you'd need to write a program.
To do this, OMG has defined mappings from IDL to just about every
major programming language: C, C++, C++11, Java, Smalltalk, COBOL, Ada, Lisp,
PL/1, Python, Ruby, and IDLscript have standard mappings. Implementations of
mappings to other languages are available.
A mapping assigns a language variable type to each IDL variable
type, and a translation from IDL's operation format to the language's
invocation of a member function or other operation invocation format. Mappings
also specify memory usage
conventions for client and server sides, and conventions that allow CORBA's infrastructure to perform services for
the object implementation: A mapping to an OO language might, for
example, assign names to the base classes for the implementation and
specify how the implementation classes should derive from
IDL-generated classes.
Language mappings are very precise: When you apply an OMG language
mapping to an IDL file, you always get the same language
constructs out. To our distributed programming environment, this
provides portability in addition to predictability.
Top
|
|
What does an IDL Compiler do?
IDL Compilers implement language mappings in software. Every
ORB comes with one or more IDL compilers, one for each language that
it supports. After you've written your IDL interface file, you run it
through an IDL compiler that came with your ORB. Because the
mappings are standard, and compilers implement this standard, every
vendor's IDL compiler will produce language code with the same
mappings, allowing your same client and server code to port from
vendor to vendor without change (as long as you resist vendor
extensions, of course).
After checking your IDL for errors, the compiler will produce at
least two files: one for the client stub; the other for the object
skeleton. For more on what these are and how they work, return to the
main CORBA tutorial FAQ and read on.
Top
|
|
Last updated on
03/18/2017 by Jon |
|
|