Common Object Request Broker Architecture

The Common Object Request Broker Architecture (CORBA, English for: General architecture for a mediator of object - News ) is a specification for an object-oriented middleware whose core is a so-called Object Request Broker, ORB, forms and defines the cross-platform protocols and services. It is developed by the Object Management Group (OMG). CORBA - compliant implementations simplify the creation of distributed applications in heterogeneous environments.

Overview

The CORBA specification is not tied to a particular platform. Rather, the software manufacturer or communities are called to create based on this specification 's Object Request Broker implementations. Most manufacturers offer implementations for multiple programming languages ​​and operating systems. The common specification then allows applications to communicate with each other, which have been created with different programming languages, use different ORBs and can run on different operating systems and hardware environments.

By means of also specified by the OMG Interface Definition Language (IDL), the programmer created a formal specification of the interfaces ( data types and method signatures ), which provides an object for remote or local access. The interface semantics is not fixed. This interface description is then reacted with an IDL compiler into equivalent descriptions of the programming language used. In addition, the source code is generated that matches the used ORB implementation. This code contains stubs and skeletons. You implement the Broker pattern architecture as a pattern to hide the complexity of network communications and to make a method call look like a local call. A stub accepts the same messages as the remote object it represents. Therefore, it can be used by other objects such as a local objects of their programming, while the inter-process communication remains hidden with the remote, represented object in the supplied libraries CORBA implementation. IDL compilers are often supplied by the manufacturer of the ORB.

For example, the developer of a C server application first defines its IDL interfaces, after which he created with the help of a corresponding IDL compiler C skeleton classes. Next, he expanded the Skeletons with the necessary implementation of the logic. So that his job is done. A client developer uses the IDL interfaces of the server developer and generated by its IDL compiler stubs in the source code of its programming language. He can then the instances of this class generated as explained above to use as the "normal" properties.

This approach reduces the workload on the client - server development, since all the details of inter-process communication for the client and server remain hidden. Most CORBA implementations support the programming languages ​​Java and C . However, there are also implementations for many other languages.

It is also possible to use CORBA IDL without. For this, the Dynamic Invocation Interface ( DII) and the Dynamic Skeleton Interface ( DSI) are available.

Communication within a CORBA implementation - ORB - took place in earlier CORBA specifications with a vendor- specific protocol. This also ORBs from different vendors can communicate with each other was the General Inter-ORB Protocol ( GIOP ) defined with CORBA 2.0, which defines the communication for different transport protocols. The most widespread is the use of GIOP over TCP / IP, the Internet Inter-ORB Protocol ( IIOP ).

Related Technologies

Also for the creation of distributed applications that use multiple programming languages, is developed by Microsoft COM / DCOM is. However, one must then remain in the Windows world. If a link between Java and other programming languages ​​are made, it can also be used the JNI. For the inter-process communication within Java RMI itself usually is employed. The overhead of complexity that CORBA brings with it due to its language independence, then omitted. A further possibility Web services respecting you're like CORBA language-and platform-independent.

Performance

Meanwhile, the performance of CORBA on the stand of comparable technologies such as RMI. It depends mainly on the bandwidth and latency of the network.

Compatibility

With the help of Bridges can provide a CORBA application of treatments, the RMI or COM-/DCOM-Schnittstellen be coupled. This is interesting especially for older Windows applications with COM interface.

The object model of CORBA

The object concept of OMG hardly differs from other computer science definitions of the word " object": objects are defined as uniquely identifiable entity. In the object model in addition to the properties of objects and types, interfaces, operations and attributes are qualified in more detail. Types are used to narrow the possible values ​​of data and to designate this limitation. This CORBA distinguishes between two different groups of types: the simple and the constructed types. Among the simple types short, long, float, double, char, boolean, octet, string, enum and any.

The constructed types are struct, sequence and union.

For an object-oriented view of the developer needs a further form of the data, namely, object references. In CORBA object references identify the objects within an ORB domain. The internal structure of such references are not intended CORBA ORB and may vary according to manufacturer and programming vary. But this can be used for communication and the exchange of object references across, the CORBA defined as an exchange format, the IOR ( Interoperable Object Reference = ).

CORBA services

In addition to the CORBA protocol defines some services, or services that have a defined IDL interface. The most important CORBA service is the Naming Service, the server allows objects to be approached by a specified name. The name service then delivers the IOR to a registered object name. The Naming Service is a sort of " phone book " for CORBA objects.

The trading service allows also to find objects at runtime. However, objects are identified here about their properties and not by a name. The result of such a search can be several objects.

The event service enables loosely coupled, event-based n: m communication. The Shipping is done asynchronously. In the push model, the supplier (Seller) sends an event (event ) in the form of any object to the consumer (consumer ), the pull model, the consumer calls an event explicitly (possibly blocking) to. " Event Channels" allow buffering of events in FIFO order. In addition, they allow the simultaneous use of different communication models for the transmission of events. Thus, a consumer about an event " ampoules " that has been " pushed" by a supplier in a channel.

The Life Cycle Service provides operations to copy, move and delete objects. Together with the externalization service is enabled so that the migrating objects.

The Relationship Service allows the modeling of relations between objects, which thereby assume specific roles in the relationship. Three levels are defined: Basic relations, relationship graphs and special relations ( containment relationships ( 1: n), reference relationships ( n: m)). A standards- compliant implementation of the Relationship Service Level 1 should implement Level 1 and 2 or Level 1-3.

In addition, for example, there are the following services: externalization Service, Persistent Object Service, Concurrency Control Service, Transaction Service, Property Services, Licensing Service, Object Collection Service, Query Service, Time Service, Security Service, Notification Service as an extension to the event service.

Classification

CORBA is a relatively abstract concept, which makes intuitive access. However, it allows the high level of abstraction, distributed applications with very little effort to develop. With its many service definitions CORBA was at the time of its development an innovative concept with great potential. Since only a few services were actually implemented, this hope has not been fulfilled. The # of programming languages ​​such as Java, Objective- C or C standard libraries today offer much of what was once defined as a CORBA service, and thus bind the developer to the particular programming language and the underlying manufacturer.

Implementations

• AdORB - CORBA ORB for Mac OS X and iPhone OS
• Borland VisiBroker
• JacORB
• MICO CORBA
• OmniORB
• Orbacus
• TAO