7.9 Summary

Object-orientation (OO) has a great deal of promise in reducing the complexity of C/S applications. The primary standard for distributed OO systems is OMG’s CORBA. CORBA is a very powerful and important specification for distributed-object-oriented applications. The compound-document standards such as OLE and OpenDoc are being built on top of object- oriented middleware (OpenDoc uses CORBA and OLE uses DCOM). Microsoft shifted its attention from OLE to ActiveX for enterprisewide distributed-object computing over the Internet/Intranet. An important aspect of the current work is to combine distributed objects with the Web (see the sidebar "Combining Distributed Objects with the Web" for different options).

XYZCorp has initiated a technology-assessment effort that focuses on distributed-object technologies. The advanced-technology group in the corporation believes that the distributed-object model should be used as the ONLY model throughout the corporation. You have been asked to:

Hints about the Case Study:

The book by Orfali [1996] is an excellent reference for distributed objects and covers CORBA, OLE, and OpenDoc in great detail. The books by Mowbray [1995], Otte [1996] and Siegel [1996] describe CORBA in great detail. OMG also publishes on different aspects of CORBA. For example, CORBA: Architecture and Specification, CORBA Services, and CORBA Facilities are all OMG-published books. Examples of additional books on CORBA are Otte [1996], Orfali [1996], and Mowbray [1995]. For the most recent information about CORBA, consult the OMG home page (http://www.omg.org).

For OLE technical details, the book by Brockschmidt [1995] should be consulted. Most books on Visual C++ at present include discussion of OLE. For additional information on ActiveX, the book by Chapell [1996] should be reviewed. For additional information, consult the Microsoft home page (http://www.microsoft.com). Information about OpenDoc can be obtained from the CI Labs home page (http://www.cilabs.org).

State-of-the-art information about distributed objects appears in IEEE Software, IEEE Computer, and Communications of ACM (see, for example, the May 1995 issue of IEEE Computer). State-of-the-market and state-of-the-practice information appears in trade magazines such as Client/Server Today, Datamation, and Object Magazine. Detailed analysis of industrial trends can be found in Gartner Group reports and Seybold Group reports (see, for example, Seybold Distributed Computing Monitor, March 1995).

Let us go through an example of developing a simple inventory system by using CORBA. The inventory system consists of a relational table that contains product information (e.g., product ID, product name, price, and quantity on hand). This table is managed by a "product object" that responds to requests from clients to add, view, update, and delete a product. For example, a client invokes a product-view operation by passing a product ID. The product object receives the request and invokes a method that reads the product information and sends it back to the client. Table 7.2 shows the object model for the customer object. In the sections that follow, we will use this model as a starting point for defining the interface, building a server, and building clients in CORBA.

This example is intended to give an overview of the process needed for CORBA application development. Additional details can be found in books and articles [Otte 1996, Minton 1996, Orfali 1996, Mowbray 1995].

Figure 7.19 shows the activities involved in developing OO applications in CORBA (this figure is repeated from an earlier discussion):

The following CORBA definitions are created as the first step in CORBA application development:

As stated previously, the interface of an object is used to declare the behavior of an object. For example, the following statements specify the interface for the product object in CORBA IDL. This interface supports only two operations (we have simplified it somewhat for illustrative purposes):

Figure 7.19 CORBA Application Development

The module statement is used to name a group of interfaces that relate to each other and can be used to represent a package (i.e., a group of objects). The module name becomes part of the name that the client and server use to reference an interface. The interface statement shows what operations can be performed on the customer object (we have shown only two operations; others can be filled in by the reader). Each interface statement defines an interface and contains the descriptions of the operations (operation signatures). The complete name of an operation includes the module and the interface name. For example, "PRODUCT_ PACKAGE::product_interf::create_product" is the fully qualified name of the operation that creates a new product.

The IDL file is compiled to create the client stub and the server skeleton. The client stub and server skeleton are the code templates for building CORBA client and server programs (see Figure 7.19). The client stub is used only to build client programs that use static binding (see Section 7.14.4). The server skeleton is always used as the framework for building the server application, regardless of the invocation type used by the client (see Section 7.14.3).

Operations on objects are implemented by executable code called methods. For example, the product object must contain the code ("add-product-method") that will be executed to actually create a new product when an operation "add-product" is invoked by a client. The collection of methods that accomplishes the set of operations required for an object is called an implementation. Some CORBA implementations offer a mapping language for describing implementations called the Implementation Mapping Language (IML). The implementation descriptions can be stored in an implementation repository. which can be displayed by CORBA compliant commands or the repository manager. The following statements show the implementation of product methods (once again, we have simplified this somewhat):

In addition to IML, you may need to define method maps. These maps are used by the ORB to locate the best server method for the object operation requested when there is more than one active implementation of an interface. For example, when a client invokes the "add_product" operation, then the ORB looks at the method maps to determine the most appropriate method to invoke. The method map can be stored in the interface repository along with the interface definitions. You can use CORBA commands to generate a default method map from the interface definitions.

Building of program servers requires the following steps:

The first step is to specify the IDL statements and then compile these statements to generate a server skeleton. This compilation also uses the information contained in the IML files. The server skeleton contains method templates that show entry points for all of the implementation methods, the server dispatcher code that makes the implementations, and the methods known to the ORB; a registration routine is also generated as part of the server code. The skeleton code simplifies the task of building a server.

Each server initialization needs code to register the implementation (e.g., make itself available for use), activate the server’s implementation, enter a main loop to receive requests, and exit after unregistering and releasing resources. In addition, the server needs routines for creating objects and managing references to these objects. The server skeleton is used to develop this code. The initialization code uses CORBA run-time routines (these routines are identified as CORBA_ or ORB_). An example of the server C-type pseudocode for the product example is listed below (we have simplified this code by ignoring the error checking and by using a generic "parameter" for the CORBA-provided functions):

#include <stdio.h>

#include <orb.h>

#include product.h /* the IDL generated header */

main ()

{

printf ("product server starting \n");

/* Register the implementation */

status = RegisterImpls (parameters);

/* Create object and its reference */

status = CreateObjRefs(parameters);

/*Make server ready */

CORBA_BOA_impl_is_ready (parameters); /* indicate server ready */

/* main loop to listen to client messages */

ORB_BOA_main_loop (parameters); /* enter the main loop */

/* exit code */

CORBA_BOA_dispose(parameters); /* Frees object references */

ORB_BOA_imp_unregister (parameters); /* Unregister */

/* Methods code templates */

}

The major activity in building a CORBA server is to write the code for the methods that execute the operations. For each method template, you must develop the code for the methods. Methods can be implemented as executable code, calls to legacy applications, or scripts to integrate command-line interfaces with existing applications. Methods can be written to invoke OLE (Object Linking and Embedding), DDE (Dynamic Data Exchange), and SQL database accesses. For example, the following pseudocode to access the product relational table can be added to the add_product and view_product methods:

}

The final step in building a server is to compile and link the methods, server initialization code, the generated server dispatcher, and the generated registration routine. The server code can be tested and debugged by using CORBA tracing facilities.

After a server has been built and registered, clients can be built to invoke the servers. As stated previously, CORBA clients can use static invocations (i.e., clients know at compile time the objects and the operations on these objects) or dynamic invocation (i.e., the clients determine at run time the objects and the operations on these objects). We will focus on static invocation in this section and review dynamic invocation in the next. The steps involved in building a static-invocation CORBA client are:

The client stub can be generated from IDL, IML, and MML source files or from the interface repository. The generated stub consists of a header file that contains definitions, and the C language stub routines.

A context object shows a set of properties providing information about the client, the environment, or characteristics of the request. The context object is used by ORB during method resolution to identify user preferences for server selection. Basically, it provides a means of maintaining information between requests for conversational applications. The context information is difficult to pass as parameters in a distributed application. The IDL is used to specify whether the ORB should also retrieve information regarding the request from the context object (the "context" clause in IDL). If no context object is specified, the ORB uses the default context object definition. Context objects can be specified at user level (e.g., user preferences), group level (e.g., data restricted to a group of users), or system level (e.g., display types for an application).

The client code includes header file generated by IDL, "local" client code (e.g., communicate with the user), invoke object operations defined in IDL, and handle errors/exceptions.

To invoke the object operations, a client needs to first get an object reference (object references can be stored by the server at start-up in an external file or registry) and then invoke a method on the object. The following client pseudocode illustrates the key points of a client that invokes the add_product and view_product methods:

#include <stdio.h>

#include product.h /. the IDL generated header ./

/* define variables, etc. */

main ()

{

/* code to obtain object reference. This code depends on where the server stored the reference. If object reference is in a file, then use fget, for example, to read the object reference */

product_interf *pptr; /* *pptr is the object reference */

/* Now invoke the add_product and view_product methods */

/* Other client code, e.g., free resources, error processing, etc. */

After coding, the client is compiled, linked and debugged by using the CORBA environment compilers and tracing facilities?

CORBA’s Dynamic Invocation APIs allow a client program to build and invoke requests on objects at run time. These APIs provide maximum flexibility by allowing new objects to be added at run time. The client specifies, at run time, the object to be invoked, the method to be performed, and the set of parameters through a call or a sequence of calls. The client code typically obtains this information from the interface repository. To invoke a dynamic method on an object, the client must perform the following steps:

CORBA specifies about ten API calls for locating and obtaining objects from the repository. An example of such an API call is lookup_name(). A describe call is issued, after an object is located, to obtain its full IDL definition. To create an argument list, CORBA specifies a NameValue list as a self-defining data structure for passing parameters. The list is created by using the create_list operation. After this, the request is created using the CORBA create_request call. Eventually, the client can invoke the request by using either an invoke call (send the request and obtain the results, i.e., a synchronous call), or a send call (an asynchronous call). The following pseudocode shows a sample dynamic invocation: