In computing, Common Object Request Broker Architecture (CORBA) is a standard for software componentry, created and controlled by the Object Management Group (OMG). It defines APIs, communication protocol, and object/service information models to enable heterogeneous applications written in various languages running on various platforms to interoperate. CORBA therefore provides platform and location transparency for sharing well-defined objects across a distributed computing platform.
In a general sense CORBA “wraps” code written in some language into a bundle containing additional information on the capabilities of the code inside, and how to call it. The resulting wrapped objects can then be called from other programs (or CORBA objects) over the network. In this sense, CORBA can be considered as a machine-readable documentation format, similar to a header file but with considerably more information.
CORBA uses an interface definition language (IDL) to specify the interfaces that objects will present to the world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. This mapping precisely describes how the CORBA data types are to be used in both client and server implementations. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, and Python. There are also non-standard mappings for Perl, Visual Basic, and Tcl implemented by ORBs written for those languages.
The CORBA IDL is only one example of an IDL.
This diagram illustrates how the generated code is used within the CORBA infrastructure:
This picture does not reflect all typically used possibilities. Normally the server side has the Portable Object Adapter that redirects calls either to the local servants or (to balance the load) to the other servers. Also, both server and client parts frequently have interceptors that are described below.
In addition to providing users with a language and a platform-neutral remote procedure call specification, CORBA defines commonly needed services such as transactions and security.
The OBV's may have fields that are transferred when the OBV is transferred. These fields can be OBV's themselves, forming lists, trees or arbitrary graphs. The OBV's have a class hierarchy, including multiple inheritance and abstract classes.
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 management. 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.
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.
SSLIOP is IIOP over SSL, providing encryption and authentication.
For Real-time applications, the traditional publish-subscribe model has some limitations. The Real-time applications need more deterministic timing control, reliability control, fault tolerance and thread awareness. Object Management Group (OMG) developed the CORBA and the DDS standards. DDS addresses publish-subscribe data distribution and extends publish-subscribe model for real-time systems. Based on the DDS standard, Real-Time Innovations (RTI), headquartered in the heart of Silicon Valley since 1991, produces NDDS, the Real-Time Publish-Subscribe Network Middleware.
The Network Data Delivery Service (NDDS) is network messaging middleware that allows programmers to set up host-independent communication for distributed real-time applications. It implements the Publish-Subscribe communications model and runs on top of a standard internet UDP/IP protocol stack. NDDS has support for many architectures, Multi-OS, like Windows NT, 2000, XP / Linux / Solaris / VxWorks / Integrity / LynxOS and languages include C / C++ / Java.
Besides NDDS there are multiple other products that emerged from the DDS standard. For example for The ACE ORB there is a TAO-DDS that emerged from the DDS standard.
CorbaLoc means Corba Location 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/editable way to specify a location where an IOR can be obtained.
An example of corbaloc is shown below:
corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root
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).
Common Object Request Broker Architecture | CORBA | Common Object Request Broker Architecture | CORBA | CORBA | CORBA | Common Object Request Broker Architecture | CORBA | CORBA | CORBA | CORBA | CORBA | CORBA
This article is licensed under the GNU Free Documentation License.
It uses material from the
"Common Object Request Broker Architecture".
Home Page • arts • business • computers • games • health • hospitals • home • kids & teens • news • physicians • recreation• reference • regional • science • shopping • society • sports • world