CorbaWeb: A Generic Object Navigator

Philippe Merle
Christophe Gransart
Jean-Marc Geib

Laboratoire d'Informatique Fondamentale de Lille - URA CNRS 369
Université de Lille 1, Bat M3
59655 Villeneuve d'Ascq Cedex - France
Phone: (33) 20 43 47 21
Fax: (33) 20 43 65 66
Email: {merle, gransart, geib}


The World Wide Web and Distributed Object-Oriented Systems (e.g. CORBA) provide future infrastructures for distributed client/server computing. This paper presents our work to provide the integration of CORBA objects into the Web: first, to describe Web services using object-oriented technologies and second to access any Information System developed with CORBA from the Web.
We present a new Shared Information Space model with the following issues: Object Orientation Design, Distributed and Heterogeneous Environment, Users' Point of View, Object Invocation and Navigation.
Navigation over SIS is supported by CorbaWeb, a Generic Object Navigator, composed of metascripts allowing the access, the representation and the invocation of any CORBA object from the Web. These operations are achieved by scripts written in CorbaScript, an interpreted scripting language which can dynamically invoke any CORBA objects.


WWW, object orientation, CORBA, interoperability, scripting language, generic object navigator.


The WWW is the "killer system" of the 1990s to access distributed information and services on Internet thanks to its user-friendly uniform interface. But WWW users ask for many extensions: integrating new kinds of Web resources, extending Web browsers, changing stateless Web protocol. These problems can be overcome with a uniform model of resource interfaces, and transportable front-ends, that could be generically integrated in WWW.

In the last five years, most computing technologies have been influenced by the object-oriented approach: design methods, databases, components libraries, programming languages and distributed object-oriented systems. As [Black94] pointed out, WWW may be seen as an Object-Oriented Operating System. It furnishes the canonical functionalities of an OOOS:

These authors point out some lessons about WWW that can increase the OOOS impacts: A uniform paradigm to encapsulate and structure Web components can be achieved thanks to the Object Management Group's Common Object Request Broker Architecture (CORBA) [OMG93]. Its object-oriented approach brings modularity, flexibility and abstraction to the diversity of needed features encountered into WWW. Moreover a parallel can be made between a set of objects and an hypertext-linked set of resources. Hypertext navigational model can be used to navigate through CORBA objects, and so, WWW can be used as a uniform ``any-object'' presentation and invocation GUI.

In this paper, we present a new model which defines shared information spaces. This model is supported by the CorbaWeb environment [Merle96]: A generic gateway between http servers and CORBA objects. This enables to navigate over and invoke CORBA objects as easily as users navigate over WWW documents. With CorbaWeb, a WWW client can navigate through CORBA object links using dynamically generated URLs for each object. These URLs refer to CorbaWeb scripts: a first one executes any operation on any object, a second one automatically generates HTML Forms from IDL interfaces and a third one generates an HTML representation [Berns95] of the object state. Currently, these scripts are CGI programs written in CorbaScript. CorbaScript is an interpreted scripting language to apply any operation on any CORBA object. Objects are dynamically invoked through the Dynamic Invocation Interface (DII): Invocations are checked thanks to the object IDL signatures retrieved from the CORBA Interface Repository.

Our Shared Information Space Model

As the Web, a Shared Information Space (SIS) is a large set of information highly distributed and accessed by a high number of various cooperative users. A SIS is brought by distributed servers and accessed by standard client programs. Contrary to the Web, a SIS is structured by objects which can be of various types. A user can navigate through a SIS by following links between objects. It can invoke any operation on these objects. The navigation is done thanks to a single uniform user interface (i.e. a browser) whatever information types. The navigator adapts itself to the user's profile and to the object types. A SIS manages object access control policies to protect information confidentiality and to prevent anybody from accessing and modifying any information. The four major issues of this model are:
Object Orientation
Object-oriented design allows the construction of applications using classes. Well-known benefits of object-oriented design [Wegner90] are encapsulation, extensibility, modularity ... These benefits can be preserved in distributed heterogeneous information systems [Manola93]. In our information model, we have the possibility to mix classical data and multimedia data: data objects (e.g. database), service objects (e.g. computational object) and multimedia objects (e.g. sound, image, video objects).

