We can see from the programs in Figures 8-4 and Figures 8-5 that a barebones CORBA application will require two ORBs, an object adapter, a method for communicating an IOR, and at least one servant object. Figure 8-6 shows the logical structure of a barebones CORBA application. Figure 8-6. The logical structure of a barebones CORBA application.
After the IOR is obtained and narrowed, the remote method invocation in the consumer or client program looks just like regular method calls in a C++ program. In the CORBA examples in this book, the IIOP (Internet Inter ORB Protocol) is assumed. Therefore, the ORBs in Figure 8-6 are communicating using a TCP/IP protocol. The IOR will contain enough information about the remote object's location to facilitate the TCP/IP communication. The object adapter in Figure 8-6 will typically be a portable object adapter. However, some older or simpler programs may use the basic object adapter. We will describe the difference between these two adapters later in this chapter. Each CORBA application has one or more servant objects that implements the interface designed in the IDL class. The simple consumer and producer programs shown in Figures 8-4 and 8-5 can execute on the same computer in different processes or on different computers. If the programs are executed on the same computer then the file adding_machine.ior should be accessible from both programs. If the programs are executed on different computers, then the file will have to be sent to the client computer via ftp , e-mail, http , and so on. The compilation and execution details for the programs shown in Figure 8-4 and 8-5 are shown in Profile 8.1 and Profile 8.2
8.5.1 The IDL CompilerThe IDL compiler is a tool used to translate IDL Class definitions into C++ code. This code consists of a collection of class skeletons, enumerated types, and template classes. The IDL compiler used for the CORBA programs in this book is the MICO IDL compiler. Table 8-3 contains some commonly used command-line options to the IDL compiler. Table 8-3. Some Commonly Used Command-Line Options to the IDL Compiler
The -boa and -poa switches in Table 8-3 can be used to determine what kind of adapter skeletons will be produced. For example, typing the command: idl -poa -no-boa adding_machine.idl will produce a file named adding_machine.h that contains skeletons for the poa (portable object adapter) and it will turn off the production of skeletons for the boa (basic object adapter). Typing the command: idl -h generates a complete list of the IDL compiler switches. If the man pages for the MICO distribution have been properly installed, then typing the command: man idl will provide a complete explanation of the IDL switches available. Designing the IDL classes is the first step in CORBA programming. The next major step in a CORBA program is determining how the IORs for remote objects will be stored and retrieved. 8.5.2 Obtaining IOR for Remote ObjectsThe ORB class has two member functions that can be used for converting IOR objects between strings and Object_ptrs . The methods are string_to_object() and object_to_string() . The string_to_object() member function takes a const char * and converts it to an Object_ptr . The object_to_string() member function takes an Object_ptr and converts it to a char * . These methods are part of the ORB class interface. The object_to_string() method is used to stringify object IORs. Once the IOR has been stringified it can be transmitted to client and consumer programs through a variety of techniques, including:
The receiving program then takes the stringified IOR and uses its ORB's string_to_object() member function to convert the IOR to a CORBA object ptr . The CORBA object ptr is then narrowed and used to initialize the local object. Programs 8.1 and 8.2 use stringified objects and a file to communicate the IOR between the consumer program and the producer program. The stringified IOR can be used to facilitate very flexible connections to remote objects that can reside virtually anywhere on the Internet or on any intranet or extranet. In fact, the MIWCO (Wireless Mico) is an open -source implementation of wCORBA, [4] the wireless CORBA standard, and can be used to enhance the mobility of objects. The wireless specification enables mobility through a MIOR (Mobile IOR). The wireless specification has support for TCP, UDP, and WAP WDP (Wireless Application Protocol Wireless Datagram Protocol) transports. Multiagent and distributed agent systems can also benefit by taking advantage of the IOR standards. The IOR and MIOR are part of the building blocks for the next generation of object-oriented Web services. It is important to note that although the stringified IOR provides a flexible and portable object reference, it may not be ideal for all situations and configurations. Moving a file containing the IOR may not be practical for many installations. Forcing client and server applications to share the same file system or network may not be practical. Security concerns might exclude the stringified IOR as an option. If a client-server application is large and diverse enough, then the stringified IOR sharing may be too restricting. The CORBA specification includes two other standards for obtaining or communicating object references: naming services, and trading services.
|