CorbaWeb: A Navigator for CORBA Objects

Philippe, a postgraduate student at the University of Lille, France, can be contacted at [email protected]. Christophe is a lecturer at the University of Lille and can be reached at [email protected]. Jean-Marc, a professor of computer science at the University of Lille, can be contacted at [email protected].

The CorbaWeb environment (http:// corbaweb.lifl.fr/) is a generic gateway between HTTP servers and CORBA objects. CorbaWeb, which can be classified as a "generic object navigator" (see P. Merle et al., "CorbaWeb: A Generic Object Navigator," Proceedings of the 5th International World-Wide Web Conference, May 1996) enables World Wide Web clients to navigate through CORBA object links using dynamically generated URLs for each object. CorbaWeb is composed of meta scripts allowing the access, representation, and invocation of any CORBA object across the Web. These operations are executed by scripts (currently CGI programs) written in the CorbaScript interpreted scripting language.

The CorbaWeb environment has been implemented on a Sun SPARCstation with Orbix 2.0 for Solaris 2.4 (for more information, see P. Merle et al., "CorbaScript and CorbaWeb: A Generic Object-Oriented Dynamic Environment upon CORBA," Proceedings of TOOLS Europe'96). The CorbaWeb prototype implementation consists of 20,000 lines of C++ code including the syntax analyzer, interpreter engine, and CORBA-specific code. We plan to adopt another server API, like Apache API instead of CGI, to improve performance, but the CorbaWeb architecture will not be modified. CorbaWeb was designed to support a Shared Information Space (SIS) model in which highly distributed information is accessed by large numbers of cooperative users. An SIS is delivered by distributed servers and accessed by standard client programs. As opposed to the World Wide Web, an SIS is structured by various types of objects. Users navigate an SIS by following links between these objects. Any operation can be invoked on these objects. Navigation is accomplished by a single, uniform user interface (a browser) no matter what the information types. The navigator adapts itself to the user's profile and to the object types. An SIS also manages object-access control policies to protect information confidentiality and prevent anybody from accessing and modifying information. The four major facets of this model involve:

• Object orientation, which allows the construction of applications using classes. SIS makes it possible to mix classical and multimedia objects: data (databases), services (computational objects), and multimedia (sound, image, video objects).
• Distributed/heterogeneous environments, in which clients and servers are running on different architectures and operating systems. Communication between several programs is achieved using the common protocols: HTTP between web clients and web servers; IIOP (see "Universal Network Objects," OMG Document Number 94.9.32) between CORBA applications.
• Navigation and invocation through a single, uniform user interface. Users always apply operations and show results in the same way, no matter what kind of information they manipulate or computing environment they use. Traditionally, you find N user interfaces for N applications. In the SIS model, you use one interface for all applications, and all navigation through this space is accomplished via hypertext. In an application designed with object methodology, for example, users can follow the references between objects to browse information contained in objects.
• Users' point of view. In the SIS model, information is displayed according to a user's profile. In a medical application, for example, a physician can browse a patient's medical folder, seeing all information about the patient. When browsing the same folder, however, a hospital receptionist sees only a part of it (patient name and address). As the information space is shared between several users, object access-control policy protects information confidentiality, and prevents anybody from accessing and modifying any information.

To implement SIS environments, you will need:

• An Interface Definition Language (IDL) to specify SIS object interfaces.
• The Common Object Request Broker Architecture (CORBA) to support SIS object servers.
• Web browsers as a single, uniform user interface to navigate through SIS objects.
• URLs to access objects and apply operations on them.
• HTML to present the object state.
• CGI in web servers as a gateway between the Web and SIS objects.

From a technological point of view, our work involves the integration of the Web and CORBA. Services are implemented in an appropriate language and are accessible through a standard web browser or specific CORBA client application. On the web side, we're investigating how to access any CORBA-based information system, even if the system was not designed for the Web. In short, the SIS model provides the best CORBA-based object-oriented programming and web-based hypermedia navigation.

The CorbaWeb Environment

Recognizing the need for a standard in object-oriented application interoperability, the Object Management Group (OMG) created a unified, distributed architecture to promote object technologies. The CORBA specification defines an object-oriented messaging facility for distributed-object environments.

CORBA provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems. CORBA is specified independently of any programming language, since object interfaces are described in the IDL. As Figure 1 illustrates, a typical CORBA environment consists of:

• A client/server object-oriented invocation system. The communication between objects is supported by a standard stubs mechanism generated by the compilation of IDL descriptions. This separation hides distribution and permits heterogeneity between the service consumer (client) and the service producer (server).
• An adaptive object-support policy. CORBA provides object adapters to accommodate a diverse range of object features such as lifetime and granularity policies.
• A reflexive environment. CORBA provides objects at run time to retrieve IDL information (Interface Repository). It facilitates dynamic type checking and allows the construction of requests through the dynamic invocation interface (DII).

The IDL allows the definition of types, structures, exceptions, and interfaces. An object interface is a set of attributes and operations applying to its instances. Each operation is specified by a return type, operation name, set of parameters, and list of related exceptions. Each parameter is specified by a call mode (in, out, and inout), type, and name. A type can be any basic IDL type (integer, double, Boolean, char, string, object reference) or constructed type (structure, sequence, array, union, or object interface). Operations can return exceptions to signal problems.

Example 1 is an IDL description that defines the object-interface computer. This interface contains three operations: is_prime_number determines if a number is prime; prime_numbers computes prime numbers less than a specified value; and decompose_into_prime_factors decomposes a number into its prime factors.

This object type can be implemented with any CORBA-supported language. A language mapping defines how this language interfaces with CORBA. Currently, the mappings for C, C++, Smalltalk, and Ada95 have been specified by the OMG.

The CorbaWeb Architecture

To promote integration between the World Wide Web and CORBA objects, the CorbaWeb environment acts as a generic gateway between HTTP servers and CORBA systems. The web browser manages user interactivity and sends user actions to the web server. CorbaWeb receives user actions and executes operations on CORBA objects. These operations are invoked by scripts written in CorbaScript.

The CorbaWeb architecture (see Figure 2) is supported by:

• Standard WWW technology. Any web browser acts as a GUI to browse and invoke CORBA objects represented both by HTML anchors (to access objects) and HTML Forms (to invoke operations on them).
• CorbaWeb interprets user requirements by invoking objects. It is composed of many CorbaScript CGI scripts that invoke objects and generate HTML documents to show request results.
• CorbaScript lets you write scripts that dynamically invoke objects. This language contains constructions to manage variables, control execution flow, catch exceptions, and the like.
• The CorbaWeb (CorbaScript) interpreter translates CGI parameters into CorbaScript variables.
• The CORBA environment supports the heterogeneous distributed-object-oriented system and the DII.
• The Interface Repository contains a graph of objects representing IDL descriptions. These objects are dynamically invoked to check invocations of scripts.
• The CorbaWeb Repository maintains CorbaWeb environment information. For instance, it stores representation and access-control information. This information is structured by CORBA objects. It is handled by special scripts (also called "meta scripts").

The CorbaScript Language

A CorbaScript program is a sequence of instructions.

The print instruction outputs any value. It recursively explores structures, unions, arrays, and sequences to display their field values. For instance, a structure is displayed by an HTML list. Each field is an item of this list. An object reference is displayed by an HTML anchor referring to a CGI script that displays the object.

The assignment instruction (=) assigns a value to a variable. Variables are defined at their first use. A variable can be set with any IDL value.

The conditional-test instruction is constructed as follows: test_construction ::= if condition { instructions1 }[ else { instructions2 } ]. instructions1 is executed if condition is True; otherwise instructions2 is executed.

The conditional-loop construction is loop_ construction :: while condition { instructions }. The instruction is executed while condition is True.

The exception-management construction handles CORBA exceptions; see Example 2. This construction executes instructions1. If an exception is raised by one operation of instructions1, then instructions2 are executed. Several exception types can be caught, and each is managed by a separate catch clause. If an unexpected exception is raised, then instructions3 are executed. If an exception is raised from a catch block (instructions2, instructions3, for example) then it is propagated in the previous block.

The invocation mechanism (. operator) permits operation calling, attribute getting, or attribute setting on any CORBA object.

Objects are dynamically invoked through the DII. CorbaScript and its interpreter hide the complexity of using the DII. The interpreter translates scripts into dynamic invocations. Invocations are checked, thanks to the IDL signatures retrieved from the Interface Repository. The parameters are dynamically checked and inferred if necessary. The interpreter dynamically constructs a request according to parameters. This request is then sent to the ORB. The ORB executes the request on the appropriate object and returns the result.

A script is a set of instructions handling values and variables. A CorbaScript value could be:

• Any basic value like integer, float, character, or string.
• A set of CorbaScript values such as (10, 'a', "hello").
• The result of an operation invocation on an object.
• Any CORBA typed value composed of an IDL type and set of values.
• Any expression with standard operators (+, or, <, ...).
• A variable (computer, for example).
• A CORBA object reference.

A CorbaScript object reference of a CORBA object is composed of an IDL object interface, object name, application name, and host name. For example, computer("my_computer:computerSvr:blanche") refers to an object of type computer with the name my_computer. This object is managed by the computerSvr application that runs on the host blanche.

We have a complete mapping of IDL in CorbaScript so we can handle simple or composed IDL values (integer, character, string, sequence, union, and so on). The shell performs type inference on the parameters; for example, (10, "hello", True) given as a parameter to a method call is translated into the appropriate IDL structure. The user does not give the IDL types for the items in the structure or the structure type; all this work is done by the interpreter.

A CorbaScript Example

Although it is not directly accessible from the standard Web, the previous object computer can be a web service. CGI protocol provides a way to access it -- designing a CGI script that acts as a gateway between a web server and a computer instance. Consequently, this CGI program is referred by the /cgi-bin/prime_service URL. The CGI program generates the graphical interface to use an object computer (other solutions are possible). Figure 3, an HTML document generated by this CGI script, contains HTML Forms to call the various operations of this object. The action associated with each form is a URL to the CGI script with a distinct query string (for example, ?is_prime, ?prime_numbers, and ?decompose). Listing One llustrates how to a write CGI script to access a CORBA object computer.

The CorbaScript interpreter (named "cwsh") translates CGI parameters into CorbaScript variables. The variable computer refers to a computer instance. This script generates an HTML document according to the value of the CGI variable QUERY_STRING. If it contains:

• a null value, the script generates HTML Forms (Figure 3) to use the service.
• an is_prime value, then it invokes the is_prime_number operation of the computer object.
• a prime_numbers value, then it invokes the prime_numbers operation of the computer object.
• a decompose value, then it invokes the decompose_into_prime_factors operation of this object.

After each invocation, the script displays the invocation result.

CorbaScript simplifies the implementation of CGI scripts that interface objects with the Web. Still, this first approach looks like standard CGI programming, the main difference being that CorbaScript is a dynamically interpreted scripting language specially designed for CORBA and OMG-IDL. Thus, the web integration of several million objects and several hundred object interfaces requires you to program a plethora of CGI scripts. Meta scripts solve this problem.

CorbaWeb: A Set of Meta Scripts

Meta scripts allow the definition of generic actions on CORBA objects. These scripts take parameters (like object references or scripts) and apply meta operations (such as an object browsing or a script executing) on them.

The Exec meta script (see Listing Two) takes a script as a parameter, then executes it. It allows users to invoke operations on any object from a web browser. If the parameter is not set, then the script generates an HTML Form and the user types its parameter script.

The Exec meta script in Listing Two presents the instruction eval and a variable EXCEPTION. The eval instruction takes one string as a parameter and executes it as a CorbaWeb script. This executed script can raise exceptions and the meta script must catch them and signal the web user. The variable EXCEPTION stores the last exception. CorbaWeb unmarshals an exception into an HTML list as it unmarshals complex IDL types. This generic unmarshaling is based on the possibility of exploring a CORBA TypeCode (which represents an IDL type) at run time.

The script aims to provide a distant invocation mechanism for mobile code. The next meta script reuses the first meta script to provide a generic object browser that allows the invocation of any defined operation on any object type.

The Interface meta script takes an object reference as a parameter and generates an HTML document containing one HTML Form for each operation of the object IDL interface. The action of each Form refers to the Exec meta script. From the object reference, the script retrieves its interface object. This object is managed by the Interface Repository. The script accesses the IR object and retrieves all operations and attributes of this interface. It generates a form for each operation or attribute. When an operation takes parameters, it generates HTML input text fields. For an enum parameter, it generates a popup menu (<SELECT>..</SELECT> in HTML). For instance, the computer object can be browsed via HTML Forms (see Figure 4(a)) automatically generated by the Interface meta script. Then it can be invoked via the Exec Meta Script in Figure 4(b).

The Exec and Interface meta scripts define basic meta operations (that is, invocation and browsing) allowing users to access and invoke any object. In a shared information space, however, objects must be displayed according to users' profiles. For each object type and profile, we associate a View script. These scripts are composed of CorbaScript instructions that generate an HTML document representing the object state. They are stored into the CorbaWeb Repository.

Thus, the View meta script in Figure 5 takes two parameters -- an object reference and a profile (1). It retrieves from the CorbaWeb Repository the appropriate view script according to the object type and profile (2). Then it executes the retrieved script (3), which calls attributes and operations on the object (4), and generates an HTML document presenting the object state (5). The script can also generate HTML forms to invoke object methods.

Figure 6, for instance, shows a complex HTML document generated by View scripts. This figure illustrates a hospital information system mixing multimedia and structured-object information. In this example, the user is a physician whose profile is mapped by the HTTP authentication mechanism. Note that navigation across structured information is achieved by anchors. These anchors are dynamically generated URLs referring to the View meta script.

The concept of meta scripts allow seamless integration of any CORBA object into the Web. These scripts are designed for general purposes and handle meta operations on objects. Meta scripts can be used in many ways, including distant invocations supported by the Exec meta script, HTML Forms representing IDL object interfaces that are automatically generated by the Interface meta script, View meta scripts that allow the generation of HTML or MIME documents representing the state of any object, and (in the near future) VRML documents that could be generated by a VRML meta script to navigate in 3-D objects.

The CorbaWeb environment can be incrementally extended thanks to meta scripts. Moreover, meta scripts permit the integration of legacy CORBA objects (that is, those not designed for the Web) without object modification.

Conclusion

The integration of the Web and object-oriented design provides a great way to manage the explosion of web services. We are currently testing this environment on a hospital information system. This experimentation will enable us to define new required meta scripts and propose an object-access-control policy for the CorbaWeb environment.

Our SIS model combines the benefits of both environments -- the WWW as a hypermedia browsing environment and CORBA as an object-oriented structuring system. It is our belief that the WWW and CORBA will merge to provide the next infrastructure for distributed client/server computing.

References

Merle, P., C. Gransart, and J.M. Geib. "CorbaScript and CorbaWeb: A Generic Object-Oriented Dynamic Environment upon CORBA." Proceedings of TOOLS Europe '96. Prentice-Hall, February 1996. http://www .lifl.fr/~merle/papers/TOOLS96.ps.gz.

Merle, P., C. Gransart, and J.M. Geib. "CorbaWeb: A Generic Object Navigator." Proceedings of the Fifth International World-Wide Web Conference, May 1996. http://www.lifl.fr/~merle/papers/96_WWW5/paper/Overview.html.

Object Management Group. "The Common Object Request Broker: Architecture and Specification." Revision 1.2. OMG Document Number 93.12.43, December 1993. ftp://ftp.omg.org/pub/docs/1993/93-12-43.ps.

Object Management Group. "Universal Network Objects." OMG Document Number 94.9.32, September 1994. ftp://ftp .omg.org/pub/docs/1994/94-09-32.ps.

The Orbix Home Page at IONA Technologies. http://www.iona.ie/.

For More Information

The Corbaweb home page

DDJ

Listing One

#! /bin/cwsh
print "Content-type: text/html\n\n<HTML>\n"
computer = computer("my_computer:computerSvr:blanche")
if ( QUERY_STRING == "" ) {
  # generates HTML Forms (see Figure 3)
  # each text field of HTML forms is named 'number'.
}
if ( QUERY_STRING == "is_prime" ) { ... invokes computer and displays result ...
}
if ( QUERY_STRING == "prime_numbers" ) {
  result = computer.prime_numbers(number)
  print "The prime numbers less than the number " , number , " are\n<P>\n"
  print result
}
if ( QUERY_STRING == "decompose" ) { ... invokes computer and displays result
 ... }
print "</HTML>\n"

Back to Article

#! /bin/cwsh
print "Content-type: text/html\n\n<HTML>\n"
if ( QUERY_STRING <> "" ) {
  print "<TITLE>" , QUERY_STRING , "</TITLE>\n<BODY>\n"
  try {
    print eval ( QUERY_STRING )
  } catchany ( EXCEPTION ) {
    print "Exception raised: " , EXCEPTION
  }
  print "</BODY>\n</HTML>\n"
} else {
  # generates HTML Form for user's input
}

Back to Article