Distributed and Heterogeneous Environment
Clients and servers applications are running on different architectures and operating systems. Communication between several programs can be achieved using the same protocol (e.g. HTTP between Web clients and Web servers; IIOP [OMG94] between CORBA applications). Using these protocols permits one to have distributed and heterogeneous information systems.

Navigation and Invocation
We submit that a single uniform user interface can simplify information exploitation e.g. data browsing and service invocations. Users apply operations and show results always the same way whatever the kind of information they manipulate and the computing environment they use. In general, one finds N user interfaces for N applications. In our model, we use 1 interface for all applications. The navigation through this space is done using the hypertext metaphor. For example in an application designed with object methodology, a user who navigates in it can follow the references between objects to browse information contained in objects.

Users' Point of View
In our Shared Information Space Model, information is displayed according to the user's profile. For example in a medical application, when a physician browses a patient medical folder, he/she sees every information about the patient but when a hospital receptionist browses the same folder, he/she sees only a part of it (patient name, address). This example illustrates that the same information is not seen the same way according to people who access it.
As the information space is shared between several users, an object access control policy must be installed to protect information confidentiality and to prevent anybody from accessing and modifying any information.

To implement SIS environments, we want to reuse current technologies: From a technological point of view, our work concerns the integration between the Web and CORBA: This integration model aims at providing the most important features of both environments: object-oriented programming from CORBA and hypermedia navigation from the WWW.

Our CorbaWeb Environment

C.O.R.B.A.: A Common Object-Oriented Architecture

Recognizing the urgent requirement for a standard in object-oriented application interoperability, the industry has formed the Object Management Group (OMG) consortium to create a unified distributed architecture to promote object technologies. In 1991, it proposed the Object Management Architecture guide (OMA) [OMG92]. The OMA gives an overview of a federated distributed object system. The first OMG specification was the Common Object Request Broker Architecture (CORBA) [OMG93]. CORBA specifies an object-oriented messaging facility for a distributed object environment: the Object Request Broker (ORB) allowing any object to invoke the services of any other object. Thus, 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 Interface Description Language (IDL). A CORBA environment (cf Fig.1) is decomposed into three main parts:
Fig.1. The Common Object Request Broker Architecture.

The Interface Description Language

The IDL language 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, an operation name, a set of parameters and a list of related exceptions. Each parameter is specified by a call mode (in, out and inout), a type and a name. A type can be any basic IDL type (e.g. integer, double, boolean, char, string, object reference) or constructed types (e.g. structures, sequences, arrays, unions or object interfaces). Operations can return exceptions to signal problems.

The following example illustrates an IDL description. It defines the object interface computer. This interface contains three operations: is_prime_number which computes if a number is prime, prime_numbers which computes prime numbers less than a number and decompose_into_prime_factors which decomposes a number into its prime factors.

interface computer {
  typedef unsigned long Positive;
  boolean is_prime_number (in Positive number);
  sequence<Positive> prime_numbers (in Positive number);
  sequence<Positive> decompose_into_prime_factors (in Positive number);
This object type can be implemented with any language supported by CORBA. A language mapping defines how this language interfaces with CORBA. Currently, the mappings for C, C++, SmallTalk and Ada95 are specified by the OMG. Nevertheless, an effective computer implementation could be done on a supercomputer because prime algorithms consume many CPU resources. In the following sections, a computer instance is considered as a distributed resource.

The CorbaWeb Architecture

To experiment the integration between the Web and CORBA objects, we have implemented the environment CorbaWeb. This environment acts as a generic gateway between http servers and CORBA systems: A Web server extension through the CGI protocol. Users invoke and navigate over CORBA objects as easily as they navigate over the World Wide Web. Any Web browser (Mosaic, NetScape, HotJava) manages the user interactivity and sends users' actions to the Web server. CorbaWeb receives users' actions and executes operations on CORBA objects. These operations are invoked by scripts written in the language CorbaScript.

The CorbaWeb environment is supported by the following components (cf Fig.2):

Fig.2. The CorbaWeb Architecture.

Thus, CorbaWeb dynamically furnishes a transparent access to all CORBA objects through a WWW server. In the next section, we present the main characteristics of the language CorbaScript which is the basis of the CorbaWeb environment.

CorbaScript: A New CGI Language

CorbaScript is a new interpreted scripting language developed from scratch. We have chosen to develop it to include the dynamic invocation operation on CORBA objects in the CorbaScript nucleus. Integrating this mechanism in an existing language would be more complicated and the syntactic simplicity would not be obtained.

The first way of using the CorbaWeb environment allows the writing of CGI programs which invoke objects. These programs are written with the language CorbaScript. After describing the main features of the CorbaScript language, we show how to integrate in the Web a previous object computer via a CorbaScript program.

The CorbaScript Language

A CorbaScript program is a sequence of the following kinds of instructions : Objects are dynamically invoked through the Dynamic Invocation Interface. The language CorbaScript and its interpreter hide the complexity of the use of 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 infered if necessary. The interpreter dynamically constructs a request according to parameters. Then this request is sent to the ORB which executes the request on the right object and returns the result.

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

A CorbaScript object reference of a CORBA object is composed of four parts: an IDL object interface, an object name, an application name and a host name; e.g. 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 which 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, ...). 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 neither for the items in the structure nor for the structure type; all this work is done by the interpreter.

