Interoperable Object Reference

The Interoperable Object Reference, IOR short, describes an object reference to a CORBA object. These are object references for objects in the field of object-orientation that exist in different computers and be used across systems.

Objects and references in general

Object orientation as a method of structuring a software, so objects that are created at run- time of a system and exist in the computer's memory or stored long term in object-oriented databases. In the production of such objects are usually receives a reference (see References ), which identified at any time that you just created object uniquely among all possible occurring objects.

This reference is then used to call methods on the object to be accessed in this object data stored, or to change it. References can be passed just like other variables or values.

Objects and References in Distributed Systems

In distributed systems, in which objects in different computers (or at least in separate areas of memory) are, there must be a mechanism for object references can transport across system boundaries. There should be possible to store, to convert them into a suitable reference to the transmission format ( Stringifizierung ) or for later use.

Interoperable Object Reference

For this purpose, the system limits communication across specified called the Interoperable Object Reference, IOR short of the CORBA standard. The IOR contains all the information to build a communication channel to an object and appropriate calls, as well as in a local system perform.

This includes information such as:

  • Type of communication protocol
  • Information about the location of the object, as in the case of TCP / IP, an IP address and a port
  • Requirements for presenting text and data, such as code pages, Endian, encryption, or compression of the data
  • Information on the identity of the object in the target system

The OMG specifies this information for so-called " TaggedProfile " and " TaggedComponent ", as the following excerpt from the IDL specification shows.

Struct { TaggedProfile       ProfileId day;       sequence profile_data;     };      IOR struct {        string type_id;        sequence profiles;     };     struct { TaggedComponent       ComponentId tag;       sequence component_data;     }; Profiles and data Komponentdaten contain a data structure whose importance by the day ( a number here ) is set. For some tags, the CORBA specification defines the data structure, for example, describes a ProfileId - day 0 an IIOP profiles.

The respective ORB one system gets the job, IORs from other systems ( and other ORBs ) to interpret and transform it into an object reference or references to objects in a textual interpretation to transform ( stringifizierte IOR ).

Manufacturers who create their own ORB implementations according to the CORBA specification, can also use your own tags. However, to avoid incorrect interpretations, they should not overlap with any other assigned tags. Does an ORB is not the meaning of a day, he can not and should not use the information contained in the data structure.

From an IOR can not be concluded that the methods and data elements of the referenced object. The only indication in the IOR is the type of the object ( type_id, even Repository Id) called, which should correspond to the IDL, which describes the interface of the object.

IOR Reference

The CORBA Naming Service, which was as a service also specified by OMG, is a way to store object references under one name. Since the Naming Service also represents a CORBA object whose reference must be known in order to use it, but the problem arises how the IOR to the caller, which is not specified in the CORBA standard. Stringifizierte IORs can, however, save to file or send it by mail, web or file transfer.

Computer memory Object Management Group Object Request Broker
415252
de