November 1991, Object Management Group (OMG) which is the organization responsible for

standardizing promoting Common Object Request Broker Architecture (CORBA) to answer to the
need for interoperability among the rapidly proliferating number of hardware and software
products available today. In this essay, we will briefly illustrate CORBA's features and its
architecture. After that, readers will get more familiar with CORBA and understanding the CORBA
architecture.

1. Distributed Systems

Before we discuss CORBA, one important concept we must know about it which is distributed
systems. Actually, Distributed systems have been around, in one form or another, for some time,
although they haven't always been called that and they certainly haven't always had the flexibility
that they do now. To discover where CORBA fits in, let's briefly introduce the history of distributed
systems.

Before distributed systems appeared, there were three different system models. At beginning,
Monolithic Systems and Mainframes are along with come hierarchical database systems and dumb
terminals also known as green screens.

The Apache Thrift API client/server architecture.

The Apache Thrift API client/server architecture.
English: Demonstartion of CORBA interoperability between GNU Classpath + JamVM and Sun
Microsystems. Category:Free screenshots
English: Demonstartion of CORBA interoperability b...
Object Management Group
Object Management Group
Because of it, Software systems written for mainframes were often monolithic. That is the user
interface, business logic, and data access functionality was all contained in one large application.
By reason of this, one more flexible model came into being which Client/Server Architecture is.
With the advent of the PC made possible a dramatic paradigm shift from the monolithic
architecture of mainframe-based applications, many applications simply did not require the
massive power of mainframes. So client/server applications typically distributed the components
of the application so that the database would reside on the server (whether a UNIX box or
mainframe), the user interface would reside on the client, and the business logic would reside in
either, or both, components. However, one problem appeared is client/server was not without
faults of its own, because database access functionality (such as embedded...

The Common Object Request Broker Architecture (CORBA) is a standard defined by

the Object Management Group (OMG) that enables software components written in
multiple computer languages and running on multiple computers to work together, i.e.
it supports multiple platforms. CORBA is a mechanism in software for normalizing the
method-call semantics between application objects that reside either in the same
address space (application) or remote address space (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 will present to the
outside world. CORBA then specifies a mapping from IDL to a specific implementation
language like C++ or Java. Standard mappings exist for Ada, C, C++, 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. The CORBA specification dictates that there shall be an
ORB through which the application interacts with other objects. In practice, the
application simply initializes the ORB, and accesses an internal Object Adapter which
maintains such issues as reference counting, object (and reference) instantiation
policies, object lifetime policies, etc. 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 the CORBA semantics and provide a clean user process for
interfacing with the CORBA infrastructure. Some IDL language mappings are "more
hostile" than others.