While briefly popular in the mid to late 1990s, CORBA's complexity, inconsistency, and high licensing costs have relegated it to being a niche technology.
Implementation details from specific operating systems, programming languages, and hardware platforms are all removed from the responsibility of developers who use CORBA.
Standard mappings exist for Ada, C, C++, C++11, COBOL, Java, Lisp, PL/I, Object Pascal, Python, Ruby, and Smalltalk.
Non-standard mappings exist for C#, Erlang, Perl, Tcl, and Visual Basic implemented by object request brokers (ORBs) written for those languages.
The C++ mapping requires the programmer to learn datatypes that predate the C++ Standard Template Library (STL).
The CORBA specification further addresses data typing, exceptions, network protocols, communication timeouts, etc.
The CORBA specification (and thus this figure) leaves various aspects of distributed system to the application to define including object lifetimes (although reference counting semantics are available to applications), redundancy/fail-over, memory management, dynamic load balancing, and application-oriented models such as the separation between display/data/control semantics (e.g. see Model–view–controller), etc.
In addition to providing users with a language and a platform-neutral remote procedure call (RPC) specification, CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.
In total, this system provides a very powerful means to balance the load, distributing requests between several machines.
The object is exposed for the remote invocations, while the servant contains the methods that are actually handling the requests.
The servant for each object can be chosen either statically (once) or dynamically (for each remote invocation), in both cases allowing the call forwarding to another server.
The branches of this tree can be independently activated/deactivated, have the different code for the servant location or activation and the different request handling policies.
This reference is either acquired through a stringified Uniform Resource Locator (URL), NameService lookup (similar to Domain Name System (DNS)), or passed-in as a method parameter during a call.
CORBA Objects are passed by reference, while data (integers, doubles, structs, enums, etc.)
The combination of Objects-by-reference and data-by-value provides the means to enforce great data typing while compiling clients and servers, yet preserve the flexibility inherent in the CORBA problem-space.
The purpose of these is to provide a human readable and editable way to specify a location where an IOR can be obtained.
An example of corbaloc is shown below: A CORBA product may optionally support the "http:", "ftp:", and "file:" formats.
While CORBA delivered much in the way code was written and software constructed, it has been the subject of criticism.