CORBA is an object-oriented middleware standard, defined by the OMG. It enables software components written in different languages to communicate with each other. Server components implement interfaces defined in IDL and register them with an Object Adapter, and clients can access those services using an ORB (Object Request Broker).
CORBA is a middleware standard that makes server-side objects accessible to remote clients. A server (where the object resides) exports the implementing instance. A client receives a stub that implements the same interface, allowing them to invoke remote methods. CORBA also supports remote exception handling.
CORBA messages use General Inter ORB protocol (GIOP) as binary protocol to transfer data between client and server.
Version 1.0 was released in October 1991, the latest version is 3.3 which was released November 2012. CORBA uses an interface definition language (IDL) to specify the interfaces which objects present to the outer world. CORBA then specifies a mapping from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, C++11, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages.
CORBA is useful because it enables separate pieces of software written in different languages and running on different computers to work with each other like a single application or set of services.
The CORBA specification dictates there shall be an ORB through which an application would interact with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter, which maintains things like reference counting, object (and reference) instantiation policies, and object lifetime policies. The Object Adapter is used to register instances of the generated code classes. Generated code classes are the result of compiling the user IDL code, which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce CORBA semantics and provide a clean user process for interfacing with the CORBA infrastructure.
Some IDL language mappings are more difficult to use than others. For example, due to the nature of Java, the IDL-Java mapping is rather straightforward and makes usage of CORBA very simple in a Java application. This is also true of the IDL to Python mapping. The C++ mapping is notoriously difficult; the mapping requires the programmer to learn complex and confusing datatypes that predate the C++ Standard Template Library (STL). The C++11 mapping uses the C++ Standard Template Library (STL) heavily and is simple to use. Since the C language is not object-oriented, the IDL to C mapping requires a C programmer to manually emulate object-oriented features.
A language mapping requires the developer to define its interfaces and type system using IDL . Typically, a CORBA implementation comes with a tool called an IDL compiler which converts the user's IDL into some language-specific generated code. A traditional compiler then compiles the generated code to create the linkable-object files for the application.
As (unlike XML, for instance) GIOP messages are not user readable, an IDL compiler is responsible for creating all code that writes and reads the data structures during the remote operation.
