Knowledge about CORBA: IOR, GIOP, and IIOP

Level: elementary

Dave Bartlett (mailto: dbartlett@pobox.com? Subject = ior, GIOP, and IIOP), Consultant, writer, and lecturer

August 01, 2000

In July, we created a simple example-simplecalc. This example is not worth mentioning; it is a single methodadd(). Two IDL long variables are accepted and a long variable is returned. One difficulty in teaching and learning about CORBA is that it is known to be a distributed client and server, and it has become very complicated from the very beginning. You must deal with the network immediately. So let's talk about networks now.

Network

If you dig deeper into the topic, you will find that many of them are worth exploring, but they are very simple. Our simple calculator server is designed to be called remotely, and CORBA specifically ensures that we do not have to worry about the differences between the client and server environments. Client remote calls to the server are generated based on the Remote Procedure Call (RPC) protocol, which exists since 1980s. RPC is the result of years of tests on various communication models-a reliable and real technology that has been tested in the product environment. The current CORBA model is based on this model.

Figure 1. Network

Back to Top

Ior)

Let's track method calls. The client must first obtain the instance of the calculator. It achieves this goal by using the calculatorhelper. Java narrow () method.iorIt is a string representation of the IOR that can be referenced by an interoperable object.calcref.ior. This file is written by the server so that the client can locate and connect to it. To orbstring_to_object()Only obtainiorString and convert it to object reference. The following is the code in the client,SimpleCalcClient.java:

calculator calc = calculatorHelper.narrow(orb.string_to_object(ior)); System.out.println("Calling into the server"); System.out.println( calc.add(2,3) );

What is ior? Ior is a data structure that provides information about types, protocol support, and available orb services. Orb creates, uses, and maintains the IOR. Many ORB vendors provide a utility to look inside the IOR. Orbacus (see references) of OOC (object oriented concepts, Inc.) comes with iordump.exe. If you use VisiBroker, it provides printior.exe. You can also find a utility on the Xerox PARC site (see references. Because orbacus is being used, I will run iordump on the IOR created in the simplecalc example. The following output is displayed:

C:\_work\corbasem\_sources\calcsimpl>iordump -f calcref.ior IOR #1: byteorder: big endian type_id: IDL:corbasem/gen/calcsimpl/calculator:1.0 IIOP profile #1: iiop_version: 1.2host: 192.168.0.10 port: 4545 object_key: (36) 171 172 171 49 57 54 49 48 "1/2 1/4 1/2 9610" 48 53 56 49 54 0 95 82 "05816._R" 111 111 116 80 79 65 0 0 "ootPOA.." 202 254 186 190 57 71 200 248 ".?.9G.." 0 0 0 0 "...." Native char codeset: "ISO 8859-1:1987; Latin Alphabet No. 1" Char conversion codesets: "X/Open UTF-8; UCS Transformation Format 8 (UTF-8)" "ISO 646:1991 IRV (International Reference Version)" Native wchar codeset: "ISO/IEC 10646-1:1993; UTF-16, UCS Transformation Format 16-bit form" Wchar conversion codesets: "ISO/IEC 10646-1:1993; UCS-2, Level 1" "ISO 8859-1:1987; Latin Alphabet No. 1" "X/Open UTF-8; UCS Transformation Format 8 (UTF-8)" "ISO 646:1991 IRV (International Reference Version)"

Ior is embedded with type_id, IIOP version, host address, port number, and object key. The type_id string is of the interface type.Resource library IDFormat. Basically, the resource library ID is the unique identifier of the interface. This identifier can be in the dce uuid format (COM programmers are familiar with it) or the local format you specified. The IIOP version will help the IOR reader (usually orb) to correctly understand the IOR format, because OMG always improves the specifications and the reading methods of each version are slightly different from those of previous versions ;-). The host address and port number expose us to orb that communicates with the expected object. Object keys and many other materials are built based on the OMG standard of service-specific information. This is service-specific data that helps OTB support servers. For example, these dedicated ior components can encode orb types and versions, or help support orb Implementation of OMG security services. Most of the above information specifies the character code set conversion, so that the client and server can understand each other.

If you run the IOR statement using the Xerox PARC ior syntax analyzer, the following output is displayed:

