CORBA 2.6.1 Administration Guide

The NonStop CORBA ORB
The NonStop CORBA ORB, although conceptually a single entity, is actually a group of mechanisms. Among these are an SRL (Shared Runtime
Library), databases, and the stubs and skeletons representing CORBA objects. The SRL contains mechanisms, which control all events,
threads, database I/O, and the interaction the ORB requires to act as the object message bus, to assure delivery and proper system interaction.
The stubs and skeletons contain the required code to marshal and demarshal the actual requests and their parameters.
GIOP and IIOP
Inter-ORB communications are accomplished through a standard, the Generalized Inter-ORB Protocol (GIOP). There are several versions of the
protocol, and NonStop CORBA supports GIOP 1.0, 1.1, and 1.2. One variation of GIOP is the Internet Inter-ORB Protocol (IIOP). IIOP uses
GIOP messages over the TCP/IP transport mechanism. The OMG defines a set of data formatting rules, called CDR (Common Data
Representation), which is tailored to the data types supported in the CORBA Interface Definition Language (IDL). Using the CDR data formatting
rules, the specification also defines a set of message types that support all of the ORB semantics. Together, the CDR formatting rules and the
message formats constitute an abstract protocol called GIOP. GIOP messages can be sent over virtually any data transport protocol, such as
TCP/IP, the TS/MP Pathsend interface, the NonStop server file system, and many others. To ensure out-of-the-box interoperability between
ORB products, the IIOP specification requires that ORBs send GIOP messages over TCP/IP connections because TCP/IP is the standard
connection-oriented transport protocol for the Internet. To put it very simply, GIOP + TCP/IP = IIOP.
Objects publish their identities and locations in the form of object references. CORBA specifications dictate a common format for object
references exchanged over IIOP, called the IOR (Interoperable Object Reference) format. An IOR contains one or more profiles. Each profile
describes how a client object can contact and send requests to the object using a particular protocol. For interoperability between ORBs
provided by different vendors, an IOR should contain an IIOP profile to ensure that wherever that reference goes, any CORBA ORB can locate
the object and send requests to it. The IIOP profile contains the Internet address of the object’s server and a key value used by the server to find
the specific object described by the reference.
Object references can be converted into character strings, which can be published arbitrarily, like URLs, in e-mail messages, files, databases,
directories, and so on. Any CORBA application can convert the string into an IOR and use it to locate and invoke the object. Alternatively, the
IOR can be obtained from the Naming Service.
When a client program built with one ORB vendor’s product needs to talk to an object in a server built with another ORB vendor’s product, the
client program opens a TCP/IP connection to the server and sends one or more IIOP requests to the server. The ORB component linked into
the server locates or activates the object specified in the request and invokes the appropriate method on the object. The fact that the object is
not built with the same ORB product is invisible to the client.
CORBA/IIOP is platform-independent. CORBA ORBs interoperate without regard to vendor origin, making CORBA/IIOP the truly ideal solution
for the Internet.
NonStop CORBA 2.6.1 can use three transport protocols when communicating between objects. All three use GIOP and each can be
represented as a profile within an IOR. These three protocols are:
IIOP, the standard messaging protocol utilizing TCP/IP, used for all remote messages to platforms other than NonStop server platforms.
GIOP over TS/MP inter-ORB protocol implementation. This protocol is used when accessing objects whose server is controlled by
TS/MP.