Interoperable Object Reference

from Wikipedia, the free encyclopedia

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

Objects and references in general

The object orientation as a method of structuring software knows objects that are generated during the runtime of a system and exist in the computer's main memory or are also stored long-term in object-oriented databases . When creating such objects, you usually get a reference (see also references ) that uniquely identifies the object that has just been created from among all possible objects that may occur.

This reference is then used to send messages to this object, to access or to change data stored in this object. References can be passed just like other variables or values.

Objects and references in distributed systems

In distributed systems in which objects are located in different computers (or at least in separate areas of the main memory), there must be a mechanism that can transport object references across system boundaries. It should be possible to convert this reference into a format suitable for transmission (stringification) or to save it for later use.

Interoperable Object Reference

For this purpose of cross-system communication, the CORBA standard specifies the Interoperable Object Reference , or IOR for short. The IOR contains all the information needed to set up a possibly cross-process and cross-system communication channel to an object and to exchange messages similar to those within a process.

This includes information such as:

  • Type of communication protocol
  • Information on the location of the object, as in the case of TCP / IP an IP address and a port
  • Specifications for the display of 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 so-called "TaggedProfile" and "TaggedComponent" for this information, as the following extract from the IDL from the specification shows. 

   struct TaggedProfile {
     ProfileId tag;
     sequence <octet> profile_data;
   };
    struct IOR {
      string type_id;
      sequence <TaggedProfile> profiles;
   };
   struct TaggedComponent {
     ComponentId tag;
     sequence <octet> component_data;
   };

Profile data and component data contain a data structure whose meaning is determined by the tag (here a number). For some tags, the CORBA specification defines their data structure, e.g. B. a ProfileId tag 0 describes an IIOP profile.

The respective ORB of a system is given the task of interpreting IORs from other systems (and from other ORBs) and converting them into an object reference or converting object references into a textual interpretation (stringified IOR).

Manufacturers who create their own ORB implementations according to the CORBA specification can also use their own tags. In order to avoid misinterpretations, however, these should not overlap with tags assigned elsewhere. If an ORB does not know the meaning of a tag, it cannot and must not use the information contained in the data structure.

The methods and data elements of the referenced object cannot be inferred from an IOR. The only information in the IOR is the type of object (type_id, also called repository id), which should correspond to the IDL that describes the interface of this object.

IOR reference works

The CORBA Naming Service , which was also specified as a service by the OMG, is a way of storing object references under a name. Since the naming service also represents a CORBA object whose reference must be known in order to use it, the problem arises how the IOR gets to the caller, which is not specified in the CORBA standard. Stringified IORs can, however, be saved in files or sent by email, web or file transfer.

Web links