Common Object Request Broker Architecture
The Common Object Request Broker Architecture is a standard defined by the Object Management Group designed to facilitate the communication of systems that are deployed on diverse platforms. CORBA enables collaboration between systems on different operating systems, programming languages, and computing hardware. CORBA uses an object-oriented model although the systems that use the CORBA do not have to be object-oriented. CORBA is an example of the distributed object paradigm.
Overview
CORBA enables communication between software written in different languages and running on different computers. Implementation details from specific operating systems, programming languages, and hardware platforms are all removed from the responsibility of developers who use CORBA. CORBA normalizes the method-call semantics between application objects residing either in the same address-space or in remote address-spaces. Version 1.0 was released in October 1991.CORBA uses an interface definition language to specify the interfaces that 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, 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 written for those languages.
The CORBA specification dictates there shall be an ORB through which an application would interact with other objects. This is how it is implemented in practice:
- The application simply initializes the ORB, and accesses an internal Object Adapter, which maintains things like reference counting, object 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.
In order to build a system that uses or implements a CORBA-based distributed object interface, a developer must either obtain or write the IDL code that defines the object-oriented interface to the logic the system will use or implement. Typically, an ORB implementation includes a tool called an IDL compiler that translates the IDL interface into the target language for use in that part of the system. A traditional compiler then compiles the generated code to create the linkable-object files for use in the application. This diagram illustrates how the generated code is used within the CORBA infrastructure:
This figure illustrates the high-level paradigm for remote interprocess communications using CORBA. The CORBA specification further addresses data typing, exceptions, network protocols, communication timeouts, etc. For example: Normally the server side has the Portable Object Adapter that redirects calls either to the local servants or to the other servers. The CORBA specification leaves various aspects of distributed system to the application to define including object lifetimes, redundancy/fail-over, memory management, dynamic load balancing, and application-oriented models such as the separation between display/data/control semantics, etc.
In addition to providing users with a language and a platform-neutral remote procedure call specification, CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.
Versions history
This table presents the history of CORBA standard versions.| Version | Version Date | Highlights |
| 1.0 | October 1991 | First version, C mapping |
| 1.1 | February 1992 | Interoperability, C++ mapping |
| 1.2 | December 1993 | - |
| 2.0 | August 1996 | First major update of the standard, also dubbed CORBA 2 |
| 2.1 | August 1997 | - |
| 2.2 | February 1998 | Java mapping |
| 2.3 | June 1999 | - |
| 2.4 | August 2000 | - |
| 2.5 | September 2001 | - |
| 2.6 | December 2001 | - |
| 3.0 | July 2002 | Second major update of the standard, also dubbed CORBA 3 CORBA Component Model |
| 3.0.1 | November 2002 | - |
| 3.0.2 | December 2002 | - |
| 3.0.3 | March 2004 | - |
| 3.1 | January 2008 | - |
| 3.1.1 | August 2011 | Adopted as 2012 edition of ISO/IEC 19500 |
| 3.2 | November 2011 | - |
| 3.3 | November 2012 | Addition of ZIOP |
Servants
A servant is the invocation target containing methods for handling the remote method invocations. In the newer CORBA versions, the remote object is split into the object ' and servant '. It can be one servant per remote object, or the same servant can support several objects, associated with the given Portable Object Adapter. The servant for each object can be set or found "once and forever" or dynamically chosen each time the method on that object is invoked. Both servant locator and servant activator can forward the calls to another server. In total, this system provides a very powerful means to balance the load, distributing requests between several machines. In the object-oriented languages, both remote object and its servant are objects from the viewpoint of the object-oriented programming.Incarnation is the act of associating a servant with a CORBA object so that it may service requests. Incarnation provides a concrete servant form for the virtual CORBA object. Activation and deactivation refer only to CORBA objects, while the terms incarnation and etherealization refer to servants. However, the lifetimes of objects and servants are independent. You always incarnate a servant before calling activate_object, but the reverse is also possible, create_reference activates an object without incarnating a servant, and servant incarnation is later done on demand with a Servant Manager.
The is the CORBA object responsible for splitting the server side remote invocation handler into the remote object and its servant. 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 or dynamically, in both cases allowing the call forwarding to another server.
On the server side, the POAs form a tree-like structure, where each POA is responsible for one or more objects being served. 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.
Features
The following describes some of the most significant ways that CORBA can be used to facilitate communication among distributed objects.Data By Value
The CORBA Interface Definition Language provides the language- and OS-neutral inter-object communication definition. CORBA Objects are passed by reference, while data are passed by value. 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.Objects By Value (OBV)
Apart from remote objects, the CORBA and RMI-IIOP define the concept of the OBV and Valuetypes. The code inside the methods of Valuetype objects is executed locally by default. If the OBV has been received from the remote side, the needed code must be either a priori known for both sides or dynamically downloaded from the sender. To make this possible, the record, defining OBV, contains the Code Base that is a space-separated list of URLs whence this code should be downloaded. The OBV can also have the remote methods.CORBA Component Model (CCM)
CORBA Component Model is an addition to the family of CORBA definitions. It was introduced with CORBA 3 and it describes a standard application framework for CORBA components. Though not dependent on "language dependent Enterprise Java Beans ", it is a more general form of EJB, providing four component types instead of the two that EJB defines. It provides an abstraction of entities that can provide and accept services through well-defined named interfaces called ports.The CCM has a component container, where software components can be deployed. The container offers a set of services that the components can use. These services include notification, authentication, persistence and transaction processing. These are the most-used services any distributed system requires, and, by moving the implementation of these services from the software components to the component container, the complexity of the components is dramatically reduced.
Portable interceptors
Portable interceptors are the "hooks", used by CORBA and RMI-IIOP to mediate the most important functions of the CORBA system. The CORBA standard defines the following types of interceptors:- IOR interceptors mediate the creation of the new references to the remote objects, presented by the current server.
- Client interceptors usually mediate the remote method calls on the client side. If the object Servant exists on the same server where the method is invoked, they also mediate the local calls.
- Server interceptors mediate the handling of the remote method calls on the server side.
General InterORB Protocol (GIOP)
The GIOP is an abstract protocol by which Object request brokers communicate. Standards associated with the protocol are maintained by the Object Management Group. The GIOP architecture provides several concrete protocols, including:- Internet InterORB Protocol - The Internet Inter-Orb Protocol is an implementation of the GIOP for use over the Internet, and provides a mapping between GIOP messages and the TCP/IP layer.
- SSL InterORB Protocol - SSLIOP is IIOP over SSL, providing encryption and authentication.
- HyperText InterORB Protocol - HTIOP is IIOP over HTTP, providing transparent proxy bypassing.
- Zipped IOP - A zipped version of GIOP that reduces the bandwidth usage.
VMCID (Vendor Minor Codeset ID)
Minor codes for the standard exceptions are prefaced by the VMCID assigned to OMG, defined as the unsigned long constant CORBA::OMGVMCID, which has the VMCID allocated to OMG occupying the high order 20 bits. The minor exception codes associated with the standard exceptions that are found in Table 3-13 on page 3-58 are or-ed with OMGVMCID to get the minor code value that is returned in the ex_body structure.
Within a vendor assigned space, the assignment of values to minor codes is left to the vendor. Vendors may request allocation of VMCIDs by sending email to tagrequest@omg.org. A list of currently assigned VMCIDs can be found on the OMG website at: http://www.omg.org/cgi-bin/doc?vendor-tags
The VMCID 0 and 0xfffff are reserved for experimental use. The VMCID OMGVMCID and 1 through 0xf are reserved for OMG use.
Corba Location (CorbaLoc)
Corba Location refers to a stringified object reference for a CORBA object that looks similar to a URL.All CORBA products must support two OMG-defined URLs: "corbaloc:" and "corbaname:". 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. The semantics of these is that they provide details of how to download a stringified IOR. Some ORBs do deliver additional formats which are proprietary for that ORB.
Benefits
CORBA's benefits include language- and OS-independence, freedom from technology-linked implementations, strong data-typing, high level of tunability, and freedom from the details of distributed data transfers.; Language independence:CORBA was designed to free engineers from limitations of coupling their designs to a particular software language. Currently there are many languages supported by various CORBA providers, the most popular being Java and C++. There are also C++11, C-only, Smalltalk, Perl, Ada, Ruby, and Python implementations, just to mention a few.
; OS-independence: CORBA's design is meant to be OS-independent. CORBA is available in Java, as well as natively for Linux/Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, INTEGRITY, and others.
; Freedom from technologies: One of the main implicit benefits is that CORBA provides a neutral playing field for engineers to be able to normalize the interfaces between various new and legacy systems. When integrating C, C++, Object Pascal, Java, Fortran, Python, and any other language or OS into a single cohesive system design model, CORBA provides the means to level the field and allow disparate teams to develop systems and unit tests that can later be joined together into a whole system. This does not rule out the need for basic system engineering decisions, such as threading, timing, object lifetime, etc. These issues are part of any system regardless of technology. CORBA allows system elements to be normalized into a single cohesive system model.
For example, the design of a multitier architecture is made simple using Java Servlets in the web server and various CORBA servers containing the business logic and wrapping the database accesses. This allows the implementations of the business logic to change, while the interface changes would need to be handled as in any other technology. For example, a database wrapped by a server can have its database schema change for the sake of improved disk usage or performance, without affecting the external interfaces. At the same time, C++ legacy code can talk to C/Fortran legacy code and Java database code, and can provide data to a web interface.
; Data-typing: CORBA provides flexible data typing, for example an "ANY" datatype. CORBA also enforces tightly coupled datatyping, reducing human errors. In a situation where Name-Value pairs are passed around, it is conceivable that a server provides a number where a string was expected. CORBA Interface Definition Language provides the mechanism to ensure that user-code conforms to method-names, return-, parameter-types, and exceptions.
; High tunability: Many implementations and OmniORB ) have options for tuning the threading and connection management features. Not all ORB implementations provide the same features.
; Freedom from data-transfer details: When handling low-level connection and threading, CORBA provides a high level of detail in error conditions. This is defined in the CORBA-defined standard exception set and the implementation-specific extended exception set. Through the exceptions, the application can determine if a call failed for reasons such as "Small problem, so try again", "The server is dead" or "The reference does not make sense." The general rule is: Not receiving an exception means that the method call completed successfully. This is a very powerful design feature.
; Compression: CORBA marshals its data in a binary form and supports compression. IONA, Remedy IT, and Telefónica have worked on an extension to the CORBA standard that delivers compression. This extension is called ZIOP and this is now a formal OMG standard.
Problems and criticism
While CORBA delivered much in the way code was written and software constructed, it has been the subject of criticism.Much of the criticism of CORBA stems from poor implementations of the standard and not deficiencies of the standard itself. Some of the failures of the standard itself were due to the process by which the CORBA specification was created and the compromises inherent in the politics and business of writing a common standard sourced by many competing implementors.
;Initial implementation incompatibilities
;Location transparency
;Design and process deficiencies
;Problems with implementations
;Firewalls