Common Object Request Broker Architecture

from Wikipedia, the free encyclopedia
QS IT
 This article was due to content flaws on the quality assurance side of the computer science editorial added. This is done in order to bring the quality of the articles from the subject area of ​​computer science to an acceptable level. Help to eliminate the shortcomings in this article and take part in the discussion !  ( + )


Reason: Is everything still up to date? For example, the section "Performance" could have been changed. - Pumuckl456 ( discussion ) 08:42, Oct. 20, 2019 (CEST)

The Common Object Request Broker Architecture ( CORBA , English for general architecture for brokers of object messages ) is a specification for an object-oriented middleware whose core is an object request broker , the ORB, and which defines cross-platform protocols and services . It is being 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 specific platform. Rather, the software manufacturers or communities are called upon to create their own Object Request Broker implementations based on this specification. Most manufacturers offer implementations for several programming languages and also operating systems. The common specification then enables communication between applications that have been created with different programming languages, use different ORBs and can run on different operating systems and hardware environments.

Using the Interface Definition Language (IDL) also specified by the OMG , the programmer creates a formal specification of the interfaces (data types and method signatures) that an object makes available for remote or local access. The interface semantics are not specified. This interface description is then converted into equivalent descriptions of the programming language used with an IDL compiler. In addition, source code is generated that matches the ORB implementation used. This source code contains stubs and skeletons . They implement the broker pattern as an architectural pattern to hide the complexity of network communication and make a method call appear like a local call. A stub accepts the same messages as the remote object it represents. It can therefore be used by other objects like a local object in their programming language, while the interprocess communication with the remote, represented object remains hidden in the supplied libraries of the CORBA implementation. IDL compilers are often supplied by the manufacturer of the respective ORB.

So defined e.g. For example, the developer of a C ++ server application first creates his IDL interfaces, then he creates C ++ skeleton classes with the help of a corresponding IDL compiler. Next, he extends the skeletons with the necessary implementation of the logic. With that his job is done. A client developer uses the IDL interfaces of the server developer and uses his IDL compiler to generate stubs in the source code of his programming language. He can then use the instances of these generated classes as "normal" objects, as explained above.

This procedure reduces the workload in the client-server development, since all details of the interprocess communication for client and server remain hidden. Most CORBA implementations support the programming languages Java and C ++ . However, there are also implementations for many other languages.

There is also the option of using CORBA without IDL. The Dynamic Invocation Interface (DII) and the Dynamic Skeleton Interface (DSI) are available for this.

The communication within a CORBA implementation - ORB - took place in earlier CORBA specifications using a manufacturer-specific protocol. So that ORBs from different manufacturers can communicate with each other, CORBA 2.0 defines the General Inter-ORB Protocol (GIOP) , which defines the communication for various transport protocols. The most widespread use of the GIOP is via TCP / IP , the Internet Inter-ORB Protocol (IIOP).

Related technologies

COM / DCOM developed by Microsoft is also suitable for creating distributed applications that use several programming languages . But then you have to stay in the Windows world. If a link is to be established between Java and another programming language, the JNI can also be used.

performance

In the meantime, the performance of CORBA is at the level of comparable technologies such as RMI . It depends primarily on the bandwidth and the latency of the network.

compatibility

With the help of bridges , a CORBA application can be linked to applications that provide RMI or COM / DCOM interfaces. This is interesting , among other things, in interaction with Windows applications with a COM interface.

The CORBA object model

The object concept of the Object Management Group (OMG) hardly differs from other computer science definitions of the word "object": Objects are defined as a clearly identifiable entity. In addition to the properties of objects, types, interfaces, operations and attributes are also more precisely qualified in the object model. Types are used to limit the possible values ​​of data and to name this limitation. CORBA distinguishes between two different type groups: the simple and the constructed types. Simple types include short , long , float , double , char , boolean , octet , string , enum, and any .

The constructed types are struct , sequence and union .

For an object-oriented view, the developer needs another form of data, namely object references. In CORBA, object references identify the objects within an ORB domain. CORBA does not determine the internal structure of such references and it can vary depending on the ORB manufacturer and programming language. But that can be used for communication and exchange of object references across, CORBA defined as an exchange format the IOR (= I nteroperable O bject R eference).

CORBA services

In addition to the protocol, CORBA defines some services that have a defined IDL interface. The most important CORBA service is the Naming Service , which enables server objects to be addressed using a specified name. The name service then delivers the IOR for a registered object name. The naming service is a kind of "phone book" for CORBA objects.

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

The Event Service enables loosely coupled, event-based n: m communication. Sending is asynchronous. With the push model , the supplier (provider) sends an event in the form of any object to the consumer (consumer); with the pull model , the consumer explicitly requests an event (possibly blocking). Event channels allow the buffering of events in FIFO order. In addition, they enable the simultaneous use of different communication models for the transmission of events. For example, a consumer can “pull” an event that has been “pushed” into a channel by a supplier.

The Life Cycle Service provides operations for copying, moving and deleting objects. Together with the externalization service , this enables objects to be migrated.

The relationship service enables the modeling of relationships between objects, whereby these objects take on certain roles in the relationship. Three levels are defined: Basic relationships, relationship graphs and special relationships (inclusion relationships (1: n), reference relationships (n: m)). A standards-compliant implementation of the relationship service should implement level 1, level 1 and 2 or level 1–3.

The following services also exist, for example: Externalization Service , Persistent Object Service , Concurrency Control Service , Transaction Service , Property Service , 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 that makes intuitive access difficult. However, the high level of abstraction enables distributed applications to be developed with very little effort. With its many service definitions, CORBA was an innovative concept with great potential at the time of its development. Since only a few services were actually implemented, this hope has not been fulfilled. The libraries supplied by programming languages ​​such as Java , Objective-C or C # now offer many things that were once defined as CORBA services, and thus bind the developer to the respective programming language and the manufacturers behind it.

Implementations

  • AdORB - CORBA ORB for Mac OS X and iPhone OS (discontinued, last release V1.6 from January 30, 2010)
  • VisiBroker from Micro Focus International, originally Borland. (Discontinued, last release V8.5 from January 31, 2012)
  • JacORB (Last Release 3.9 from August 31, 2017)
  • MICO CORBA (discontinued, last release 2.3.13 from September 4, 2008)
  • omniORB (last release 4.2.3 from December 10, 2018)
  • Orbacus (last release 4.3.5 from October 7, 2016)
  • TAO (last release 2.5.6 from July 30, 2019)

See also

Literature and Sources

  • Thomas J. Mowbray, William A. Ruh: Inside Corba . Addison-Wesley Longman, Amsterdam
    Distributed Object Standards and Applications.

Web links

Individual evidence

  1. ↑ AdORB - CORBA ORB for Mac OS X date = 2010-01-30. Retrieved October 21, 2019 .
  2. ↑ VisiBroker. January 31, 2012, accessed October 21, 2019 .
  3. ↑ JacORB date = 2017-08-31. Retrieved October 21, 2019 .
  4. ↑ MICO CORBA. December 15, 2008, accessed October 21, 2019 .
  5. ↑ omniORB. December 10, 2018, accessed October 21, 2019 .
  6. ↑ Orbacus. October 7, 2016, accessed October 21, 2019 .
  7. ^ Johnny Willemsen: [tao-announce] ACE 6.5.6 and TAO 2.5.6 available for download. July 30, 2019, accessed October 21, 2019 .