The Computer Example

The previous object computer can be a Web service. But it is not directly accessible from the standard WWW. The CGI protocol provides a solution to access it: designing a CGI script which acts as a gateway between a Web server and a computer instance. So this CGI is referred by the /cgi-bin/prime_service URL. This CGI program generates the graphical interface to use an object computer (other solutions are possible). Fig.3 shows an HTML document generated by this CGI script. It contains HTML Forms to call the various operations of this object. The action associated to each form is a URL to the CGI script with a distinct query string (e.g. ?is_prime, ?prime_numbers, and ?decompose).

Fig.3. The Prime Service Page and its HTML Forms.

The following program illustrates the way to write a CGI script to access a CORBA object computer.

#! /usr1/bin/cwsh
echo "Content-Type: text/html\n\n<HTML>\n"
$computer := computer(my_computer:computerSvr:blanche)
if $QUERY_STRING = "" then
  # generates HTML Forms (cf Fig.3)
  # each text field of HTML forms is named 'number'. 
if $QUERY_STRING = "is_prime" then ... invokes computer and displays result ... end
if $QUERY_STRING = "prime_numbers" then
  $result := $computer.prime_numbers($number)
  echo "The prime numbers less than the number " , $number , " are\n<P>\n"
  echo $result
if $QUERY_STRING = "decompose" then ... invokes computer and displays result ... end
echo "</HTML>\n"
The CorbaScript interpreter is named cwsh. It translates CGI parameters into CorbaScript variables (e.g. $QUERY_STRING, $number). 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 :
  1. a null value then the script generates HTML Forms (cf Fig.3) to use the service,
  2. is_prime value then it invokes the is_prime_number operation of the $computer object,
  3. prime_numbers value then it invokes the prime_numbers operation of the $computer object, or
  4. 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 which interface objects with the Web. But this first approach looks like the standard CGI programming, the main difference being that CorbaScript is a dynamic interpreted scripting language specially designed for CORBA and OMG-IDL. Thus, the Web integration of several million objects and several hundred object interfaces requires to program a plethora of CGI scripts. In the next section, we introduce the concept of meta scripts to solve this engineering problem.

CorbaWeb: A Set of Meta Scripts

A meta script allows the definition of generic actions on CORBA objects. These scripts take parameters like object references or scripts. They apply meta operations on these parameters such as an object browsing or a script execution.

Exec Meta Script

This meta script takes a script as parameter, and then executes it. It allows user 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.
#! /usr1/bin/cwsh
echo "Content-Type: text/html\n\n<HTML>\n"
if $QUERY_STRING <> "" then
  echo "<TITLE>" , $QUERY_STRING , "</TITLE>\n<BODY>\n"
    execute ($QUERY_STRING)
    echo "Exception raised: " , $EXCEPTION
  echo "</BODY>\n</HTML>\n"
  # generates HTML Form for user's input
This script presents the new instruction execute and a special variable $EXCEPTION. The new 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 it to the Web user. The special variable $EXCEPTION stores the last exception. CorbaWeb unmarshalls an exception into an HTML list as it unmarshalls complex IDL types. This generic unmarshalling is based on the possibility to explore a CORBA TypeCode which represents an IDL type at runtime.

This script aims at providing a distant invocation mechanism for mobile code. The next meta script reuses this meta script in order to provide a generic object browser which allows the invocation of any defined operation on any object type.

