Corba | Sue Brandreth's Learning Resources

Common Object Request Broker Architecture (CORBA)
(https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture)

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 has many of the same design goals as object-oriented programming: encapsulation and reuse. CORBA uses an object-oriented model although the systems that use 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 (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:

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 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:

Illustration of the autogeneration of the infrastructure code from an interface defined using the CORBA IDL

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.

Welcome to the OMG’s CORBA Website!
(http://www.corba.org/)

The OMG® is an international not-for-profit software consortium that is setting standards in the area of distributed object computing. We are a vendor-neutral membership-driven organization and have hundreds of members who are working towards developing and refining these standards. Our Board of Directors includes prominent and influential members who act as visionaries who shape the direction of the organization.

What is CORBA?
CORBA® is the acronym for Common Object Request Broker Architecture™, OMG®’s open, vendor-independent architecture and infrastructure that computer applications use to work together over networks.

What is CORBA good for?
CORBA is useful in many situations. CORBA works behind the scenes in the computer rooms of many of the world’s largest websites; ones that you probably use every day.

CORBA Standards
OMG’s best support for server-side scalability comes from the CORBA Component Model. The over 400 attendees at each OMG meeting make it a happening as well as an occasion to advance the OMG specification suite.

CORBA FAQs
(http://www.omg.org/gettingstarted/corbafaq.htm)

CORBA® BASICS
If you want to understand CORBA, this is the place to start!

CORBA Specifications
(http://www.omg.org/spec/CORBA/)

Common Object Request Broker Architecture® (CORBA)®
OMG Formally Released Versions of CORBA®
The current version is found at: http://www.omg.org/spec/CORBA/Current

About CORBA
(http://www.ois.com/Products/about-corba.html)

The Common Object Request Broker Architecture (CORBA) is a standard developed by the Object Management Group (OMG) to provide interoperability among distributed objects. CORBA is the world’s leading middleware solution enabling the exchange of information, independent of hardware platforms, programming languages, and operating systems. CORBA is essentially a design specification for an Object Request Broker (ORB), where an ORB provides the mechanism required for distributed objects to communicate with one another, whether locally or on remote devices, written in different languages, or at different locations on a network.

The CORBA Interface Definition Language, or IDL, allows the development of language and location-independent interfaces to distributed objects. Using CORBA, application components can communicate with one another no matter where they are located, or who has designed them. CORBA provides the location transparency to be able to execute these applications.

CORBA is often described as a “software bus” because it is a software-based communications interface through which objects are located and accessed.

What is CORBA?
What is Real-time CORBA?
CORBA/e
ORBexpress Performance

Object Management Group (OMG)
The OMG is a non-profit consortium created in 1989 to promote the theory and practice of object technology for the development for distributed operating systems. The goal is to provide a common architectural framework for object-oriented applications based on widely available interface specifications. With a membership of over 800 members, representing large and small companies within the computer industry, OMG leads the specification development efforts of CORBA, OMG IDL, IIOP, OMA, UML, MOF, and CWM specifications.

The OMG does not produce software or implementation guidelines, only the specifications to which OMG members respond to in Request For Information (RFI) and Requests for Proposals (RFP). By managing these specifications, the OMG supports the adoption process for the member companies interested in advancing the uses and applications of distributed object-oriented computing.

What is CORBA?
(http://www.ois.com/Products/what-is-corba.html)

The Common Object Request Broker Architecture (CORBA) is a standard developed by the Object Management Group (OMG) to provide interoperability among distributed objects. CORBA is the world’s leading middleware solution enabling the exchange of information, independent of hardware platforms, programming languages, and operating systems. CORBA is essentially a design specification for an Object Request Broker (ORB), where an ORB provides the mechanism required for distributed objects to communicate with one another, whether locally or on remote devices, written in different languages, or at different locations on a network.

The CORBA Interface Definition Language, or IDL, allows the development of language and location-independent interfaces to distributed objects. Using CORBA, application components can communicate with one another no matter where they are located, or who has designed them. CORBA provides the location transparency to be able to execute these applications.

CORBA is often described as a “software bus” because it is a software-based communications interface through which objects are located and accessed. The illustration below identifies the primary components seen within a CORBA implementation.

CORBA Implementation

Data communication from client to server is accomplished through a well-defined object-oriented interface. The Object Request Broker (ORB) determines the location of the target object, sends a request to that object, and returns any response back to the caller. Through this object-oriented technology, developers can take advantage of features such as inheritance, encapsulation, polymorphism, and runtime dynamic binding. These features allow applications to be changed, modified and re-used with minimal changes to the parent interface. The illustration below identifies how a client sends a request to a server through the ORB:

Client Sending Request to Server Through ORB

Interface Definition Language (IDL)
A cornerstone of the CORBA standards is the Interface Definition Language. IDL is the OMG standard for defining language-neutral APIs and provides the platform-independent delineation of the interfaces of distributed objects. The ability of the CORBA environments to provide consistency between clients and servers in heterogeneous environments begins with a standardized definition of the data and operations constituting the client/server interface. This standardization mechanism is the IDL, and is used by CORBA to describe the interfaces of objects.

IDL defines the modules, interfaces and operations for the applications and is not considered a programming language. The various programming languages, such as Ada, C++, or Java, supply the implementation of the interface via standardized IDL mappings.

Application Development Using ORBexpress
The basic steps for CORBA development can be seen in the illustration below. This illustration provides an overview of how the IDL is translated to the corresponding language (in this example, C++), mapped to the source code, compiled, and then linked with the ORB library, resulting in the client and server implementation.

Application Development Using ORBexpress

The basic steps for CORBA development include:

Create the IDL to Define the Application Interfaces
The IDL provides the operating system and programming language independent interfaces to all services and components that are linked to the ORB. The IDL specifies a description of any services a server component exposes to the client. The term “IDL Compiler” is often used, but the IDL is actually translated into a programming language.

Translate the IDL
An IDL translator typically generates two cooperative parts for the client and server implementation, stub code and skeleton code. The stub code generated for the interface classes is associated with a client application and provides the user with a well-defined Application Programming Interface (API). In this example, the IDL is translated into C++.

Compile the Interface Files
Once the IDL is translated into the appropriate language, C++ in this example, these interface files are compiled and prepared for the object implementation.

Complete the Implementation
If the implementation classes are incomplete, the spec and header files and complete bodies and definitions need to be modified before passing through to be compiled. The output is a complete client/server implementation.

Compile the Implementation
Once the implementation class is complete, the client interfaces are ready to be used in the client application and can be immediately incorporated into the client process. This client process is responsible for obtaining an object reference to a specific object, allowing the client to make requests to that object in the form of a method call on its generated API.

Link the Application
Once all the object code from steps three and five have been compiled, the object implementation classes need to be linked to the C++ linker. Once linked to the ORB library, in this example, ORBexpress, two executable operations are created, one for the client and one for the server.

Run the Client and Server
The development process is now complete and the client will now communicate with the server. The server uses the object implementation classes allowing it to communicate with the objects created by the client requests.

In its simplest form, the server must perform the following:

Create the required objects.
Notify the CORBA environment that it is ready to receive client requests.
Process client requests by dispatching the appropriate servant.

CORBA Programming Definitions
Within a CORBA development process, there are a number of unique terms specific to a CORBA implementation. Developers may find our Glossary of Terms helpful in understanding a full CORBA implementation.

Interoperability
The first version of CORBA provided the IDL and standard mappings to just a few languages, and as the CORBA standard has matured, CORBA 2.0 added more language bindings (particularly C++ and Java) as well as General Inter-ORB Protocol (GIOP). When a client calls a CORBA operation, the client ORB sends a GIOP message to the server. The server ORB converts this request into a call on the server object and then returns the results in a GIOP reply. This standard transfer syntax, specified by the Object Management Group, allows the interoperability of ORB-to-ORB interaction and is designed to work over any transport protocol meeting a minimal set of assumptions.

When GIOP is sent over TCP/IP, it is called Internet Inter ORB Protocol (IIOP). IIOP is designed to allow different ORB vendors to interoperate with one another. An example of this interoperability occurs when there is communication between an enterprise designed ORB, and a smaller real-time application, utilizing a real-time ORB.

Overview of CORBA
(http://www.cs.wustl.edu/~schmidt/corba-overview.html)

The Common Object Request Broker Architecture (CORBA) is an emerging open distributed object computing infrastructure being standardized by the Object Management Group (OMG). CORBA automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing and error-handling; parameter marshalling and demarshalling; and operation dispatching. See my CORBA page for additional information on CORBA, including our tutorials and research on high-performance and real-time ORBs.

CORBA Objects
(https://docs.oracle.com/javase/jndi/tutorial/objects/storing/corba.html)

Java RMI & CORBA – A comparison of two competing technologies
(http://www.javacoffeebreak.com/articles/rmi_corba/)

With the introduction of CORBA support to Java (as of version 1.2), developers now face the question of whether to continue to use remote method invocation (RMI), or make a move to CORBA. The choice is made more difficult if your applications are already written in RMI – considerable effort might have to be made to convert to CORBA. Is it worth the move? This article discusses the pros and cons, and evaluates the potential of these two technologies.

YouTube Video – 691 Common Object Request Broker Architecture
(https://www.youtube.com/watch?v=CMDt6dm06gk&list=PLO1mZWqhRqhGEnC6nPrr1NAYISWiH7zCP&index=1)

Published on 20 Feb 2015

What is CORBA (Common Object Request Broker Architecture)?
(http://searchsqlserver.techtarget.com/definition/CORBA)

Common Object Request Broker Architecture (CORBA) is an architecture and specification for creating, distributing, and managing distributed program objects in a network. It allows programs at different locations and developed by different vendors to communicate in a network through an “interface broker.” CORBA was developed by a consortium of vendors through the Object Management Group (OMG), which currently includes over 500 member companies. Both International Organization for Standardization (ISO) and X/Open have sanctioned CORBA as the standard architecture for distributed objects (which are also known as components). CORBA 3 is the latest level.

The essential concept in CORBA is the Object Request Broker (ORB). ORB support in a network of clients and servers on different computers means that a client program (which may itself be an object) can request services from a server program or object without having to understand where the server is in a distributed network or what the interface to the server program looks like. To make requests or return replies between the ORBs, programs use the General Inter-ORB Protocol (GIOP) and, for the Internet, its Internet Inter-ORB Protocol (IIOP). IIOP maps GIOP requests and replies to the Internet’s Transmission Control Protocol (TCP) layer in each computer.

A notable hold-out from CORBA is Microsoft, which has its own distributed object architecture, the Distributed Component Object Model (DCOM). However, CORBA and Microsoft have agreed on a gateway approach so that a client object developed with the Component Object Model will be able to communicate with a CORBA server (and vice versa).

Distributed Computing Environment (DCE), a distributed programming architecture that preceded the trend toward object-oriented programming and CORBA, is currently used by a number of large companies. DCE will perhaps continue to exist along with CORBA and there will be “bridges” between the two.