The Common Object Requesting 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.
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 release 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, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Ruby, 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 (& 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 processes for interfacing with the CORBA infrastructure.
Some IDL language mappings are “more hostile” than others. For example, due to the very nature of Java, the IDL-Java Mapping is rather straightforward and makes usage of CORBA very simple in a Java application. The C++ mapping is not “trivial” but accounts for all the features of CORBA, e.g. exception handling. The C-mapping is even stranger (since it’s not an Object Oriented language) but it does make sense and handles the RPC semantics just fine. It is like (.NET, COM, of Microsoft) but it is also free and stabiel.
Install transition package for omniORBpy
sudo apt-get install python-omniorb2
This package depends on python-omniorb to handle omniORBpy transition.
Install transition package for omniORBpy
sudo apt-get install python-omniorb2-omg
This package depends on python-omniorb-omg to handle omniORBpy transition.
sudo apt-get install omniidl4
omniidl backend to compile Python stubs from IDL files
omniORB4 is a freely available Common Object Request Broker
Architecture (CORBA) 2.6 compliant object request broker (ORB)
implementation. It is based on the IIOP communications
protocol and should be interoperable with any other
CORBA 2.6 compliant ORB.
This includes the Python backend for omniidl to compile IDL to
Python stubs.
sudo apt-get install omniidl4-python
omniidl backend to compile Python stubs from IDL files
omniORB4 is a freely available Common Object Request Broker
Architecture (CORBA) 2.6 compliant object request broker (ORB)
implementation. It is based on the IIOP communications
protocol and should be interoperable with any other
CORBA 2.6 compliant ORB.
This includes the Python backend for omniidl to compile IDL to
Python stubs.
sudo apt-get install python-pyorbit
A Python language binding for the ORBit2 CORBA implementation
It aims to take advantage of new features found in ORBit2 to make
language bindings more efficient. This includes:
- Use of ORBit2 type libraries to generate stubs
- use of the ORBit_small_invoke_stub() call for operation
invocation, which allows for short circuited invocation on local
objects.
Where it makes sense, this binding tries to stay compatible with the
Python language mapping, which can be found on the OMG web site:
http://www.omg.org/cgi-bin/doc?formal/02-09-07