Interface Meta Script

This script takes an object reference as 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 (cf Fig.4a) automatically generated by the Interface Meta Script. Then it can be invoked via the Exec Meta Script (cf Fig.4b).

Fig.4. Meta Script Execution Examples.

View Meta Script

The previous meta scripts define basic meta operations: invocation and browsing allowing users to access and invoke any object. But in a shared information space, objects must be displayed according to users' profiles as we have presented in our model. We define a profile as a kind of user such as a physician's profile or a receptionist's profile. For each couple of one object type and one profile, we associate a view script. These scripts are composed of CorbaScript instructions which generate an HTML document representing the object state. They are stored into the CorbaWeb Repository.

Thus, the view meta script takes two parameters: an object reference and a profile. It retrieves from the CorbaWeb Repository the appropriate view script according to the object type and the profile. Then it executes the retrieved script. This script calls attributes and operations on the object, and generates an HTML document presenting the object state. The script can also generate HTML forms to invoke object methods.

For instance, Fig.5 shows complex HTML documents generated by view scripts. These snapshots illustrate an hospital information system mixing multimedia information and structured object information. In this example, the user is a physician and its profile is mapped by the HTTP authentication mechanism.

Fig.5. HTML Pages of a French Hospital Information System.

Note that the navigation across structured information is achieved by anchors. These anchors are URLs dynamically generated referring to the view meta script.

Then the CorbaWeb Repository and the View Meta Script are powerful tools to handle meta information (scripts) to display any CORBA object according to users' profiles.

Meta Script Summary

The concept of meta scripts allows the seamless integration of any CORBA object into WWW. These scripts are designed for general purposes and they handle meta operations on objects. As described below, meta scripts can be used in many ways: The CorbaWeb environment can be incrementally extended thanks to meta scripts. Moreover meta scripts permit the integration of legacy CORBA objects (i.e. not designed for WWW) without any object modification.

Related Work

There are some other projects which investigate object-oriented design and the Web: The previous approaches tend to design Web applications using object-oriented technologies. Applications are specifically designed to manage and encapsulate particular kinds of resources. But users can not directly access these resources or objects. Then the only solution to integrate a legacy object is to develop a Web application.

In W3Objects[Ingham95], all Web resources are seen as objects described by an interface. Then Web servers are represented by W3Object instances. This approach aims at providing an extensible web architecture.

Our approach focusses on the access to any CORBA object through generic mechanisms without specific developments for such objects. With CorbaWeb, users can display resources and invoke operations defined on them. In that way, our work provides the access to objects from Web instead of the design of Web applications using objects.
Let's note that specific Web applications can be developed with CORBA objects and accessed by the CorbaWeb environment.


The CorbaWeb environment has been implemented on a SUN Sparc station with Orbix 1.3 [ORBIX] for Solaris 2.4. The CorbaWeb prototype implementation consists of 8,000 lines of C++ code including the syntax analyzer, the interpreter engine and the CORBA specific code. All HTML figures in this paper are execution snapshots of the current prototype. We plan to adopt another server API like Apache API instead of CGI to improve performances but the CorbaWeb architecture will not be modified.

The integration between WWW and Object-Oriented Design is a great deal to manage the explosion of Web services. We propose a generic gateway to integrate any object on the Web server side. This integration is supported by the environment CorbaWeb: A new scripting language CorbaScript and a set of meta scripts. Each meta script implements a meta operation on CORBA objects. At present, we defines three meta scripts: the Exec one executes any operation on objects, the Interface one generates automatically Graphical User Interfaces from IDL interfaces and the View one generates an HTML representation from the object state (via scripts stored in the CorbaWeb Repository). This set of meta scripts can be easily extended.

We are testing this environment on a hospital information system: It is modelized by objects and the users' interface is implemented by WWW browsers and CorbaWeb. This experimentation will aim at defining new required meta scripts and proposing an object access control policy for the CorbaWeb environment.

Our shared information space model combines the benefits of both environments: WWW as an hypermedia browsing environment and CORBA as a structuring object-oriented system. We argue that WWW and CORBA will merge to provide the next infrastructure for distributed client/server computing. Thus we submit that Web resources could be implemented by distributed CORBA objects. CorbaWeb allows WWW clients to access, display, navigate over and invoke any CORBA object, therefore it provides a set of functionalities to support a generic object navigator.


