The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) 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.
|Common Object Request Broker Architecture|
|Organization||Object Management Group|
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 (application) or in remote address-spaces (same host, or remote host on a network). Version 1.0 was released in October 1991.
CORBA uses an interface definition language (IDL) 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 (ORBs) 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:
Some IDL 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 requires the programmer to learn datatypes that predate the C++ Standard Template Library (STL). By contrast, the C++11 mapping is easier to use, but requires heavy use of the STL. Since the C language is not object-oriented, the IDL to C mapping requires a C programmer to manually emulate object-oriented features.
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 (POA) that redirects calls either to the local servants or (to balance the load) to the other servers. 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.
|1.0||October 1991||First version, C mapping|
|1.1||February 1992||Interoperability, C++ mapping|
|2.0||August 1996||First major update of the standard, also dubbed CORBA 2|
|2.2||February 1998||Java mapping|
|3.0||July 2002||Second major update of the standard, also dubbed CORBA 3|
CORBA Component Model (CCM)
|3.1.1||August 2011||Adopted as 2012 edition of ISO/IEC 19500|
|3.3||November 2012||Addition of ZIOP|
A servant is the invocation target containing methods for handling the remote method invocations. In the newer CORBA versions, the remote object (on the server side) is split into the object (that is exposed to remote invocations) and servant (to which the former part forwards the method calls). It can be one servant per remote object, or the same servant can support several (possibly all) objects, associated with the given Portable Object Adapter. The servant for each object can be set or found "once and forever" (servant activation) or dynamically chosen each time the method on that object is invoked (servant location). 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 Portable Object Adapter (POA) 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 (once) or dynamically (for each remote invocation), 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.
The following describes some of the most significant ways that CORBA can be used to facilitate communication among distributed objects.
Object references are lightweight objects matching the interface of the real object (remote or local). Method calls on the reference result in subsequent calls to the ORB and blocking on the thread while waiting for a reply, success or failure. The parameters, return data (if any), and exception data are marshaled internally by the ORB according to the local language and OS mapping.
The CORBA Interface Definition Language provides the language- and OS-neutral inter-object communication definition. CORBA Objects are passed by reference, while data (integers, doubles, structs, enums, etc.) are passed by value. The combination of Objects-by-reference and data-by-value provides the means to enforce strong data typing while compiling clients and servers, yet preserve the flexibility inherent in the CORBA problem-space.
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) 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 (EJB)", 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 (but are not limited to) 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 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:
The interceptors can attach the specific information to the messages being sent and IORs being created. This information can be later read by the corresponding interceptor on the remote side. Interceptors can also throw forwarding exceptions, redirecting request to another target.
The GIOP is an abstract protocol by which Object request brokers (ORBs) communicate. Standards associated with the protocol are maintained by the Object Management Group (OMG). The GIOP architecture provides several concrete protocols, including:
Each standard CORBA exception includes a minor code to designate the subcategory of the exception. Minor exception codes are of type unsigned long and consist of a 20-bit “Vendor Minor Codeset ID” (VMCID), which occupies the high order 20 bits, and the minor code proper which occupies the low order 12 bits.
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 (see Section 3.17.1, “Standard Exception Definitions,” on page 3-52 and Section 3.17.2, “Standard Minor Exception Codes,” on page 3-58).
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 firstname.lastname@example.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 (Section 3.17.1, “Standard Exception Definitions,” on page 3-52) and 1 through 0xf are reserved for OMG use.
Corba Location (CorbaLoc) 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 (or, recursively, download another URL that will eventually provide a stringified IOR). Some ORBs do deliver additional formats which are proprietary for that ORB.
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.
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.
.NET Remoting is a Microsoft application programming interface (API) for interprocess communication released in 2002 with the 1.0 version of .NET Framework. It is one in a series of Microsoft technologies that began in 1990 with the first version of Object Linking and Embedding (OLE) for 16-bit Windows. Intermediate steps in the development of these technologies were Component Object Model (COM) released in 1993 and updated in 1995 as COM-95, Distributed Component Object Model (DCOM), released in 1997 (and renamed Active X), and COM+ with its Microsoft Transaction Server (MTS), released in 2000. It is now superseded by Windows Communication Foundation (WCF), which is part of the .NET Framework 3.0.
Like its family members and similar technologies such as Common Object Request Broker Architecture (CORBA) and Java's remote method invocation (RMI), .NET Remoting is complex, yet its essence is straightforward. With the assistance of operating system and network agents, a client process sends a message to a server process and receives a reply.Bonobo (GNOME)
Bonobo is an obsolete component framework for the GNOME free desktop environment. Bonobo is designed to create reusable software components and compound documents. Through its development history it resembles Microsoft's OLE technology and is GNOME's equivalent of KDE's KParts .
Bonobo was developed as a solution to the problems and requirements of the free software community in the development of complex applications. Bonobo is based on the Common Object Request Broker Architecture (CORBA) or its GNOME implementation ORBit. Through Bonobo the functions of one application can be integrated into another: for example, Gnumeric spreadsheet tables can be directly embedded into AbiWord text document by including Gnumeric as Bonobo component.
Available components are:
ggv PostScript viewer
Xpdf PDF viewer
gill SVG viewerCSIv2
In distributed computing, CSIv2 (Common Secure Interoperability Protocol Version 2) is a protocol implementing security features for inter-ORB communication. It intends, in part, to address limitations of SSLIOP.
CSIv2 also facilitates secure EJB-CORBA interoperability.Common Data Representation
Common Data Representation (CDR) is used to represent structured or primitive data types passed as arguments or results during remote invocations on Common Object Request Broker Architecture (CORBA) distributed objects.
It enables clients and servers written in different programming languages to work together. For example, it translates little-endian to big-endian. Assumes prior agreement on type, so no information is given with data representation in messages.DIIOP
Domino Internet Inter-ORB Protocol (DIIOP) is CORBA over IIOP for Lotus Domino.
DIIOP allows external programs to attach to, and manipulate Domino databases. DIIOP is frequently used to allow Java-based and other non CORBA programs to connect to Lotus Domino.Distributed Objects Everywhere
Distributed Objects Everywhere (DOE) was a long-running Sun Microsystems project to build a distributed computing environment based on the CORBA system in the 'back end' and OpenStep as the user interface. First started in 1990 and announced soon thereafter, it remained vaporware for many years before it was finally released as NEO in 1995. It was sold for only a short period before being dropped (along with OpenStep) in 1996. In its place is what is today known as Enterprise JavaBeans.Dynamic Invocation Interface
The Dynamic Invocation Interface (DII) is an API which allows dynamic construction of CORBA object invocations. It is used at compile time when a client does not have knowledge about the object it wants to invoke. With this interface an argument list is marshalled, a function is named, and a request for service is sent to the object server. DII will usually have an asynchronous mode of
The following types of applications would require or benefit from DII: browsers for CORBA services, application browsers, bridges (protocol converters), applications accessing huge numbers of different interfaces, monitoring applications.
DII also provides a deferred synchronous invocation. Deferred synchronous invocations are submitted without having to wait for a response. This is similar to a one-way operation except return values and out parameters are possible, but must be polled for.Interoperable Object Reference
An Interoperable Object Reference (IOR) is a CORBA or RMI-IIOP reference that uniquely identifies an object on a remote CORBA server.
IORs can be transmitted in binary over TCP/IP via the General Inter-ORB Protocol (the encoding may be big-endian or little-endian), or serialized into a string of hexadecimal digits (prefixed by the string IOR:) to facilitate transport by non-CORBA mechanisms such as HTTP, FTP, and e-mail.
The internal structure of an IOR may contain multiple components. Each component is identified by its integer code and has its own binary format. The codes are assigned by the Object Management Group. The typical IOR normally contains the IP address of the remote host, the number of the remote port on that the CORBA server is listening, a string defining the class of the remote object on which the methods will be invoked, and the object key that is used by the server ORB to identify the object.
It is possible to register special objects (IOR interceptors) that can add the needed specific components to the IOR being created by the particular ORB.Java transaction service
The Java Transaction Service (JTS) is a specification for building a transaction manager that maps onto the Object Management Group (OMG) Object Transaction Service (OTS) used in the Common Object Request Broker Architecture (CORBA) architecture. It uses General Inter-ORB Protocol (IIOP) to propagate the transactions between multiple JTS transaction managers.KAoS
KAoS is a policy and domain services framework created by the Florida Institute for Human and Machine Cognition. It uses W3C’s Web Ontology Language (OWL) standard for policy representation and reasoning, and a software guard technology for efficient enforcement of a compiled version of its policies. It has been used in a variety of government-sponsored projects for distributed host and network management and for the coordination of human-agent-robot teams, including DARPA's CoABS Grid, Cougaar, and Common Object Request Broker Architecture (CORBA) models.Michael Rosen (enterprise architect)
Michael (Mike) Rosen (born 1956) is an American enterprise architect, and management consultant, known for his work on Common Object Request Broker Architecture (1998), and Applying service-oriented architecture.ORBit
ORBit is a CORBA 2.4 compliant Object Request Broker (ORB). It features mature C, C++ and Python bindings, and less developed bindings for Perl, Lisp, Pascal, Ruby, and Tcl. Most of the code is distributed under the LGPL license, although the IDL compiler and utilities use the GPL.
ORBit was originally written to serve as middleware for the GNOME project, but has seen use outside of the project.Objective Interface Systems
Objective Interface Systems, Inc. is a computer communications software and hardware company. The company's headquarters are in Herndon, Virginia, USA. OIS develops, manufactures, licenses, and supports software and hardware products that generally fit into one or more of the following markets:
Real-time communications middleware software and hardware
Embedded communications middleware software and hardware
High-performance communications middleware software and hardware
Secure communications software and hardwareA popular OIS product is the ORBexpress CORBA middleware software. ORBexpress is most popular in the real-time and embedded computer markets. OIS supports the software version ORBexpress on more than 2,200 computing platforms (combinations of the versions of CPU families, operating systems, and language compilers). OIS also has FPGA versions of ORBexpress to allow hardware blocks on an FPGA to interoperate with software.OIS engineers invented a form of communications security called the Partitioning Communication System or PCS. The PCS is a technical architecture that protects multiple Information Flows from influencing each other when communicated on a single network wire. The PCS is best implemented on a software separation operating system such as SELinux or a separation kernel.OIS's communications products are most frequently found in the enterprise, telecom/datacom, mil/aero, medical, robotics, process control and transportation industries. Objective Interface is a privately held company and has developed software products since 1989 and hardware products since 2001.
The Company is actively involved with various standards groups including:
Network Centric Operations Industry Consortium
Object Management Group (OMG)
The Open Group
Wireless Innovation ForumOrbix (software)
Orbix is a CORBA ORB (Object Request Broker) – a software product from Micro Focus (originally from Iona Technologies, then Progress Software, eventually acquired by Micro Focus in December 2012) which helps programmers build distributed applications. Orbix is an implementation of the OMG's (Object Management Group) CORBA Specification.RMI-IIOP
RMI-IIOP (read as "RMI over IIOP") denotes the Java Remote Method Invocation (RMI) interface over the Internet Inter-Orb Protocol (IIOP), which delivers Common Object Request Broker Architecture (CORBA) distributed computing capabilities to the Java platform. It was initially based on two specifications: the Java Language Mapping to OMG IDL, and CORBA/IIOP 2.3.1.With features inherited from CORBA, software components that work together can be written in multiple computer languages and run on multiple computers. In other words, it supports multiple platforms and can make remote procedure calls to execute, subroutines on another computer as defined by RMI.SSLIOP
In distributed computing, SSLIOP is an Internet Inter-ORB Protocol (IIOP) over Secure Sockets Layer (SSL), providing confidentiality and authentication.
As of January 2007, SSLIOP is implemented by (at least) TAO, JacORB, OpenORB , and MICO .TAO (software)
The ACE ORB (TAO) is a freely available, open-source, and standards-compliant real-time C++ implementation of CORBA based upon the Adaptive Communication Environment (ACE). It attempts to provide efficient, predictable, and scalable quality of service (QoS) end-to-end. TAO applies the best software practices and patterns to automate the delivery of high-performance and real-time QoS to distributed applications. TAO is for developers of distributed and embedded applications who have stringent performance demands.Visibroker
VisiBroker is an object request broker (ORB) from Borland that fully supports the CORBA standard. VisiBroker for Java is written in Java and can run in any Java environment. VisiBroker for C++ provides ANSI C++ interfaces for maximum source portability.
VisiBroker offers features such as support for the C++ programming language, object naming, the ability to distribute objects across a network, support for persistent objects, dynamic object creation and interoperability with other ORB implementations.XPCOM
Cross Platform Component Object Model (XPCOM) is a cross-platform component model from Mozilla. It is similar to Microsoft Component Object Model (COM) and Common Object Request Broker Architecture (CORBA). It features multiple language bindings and interface description language (IDL) descriptions; thus programmers can plug their custom functions into the framework and connect it with other components.
The most prominent usage of XPCOM is within the Firefox web browser. Many of its internal components interact via XPCOM interfaces. Furthermore, Firefox used to allow add-ons extensive XPCOM access, but this was removed in Firefox 57 and replaced with the less-permissive WebExtensions API. (Three forks of Firefox still support the legacy add-on capability: Pale Moon, Basilisk, Waterfox.)
ISO standards by standard number