|
}}
The '''Common Object Request Broker Architecture''' ('''CORBA''') is a [[Standardization|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 language]]s, 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 (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 (programming language)|Java]]. Standard mappings exist for [[Ada (programming language)|Ada]], [[C (programming language)|C]], [[C++]], [[C++11]], [[COBOL]], [[Java (programming language)|Java]], [[Lisp (programming language)|Lisp]], [[PL/I]], [[Object Pascal]], [[Python (programming language)|Python]], [[Ruby (programming language)|Ruby]] and [[Smalltalk]]. Non-standard mappings exist for [[C Sharp (programming language)|C#]], [[Erlang (programming language)|Erlang]], [[Perl]], [[Tcl]] and [[Visual Basic]] implemented by [[object request broker]]s (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 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:
[[Image:orb.svg|center|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 [[Servant (CORBA)|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.
== Versions history ==
| 