Fifth International World Wide Web Conference
May 6-10, 1996, Paris, France
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}@lifl.fr
Abstract
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.
Keywords
WWW, object orientation, CORBA, interoperability, scripting language, generic object navigator.
Introduction
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:
- a uniform naming with the Uniform Resource Locators (URL),
- persistent objects implemented via http daemons and their host file systems,
- an invocation meta-protocol through HyperText Transfert Protocol (HTTP)
[Berns96] and a set of basic operations (GET, POST, ...), and
- extensibility via the Common Gateway Interface protocol
[McCool].
These authors point out some lessons about WWW that can increase the OOOS impacts:
- a single uniform user interface to access all objects, (CorbaWeb aims at that), and
- simple scripting languages to incorporate new applications.
We will see that CorbaScript permits one to access any service implemented by CORBA objects.
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:
- The 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.
- The Uniform Resource Locators to access objects and to apply operations on them.
- The HyperText Markup Language to present the object state and
Graphical User Interfaces on objects.
- CGI in Web servers as a gateway between the Web and SIS objects.
From a technological point of view, our work concerns the integration between the Web and CORBA:
- The description of Web services using object-oriented technologies. Services are implemented in the most appropriate language (see CORBA section). They are accessible through a standard Web browser or through a specific CORBA client application.
- From the Web, the access to any Information System developed with CORBA even if this IS was not designed for WWW.
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:
- 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 adaptors to accommodate a diverse range of object features such as
lifetime and granularity policies.
- A reflexive environment: CORBA provides at runtime objects to retrieve IDL information
(Interface Repository).
It facilitates dynamic type checking and allows the construction of requests through the
Dynamic Invocation Interface.
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):
- With the standard WWW technology, any WWW browser acts as a
graphical user interface to browse and to invoke CORBA objects
represented both by HTML anchors to access objects
and by HTML Forms to invoke operations on them.
- The CorbaWeb environment interprets the user's requirements
by invoking objects.
It is composed of many CGI scripts.
They are written in the language CorbaScript.
They invoke objects and generate HTML documents to show request results.
- The language CorbaScript is a new language permitting one to write scripts
which invoke dynamically objects.
This language contains constructions to manage variables,
to control execution flows, to catch exceptions and to invoke objects.
- The CorbaWeb interpreter is an interpreter of the language CorbaScript.
It translates CGI parameters into CorbaScript variables.
- The CORBA environment supports the heterogeneous distributed
object-oriented system and the dynamic invocation mechanism (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 named meta scripts.
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 :
- The
echo
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 which displays the object (cf View Meta Script).
- The assignment instruction (
:=
) sets 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 then
instructions1
[ else
instructions2
] end
Instructions1 are executed if condition is true.
Else instructions2 are executed.
- The condititional loop construction:
loop_construction ::= while
condition do
instructions
end
Instructions are executed while condition is true.
- The exception management construction handles raised CORBA exceptions:
block_construction ::= try
instructions1
[ catch
exception
instructions2
]*
[ catchany
instructions3 ]
end
This construction executes instructions1.
If an exception is raised by one operation of instructions1 then
instructions2 are executed.
Several exception types can be caught, 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 (e.g.
instructions2,instructions3) 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 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:
- any basic value like integer, float, character or string,
- a set of CorbaScript values like
(10, 'a', "hello")
,
- the result of an operation invocation on an object,
- any CORBA typed value composed of an IDL type and a set of values,
- any expression with standard operators
(
+, or, <=
, ...),
- a variable (e.g.
$computer
), and
- a CORBA object reference.
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'.
end
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
end
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 :
- a null value then the script generates HTML Forms (cf Fig.3)
to use the service,
- is_prime value then it invokes the is_prime_number
operation of the $computer object,
- prime_numbers value then it invokes the prime_numbers
operation of the $computer object, or
- 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"
try
execute ($QUERY_STRING)
catchany
echo "Exception raised: " , $EXCEPTION
end
echo "</BODY>\n</HTML>\n"
else
# generates HTML Form for user's input
end
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:
- Distant invocations are supported by the meta script Exec.
- HTML Forms representing IDL object interfaces are automatically generated
by the meta script Interface.
- The meta script View allows the generation of HTML or MIME documents
representing the state of any object.
- And in the near future, VRML documents could be generated by a VRML meta script
to navigate in 3D objects.
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 integration done by AnsaWeb appears at two levels.
First, HTTP is substituted by IIOP protocol [Rees95].
Second, the IDL language is used to specify
external Web services (CGI)[Edwards95].
Authors automatically generate stubs and forms for CGI programs from IDL specifications.
- Work on Web*[Web*] defines a model
to access CORBA objects by a standard Web browser.
The gateway is realized by writing layout pages i.e. HTML documents
containing scripts to apply operations on CORBA objects.
Scripts are written with an extension of the Tcl language
(TclDII [Jagannathan94])
which allows the dynamic invocation of operations on objects .
But in TclDII, the user has to precisely define the IDL type of each parameter
so this tool is hard to use for a non IDL-CORBA expert.
- WebObjects[NeXT] allows the structuration of Web CGI applications
thanks to objects. CGI aspects and HTML generation are encapsulated in WebObjects instances.
A Web application is composed of:
- HTML templates structuring page layout and referencing WebObjects,
- Declaration files maintaining WebObjects states and associating scripts to HTML Form actions, and
- Script files defining actions executed according to user requests.
An interface between WebObjects and CORBA is under work.
- The Apache+Python+ILU approach allows the access to ILU objects
[ILU] via standard browsers.
A framework based on Python [Python] is used inside the Apache server [Apache] to design new services.
This integration increases service execution performances avoiding CGI process forking.
WWW server is defined by an ISL interface.
This permits to specific ILU client applications to access ILU objects managed by this server.
With the ILU requester [Everitt96], they plan to develop a support to dynamically discover objects like the CorbaWeb meta script View.
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.
Conclusion
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.
Bibliography
[Apache]
The Apache Home Page,
<URL:http://www.apache.org>
[Berns95]
T. Berners-Lee and D.W. Connolly,
Hypertext Markup Language - 2.0,
Internet Network Working Group RFC 1866, MIT/W3C,
November 1995.
<URL:ftp://ds.internic.net/rfc/rfc1866.txt>
[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.
<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-http-v10-spec-05.txt>
[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.
<URL:ftp://sigops.informatik.uni-kl.de/sigops/papers/S.Postscript.Black>
[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.
<URL:http://www.ansa.co.uk/ANSA/ISF/1464/1464prt1.html>
[Everitt96]
Paul Everitt,
The ILU Requester: Objects Services in HTTP Servers,
W3C Informational Draft 07-Mar-96,
<URL:http://www.w3.org/pub/WWW/TR/WD-ilu-requestor>
[ILU]
Inter-Language Unification -- ILU
<URL:ftp://ftp.parc.xerox.com/pub/ilu/ilu.html>
[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.
<URL:http://www.w3.org/pub/Conferences/WWW4/Papers2/141/>
[Jagannathan94]
G. Alamsi, A. Suvaiala, C. Goina, C. Cascaval, V. "Juggy" Jagannathan,
TclDii: A TCL Interface to the Orbix Dynamic Invocation Interface,
TR, 1994.
<URL:http://www.cerc.wvu.edu/dice/iss/TclDii/TclDiiDoc.ps>
[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,
<URL:http://hoohoo.ncsa.uiuc.edu/cgi/overview.html>
[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.
<URL:http://www.lifl.fr/~merle/papers/TOOLS96.ps.gz>
[NeXT]
The WebObjects Home Page,
<URL:http://www.next.com/WebObjects/>
[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.
<URL:ftp://ftp.omg.org/pub/docs/1993/93-12-43.ps>
[OMG94]
Object Management Group,
Universal Network Objects,
OMG Document Number 94.9.32, September 1994.
<URL:ftp://ftp.omg.org/pub/docs/1994/94-09-32.ps>
[ORBIX]
The Orbix Home Page at IONA Technologies.
<URL:http://www.iona.ie>
[Python]
The Python Language Home Page,
<URL:http://www.python.org>
[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.
<URL:http://www.w3.org/pub/Conferences/WWW4/Papers/85/>
[Web*]
Web* Home Page,
<URL:http://webstar.cerc.wvu.edu>
[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.