Also see ORBS, a term easily confused with ORB.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In Common Object Request Broker Architecture (CORBA), an Object Request Broker (ORB) is the programming that acts as a "broker" between a client request for a service from a distributed object or component and the completion of that request. Having ORB support in a network means that a client program can request a service without having to understand where the server is in a distributed network or exactly what the interface to the server program looks like. Components can find out about each other and exchange interface information as they are running.
CORBA's ORB may be thought of as strategic middleware that is more sophisticated conceptually and in its capabilities than earlier middleware, including Remote Procedure Calls (RPCs), message-oriented middleware, database stored procedures, and peer-to-peer services.
An ORB uses the CORBA Interface Repository to find out how to locate and communicate with a requested component. When creating a component, a programmer uses either CORBA's Interface Definition Language (IDL) to declare its public interfaces or the compiler of the programming language translates the language statements into appropriate IDL statements. These statements are stored in the Interface Repository as metadata or definitions of how a component's interface works.
In brokering a client request, an ORB may provide all of these services:
- Life cycle services, which define how to create, copy, move, and delete a component
- Persistence service, which provide the ability to store data on object database, , and plain files
- Naming service, which allows a component to find another component by name and also supports existing naming systems or directories, including
- DCE, , and Sun's NIS (Network Information System).
- Event service, which lets components specify events that they want to be notified of
- Concurrency control service, which allows an ORB to manage locks to data that transactions or threads may compete for
- transaction service, which ensures that when a transaction is completed, changes are committed, or that, if not, database changes are restored to their pre-transaction state
- Relationship service, which creates dynamic associations between components that haven't "met" before and for keeping track of these associations
- Externalization service, which provides a way to get data to and from a component in a "stream"
- Query service, which allows a component to query a database. This service is based on the SQL3 specification and the Object Database Management Group's (ODMG) Object Query Language (OQL).
- Licensing service, which allows the use of a component to be measured for purposes of compensation for use. Charging can be done by session, by node, by instance creation, and by site.
- Properties service, which lets a component contain a self-description that other components can use.
In addition, an ORB also can provide security and time services. Additional services for trading, collections, and change management are also planned. The requests and replies that originate in ORBs are expressed through the Internet Inter-ORB Protocol (IIOP) or other transport layer protocols.