[Apache] The Apache Home Page,

[Berns95] T. Berners-Lee and D.W. Connolly,
Hypertext Markup Language - 2.0,
Internet Network Working Group RFC 1866, MIT/W3C, November 1995.

[Berns96] T. Berners-Lee, R. Fielding, and H. Frystyk,
HyperText Transfert Protocol - HTTP/1.0,
Internet Network Working Group draft, Work in progress (expires August 19, 1996),
MIT/LCS, UC Irvine, February 19, 1996.

[Black94] A.P. Black and J. Walpole,
Objects to the rescue! or httpd: the next generation operating system,
ACM-SIGOPS 94, Sixth SIGOPS European Workshop,
Wadern Germany, September 1994.

[Edwards95] Nigel Edwards,
Object Wrapping (for WWW) -- The Key to Integrated Services?,
The AnsaWeb Project, Document Identifier APM.1464,
Architecture Projects Management Ltd, Cambridge, 1995.

[Everitt96] Paul Everitt,
The ILU Requester: Objects Services in HTTP Servers,
W3C Informational Draft 07-Mar-96,

[ILU] Inter-Language Unification -- ILU

[Ingham95] D. Ingham, M. Little, S. Caughey, S. Shrivastava,
W3Objects: Bringing Object-Oriented Technology to the Web,
Fourth International Conference on the World-Wide Web,
Boston, December 1995.

[Jagannathan94] G. Alamsi, A. Suvaiala, C. Goina, C. Cascaval, V. "Juggy" Jagannathan,
TclDii: A TCL Interface to the Orbix Dynamic Invocation Interface,
TR, 1994.

[Manola93] J.R. Nicol, C.T. Wilkes, F.A. Manola,
Object Orientation in Heterogeneous Distributed Computing System,
IEEE Computer 26, June 1993.

[McCool] R. McCool,
The Common Gateway Interface,

[Merle96] P. Merle, C. Gransart and J.M. Geib,
CorbaScript and CorbaWeb: A Generic Object-Oriented Dynamic Environment upon CORBA,
In Proceeding of TOOLS Europe'96, Palais des Congrès, Paris,
Prentice-Hall, February 96.

[NeXT] The WebObjects Home Page,

[OMG92] Object Management Group,
Object Management Architecture Guide, Revision 2.0,
OMG Document Number 92.11.1, September 92.

[OMG93] Object Management Group,
The Common Object Request Broker: Architecture and Specification, Revision 1.2,
OMG Document Number 93.12.43, December 1993.

[OMG94] Object Management Group,
Universal Network Objects,
OMG Document Number 94.9.32, September 1994.

[ORBIX] The Orbix Home Page at IONA Technologies.

[Python] The Python Language Home Page,

[Rees95] O. Rees, N. Edwards, M. Madsen, M. Beasley, A. McClenaghan,
A Web of Distributed Objects,
Fourth International Conference on the World-Wide Web,
Boston, December 1995.

[Web*] Web* Home Page,

[Wegner90] P. Wegner,
Concepts and Paradigms of Object-Oriented Programming,
ACM OOPS Messenger, Vol 1 Number 1, Aug 1990.

About the authors

Philippe Merle graduated from the Computer Science Department of the University of Lille (LIFL) in 1992. Since 1993 he has been a postgraduate student in the LIFL, the subject of his PhD being a Generic Object-Oriented Dynamic Environment (GOODE) for cooperative applications using CORBA. He gave some courses about distributed client/server programming and CORBA at graduate and postgraduate levels. He is a member of the OSACA project, a part of the R&D program on Advanced Communication called "Ganymede" and supported by "Region Nord/Pas-de-Calais".

Christophe Gransart obtained his PhD in Computing Science from the University of Lille (LIFL) in 1995. His previous work was on BOX : A Model and a Language for Concurrent and Distributed Object-Oriented Programming. Now he is a lecturer at the University of Lille. His main areas of research are Distributed Object-Oriented Programming with CORBA, Cooperative Work and ATM. He is a member of the OSACA project.

Jean-Marc Geib is a professor in Computer Science at the University of Lille. At present he is the Director of the Computer Science Laboratory of the University of Lille, and the scientific administrator of the Objects and Actors Research Group. His main topic concerns object approach for distributed systems and parallel applications.