[Up: Object Request Broker]
[Previous: Invocation] [Next: Evaluation]
CORBA 2.0 also specifies the General Inter-ORB Protocol (GIOP) as part of its ORB Interoperability Architecture. It describes the format for requests, replies, and the representation of data types ``on the wire,'' when transported from one ORB to another as part of a method invocation. It also takes into account several low-level issues, such as the format of floating point values, data alignment and endianness for integral values.
Older versions of CORBA (prior to 2.0) did not address the issue of inter-ORB data transfer, so that ORB vendors had to invent a data format on their own,3.5 making inter-vendor communication impossible.
GIOP is an abstract specification itself, requiring only a reliable (no data loss) bidirectional data stream, so that messages can be passed among the ORBs. The aforementioned Internet Inter-ORB Protocol (IIOP) is a specialization of GIOP in that it implements a concrete profile using host name and port number, and a concrete transport mechanism, TCP/IP.
The Security Service [36] describes, among other security-related issues, an implementation of GIOP over SSL (Secure Socket Layer) to provide secure, encrypted transport.
Using GIOP, true interoperability is achieved regardless of operating system or hardware. Since the data stream is agreed on, any programming language that can read and decipher GIOP data can access or implement CORBA objects. Official language mappings for C, C++, Java, Smalltalk, Ada and COBOL are part of the specification [28]. Efforts are underway to provide mappings for scripting languages such as Perl, Tcl or Python. The list of other programming languages that have been used for CORBA programming is long, including Eiffel, Lisp and Basic. An Intercal mapping is planned [52].
This kind of transparency and heterogeneity is unique and makes CORBA an interesting choice as distribution platform.
[Previous: Invocation] [Next: Evaluation]
[Up: Object Request Broker]