IIOP_ParseCDR: byte order BigEndian, repository id, 1 profile _IIOP_ParseCDR: profile 1 is 124 bytes, tag 0 (INTERNET), BigEndian byte order (iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.2, hostname=192.168.165.142, port=4545, object_key=<...1961005816._RootPOA......9G......> (iiop.c:parse_IIOP_Profile): encoded object key is < (iiop.c:parse_IIOP_Profile):?non-native cinfo is object key is <#AB#AC#AB196100 5816#00_RootPOA #00#00#CA#FE#BA #BE9G#C8#F8#00# 00#00#00>; no trustworthy most-specific-type info; unrecognized ORB; reachable with IIOP 1.2 at host "192.168.165.142", port 4545

The most important part of IOR is the part that helps the client connect to the server. You can see these sections in the output of the Xerox PARC ior reader (see references. However, many other information is proprietary to orbacus, and other ior readers cannot explain it. These private parts appear as a sequence of data appended to the IOR, and only the orb that builds the IOR understands the data.

Back to Top

Stubs

Now we know what features ior brings. The purpose of IOR is to enable the client to connect to the server so that it can call methods. The client must use the add method to convert the IOR to the actual object that can be called. This is done by using two java files generated from the IDL compiler. The client first uses the calculatorhelper object to narrow down the scope of the IOR_calculatorStubProxy object.

The following is the jidl compiler generated by orbacus.narrow()Method:

public static calculator narrow(org.omg.CORBA.Object _ob_v) { if(_ob_v != null) { try { return (calculator)_ob_v; } catch(ClassCastException ex) { } if(_ob_v._is_a(id())) { org.omg.CORBA.portable.ObjectImpl _ob_impl; _calculatorStub _ob_stub = new _calculatorStub(); _ob_impl = (org.omg.CORBA.portable.ObjectImpl)_ob_v; _ob_stub._set_delegate(_ob_impl._get_delegate()); return _ob_stub; } throw new org.omg.CORBA.BAD_PARAM(); } return null; }

As you can see, its main task is to create a new_calculatorStubObject._calculatorStubActs as a proxy for the actual calculator object residing on the server. If you do not know the proxy mode, I will be happy to introduce you to the "four-person group"Design PatternsA book (see references ). In fact, the proxy mode is nothing more than creating an object that represents or acts as a substitute for another actual object. The other object will eventually call or execute the service. Proxy mode is an important and common mode. It is used in all distributed designs. I bet you must have used this mode, but never called your design a proxy mode.

Once created_calculatorStubIt represents the calculator interface of the client. The add method is implemented on the server, and the server runs in the computer space defined in the IOR address. So far,add()Method. Note the following two points:_calculatorStubTo call the add method. Second, please note that the client will be interrupted until the call is returned, just like other synchronous method calls. This is a request response protocol that imitates a single-process application. Programming client, and then using the request response protocol to execute the client is just as common as creating a common programming development environment using libraries and APIs. This does not mean that you cannot use Asynchronous calls; of course, you can generate those types of calls. I will discuss those topics in future columns.

Back to Top

Packaging: GIOP And CDR

So far, in the architecture, we have successfully spoofed the client to believe that the service is with it. But this is true. In the next few steps, we must cast the data and method call into a form that allows the call to continue on the network, you can also use this call on the other end. This is not unrelated, and it has been around for years. You may have seen the OSI model multiple times. In Figure 2, you will see the OSI model, next to the model used by OMG.

Figure 2. OSI structure vs. GIOP protocol stack

When the client calls an interface operation, it must send the operation data (in and inout parameters) to the server. At this time, the difficulty is to convert the data into a public format, so that the server will not misunderstand or incorrectly align the data when extracting operation data. Because servers can be any number of different platforms, we should predict the architecture difference between the client and the server. By strictly defining how to convert or package data into a public format. Then, the data is re-formed or unwrapped at the other end of the connection. This is done by expressing data in the most basic structure. The most basic structure is the byte stream, that is, the eight-bit metastream.

The CORBA specification defines an eight-bit metastream as an abstract representation, which usually corresponds to the memory buffer to be sent to another process or another machine through the IPC Mechanism or network transmission ". The eight-bit IDL Meta is accurately mapped to Java bytes. They are all 8-bit values, which are not packaged by the client or server. The fundamental purpose of converting these parameters into an octal sequence is to generate a basic structure for information exchange.

Now, we should peat_calculatorStubThe internal information of the generated code. Remember that this is not compiled by me -- it is generated by orbacus's IDL-to-Java compiler jidl.

// // IDL:corbasem/gen/calcsimpl/calculator/add:1.0 // public int add(int _ob_a0, int _ob_a1) { System.out.println("Inside _calculatorStub.add()"); while(true) { if(!this._is_local()) { org.omg.CORBA.portable.OutputStream out = null; org.omg.CORBA.portable.InputStream in = null; try { out = _request("add", true); out.write_long(_ob_a0); out.write_long(_ob_a1); in = _invoke(out); int _ob_r = in.read_long(); return _ob_r; } catch(org.omg.CORBA.portable.RemarshalException _ob_ex) { continue; } catch(org.omg.CORBA.portable.ApplicationException _ob_aex) { final String _ob_id = _ob_aex.getId(); in = _ob_aex.getInputStream(); throw new org.omg.CORBA.UNKNOWN("Unexpected User Exception: " + _ob_id); } finally { _releaseReply(in); } } else { org.omg.CORBA.portable.ServantObject _ob_so = _servant_preinvoke ("add", _ob_opsClass); if(_ob_so == null) continue; calculatorOperations _ob_self = (calculatorOperations)_ob_so.servant; try { return _ob_self.add(_ob_a0, _ob_a1); } finally { _servant_postinvoke(_ob_so); } } } }

Note that_request(),write_long()Call, and_invoke()And subsequentread_long(). Pair_request()The name of the method to be called and the Boolean value to be returned. It returnsorg.omg.CORBA.portable.OutputStreamObject. This is necessary for portability, Because Java is often downloaded and depends on the public libraries on the machines on which it runs. This is true for ORB and true for Io. Therefore, the CORBA specification defines a wider set of portable types for the Java language than other languages.

General orb inter-Protocol (GIOP)
The general orb inter-Protocol (GIOP) is used to define the structure and format of messages transmitted in a messy world consisting of different computers and their architectures. If the structure and format of GIOP are used and they are applied to TCP/IP, the IIOP is obtained. GIOP has two versions: 1.0 and 1.1. This means that our messages may have different formats according to the corresponding GIOP version.

So far, we must take a look at GIOP to understand the operations that the request will undergo when it becomes a correctly formatted CORBA Request. Although we will take a closer look at the request, the response is only the requested image. If you know how requests work, you can understand the response.

The GIOP request message is divided into three parts: GIOP message header, GIOP request header, and request body. The GIOP message header indicates a GIOP message. It contains the GIOP version, message type, and Message Size. Then, based on whether you use 1.0, 1.1, or 1.2, it contains the byte order (GIOP 1.0) or a one-bit flag field, this field includes the byte order and some reserved bits. GIOP 1.1 adds support for message storage fragments and GIOP 1.2 supports bidirectional communication. The updated versions are backward compatible.

Public Data Representation (CDR)
The Public Data Representation (CDR) is a formal ing of the data types used in the CORBA call. When the client generates a request, it does not have to know where the request is to be sent, or which server will respond to the request. CORBA (as the specification) and GIOP (as part of the specification, defining the message structure and transmission) are designed to allow one interface to be implemented by one of multiple different servers to respond to requests. The specification must define how to package the data in the operation, so that all possible servers can extract parameters and call remote operations, and data conversion does not produce ambiguity. A typical example of this conversion problem is pointer. What does the pointer in the client mean for a server that runs another process on another machine? Meaningless. Or, how can variables be sent between machines using different addressing schemes (big-tail and small-tail? These data types must be converted into streams that the server can understand and use. Obviously, the CORBA specification is very detailed in terms of public data representation. This is a level of detail that we don't need to get involved in, but if you want to learn more, read the specifications or co-authored by ruh, Herron, and klinkeronIIOP completeA book (see references ).

Once all the data is encapsulated, the information in ior is used to create a connection. You can differentiate the IOR structure. TCP is usually required as the transmission mechanism. However, you can also use other transmissions (for more information, see the CORBA specifications ). The orb daemon is responsible for finding the object implementation specified by the IOR and establishing a connection between the client and the server. Once a connection is established, GIOP defines a group of messages used by clients for requests or responses by the server. The client will send the message type request, locaterequest, cancelrequest, fragment, and messageerror. The server can send message types such as reply, locatereply, closeconnection, fragment, and messageerror.

If we pull the GIOP message, it looks like:

0x47 0x49 0x4f 0x50 -> GIOP, the key 0x01 0x00 -> GIOP_version 0x00 -> Byte order (big endian) 0x00 -> Message type (Request message) 0x00 0x00 0x00 0x2c -> Message size (44) 0x00 0x00 0x00 0x00 -> Service context 0x00 0x00 0x00 0x01 -> Request ID 0x01 -> Response expected 0x00 0x00 0x00 0x24 -> Object key length in octets (36) 0xab 0xac 0xab 0x31 0x39 0x36 0x31 0x30 0x30 0x35 0x38 0x31 0x36 0x00 0x5f 0x52 0x6f 0x6f 0x74 0x50 0x4f 0x41 0x00 0x00 0xca 0xfe 0xba 0xbe 0x39 0x47 0xc8 0xf8 0x00 0x00 0x00 0x00 -> Object key defined by vendor 0x00 0x00 0x00 0x04 -> Operation name length (4 octets long) 0x61 0x64 0x64 0x00 -> Value of operation name ("add") 0x20 -> Padding bytes to align next value

You should understand the general situation. This type of message stream is highly structured. It must also be a message that can be converted to an implemented message for the client to create a server-no matter how the implementation runs or where it runs. The server must also perform the same operation for the returned values and parameters used in response to the client. This message format is very important in OMG achievements because it can achieve portability and interoperability goals. This portability will give you the freedom we mentioned in the first column. You do not need to care about hardware, databases, or programming languages. You only need to care about your information.

Back to Top

IIOP

We have not completely ended. GIOP is the core part of the call to the CORBA method. GIOP is not based on any special network protocol, such as IPX or TCP/IP. To ensure interoperability, OMG must define GIOP on the specific transmission supported by all vendors. If there are detailed and concise message specifications, interoperability is not provided, because all vendors use different transport mechanisms to achieve this interoperability. Therefore, OMG standardizes GIOP on TCP/IP, the most widely used communication and transmission platform. GIOP and TCP/IP are equal to IIOP! That's simple.

Clients that need to use the published object service will use the values in the IOR to start the connection with the object. We have already circled and returned to ior. Ior is critical to IIOP. Any client that wants to call a method for an object sends the "request" message to the host and port address described in ior. On the host, the server process listens to the port when the request enters and sends those messages to the object. This requires the server to actively listen for requests.

Life has both yin and yang, and everything has shortcomings. Interoperability and IIOP are no exception. OMG has launched and run IIOP, which is a major improvement compared to the time when ORB vendors implement this function on their own servers, and there is no server portability. But what should we do if we require that the server be location-independent? If the host and port values are embedded in the IOR, this problem suddenly occurs whenever you move an object from one server to another to balance the load. Fortunately, this problem has been solved, but there is another bad news that each vendor has a different solution.

Back to Top

Conclusion

Now, I will leave the question of Server Load balancer for future discussions. I am sure you will be pleasantly surprised if you have the "experience" (that is, for a period of time) of CORBA a few years ago and are currently engaged in another research. The CORBA specification has been greatly improved to ensure that the server code you write for one orb can be transplanted to another server running another orb. The solution is simple and based on classic protocols. The standard exchange syntax between the client and the server is based on the requirements described in some OMG details. By using the Network Addressing protocol (IIOP), OMG creates more functions for its specifications independent of the message transmission protocol (GIOP. This also ensures that with the changes in the information industry (indeed rapid development), CORBA can still keep up with it. What I like most is that I don't have to write code for the CORBA object call we just discussed about how to make it complete successfully! Detailed information about network measurement and packaging has been summarized in ORB and the function of Using IDL standardized interfaces. Next month, we will discuss IDL.

References

• For more information, see the original article on the developerworks global site.

• Learn more about CORBA from the OMG website.
• Read excellent books by Michi Henning and Steve vinoskiAdvanced CORBA programming with C ++.
• Co-authored by William ruh, Thomas Herron, and Paul klinkerIIOP complete: understanding CORBA and middleware interoperabilityFor GIOP, CDR, and IIOP references.
• Download orbacus from object oriented concepts, Inc.
• Locate the IOR syntax analyzer on the Xerox PARC site.
• Access the "four-person group" (Erich Gamma, Richard Helm, Ralph Johnson, and John vlissides) design patterns: Elements of reusable object-oriented software to obtain detailed information about the proxy mode.
• From Bruce Eckel's mindview.net andThinking in JavaLearning Java programming knowledge in Version 2

About the author

		Dave Bartlett lives in berwyn, Pennsylvania, USA. He is a consultant, writer, and lecturer. He is the author of hands-on CORBA with Java, a 5-day tutorial for public courses or internal enterprise training. Dave is compiling Course MaterialsThinking in CORBA with Java. Dave has a master's degree in engineering and business at the University of Pennsylvania. If you have questions or are interested in a topic, can you use mailto: dbartlett@pobox.com? Cc = contact Dave.