100 104. 2] Gosling, J., and McGilton, H. The Java. Language Environment: a White Paper. Tech- nical report, Sun Microsystems Inc., 7550 Garcia. Avenue, Mountain View, CA 94043 U.S.A., Oct. ... The Fifth International World Wide Web Con-.
How to Make Corba Objects User-Friendly with a Generic Object-Oriented Dynamic Environment? Philippe Merle Laboratoire d'Informatique Fondamentale de Lille - URA CNRS 369 Université des Sciences et Technologies de Lille Bâtiment M3, 59655 Villeneuve d'Ascq Cedex - France Tél.: (33) 20 43 47 21 - Fax: (33) 20 43 65 66 E-mails: merle@li .fr
Abstract The future of distributed client/server computing will consist of the WWW and Corba environments. First, the WWW is the user-friendly uniform interface to access any distributed resource. Second, Corba is a single uniform object-oriented view of distributed and heterogeneous systems integration. Then these two worlds need to merge to make distributed objects user-friendly. This paper rst presents Corba and our Generic Object-Oriented Dynamic Environment, second it discusses the interests of the integration between the WWW and Corba worlds, and nally presents CorbaWeb as an integration tool between the WWW and Corba worlds.
Keywords: Corba objects, Generic Object-
Oriented Dynamic Environment, Scripting Language, Objects in the World Wide Web.
1 From Corba to Goode The Object Management Group's Common Object Request Broker Architecture (CORBA) [8] is a standardized distributed object-oriented infrastructure to support components interoperability, portability and reusability. Currently, several Corba implementations are available and could interoperate. Many major industrial projects target to use Corba to develop their next information systems. The Motorola's project IRIDIUM is a large distributed information system modelizing telecommunications satellites as a set of Corba objects. Boeing plans
to redesign its manufacturing information system on the Iona's Corba implementation Orbix. Moreover, some USA government organizations keep watch on Corba to build their future interoperable information systems. In all these examples, Corba seems to be the long-term choice of the distributed computing infrastructure. Corba is a key technology to provide application interoperability and integration. Each component or object is described by an interface, a set of operations and attributes, written with the Interface De nition Language (IDL). An IDL description is compiled to produce a stub code for client programs and a skeleton code for server objects. IDL can be mapped to dierent programming languages, currently C, C++, Smalltalk, Java, Ada95 and a lot more in the future. Thus, an object communicates with others via requests transported by the Object Request Broker (ORB). The Orb isolates client programs from server objects. Besides client programs and server objects are isolated from the Orb via respectively IDL stubs and IDL skeletons. With this static approach, a client program which wants to communicate with hundred dierent object types needs to include the hundred appropriate IDL stub codes at compilation time. Now, let us imagine a general object browser application: this tool permits users to inspect any object. But at compilation time the browser designer cannot know all millions of object types which will be browsed at runtime. For this kind of application, Corba includes two powerful tools: the Interface Repository and the Dynamic Invocation Interface. The IR is a set of Corba
objects containing IDL information. At runtime, these objects can be inspected to discover IDL descriptions. This inspection provides information about other object interfaces. This information is used to dynamically construct requests via the DII mechanism. Currently, these Corba dynamic tools are complex to exploit by a developer. The Generic Object-Oriented Dynamic Environment (GOODE) project [5] aims at providing new user-friendly tools and methodologies to help developers to build these "generic applications". We are developing two tools based on this approach: CorbaScript, a scripting language to invoke any OMG-IDL operation on any Corba object, and CorbaWeb a generic gateway between WWW server side and Corba which allows users to invoke operations on Corba objects from standard Web browsers.
2 Goode and CorbaScript In the future, a CORBA compliant environment will support several million objects structured by several thousand object interfaces. These interfaces will form hundreds of frameworks: GUI, naming service, trader service, nancial service are framework examples. Each framework could be implemented by servers suited to the required quality-of-services needs (e.g. persistent, faulttolerant, multi-threaded objects). But user's application design will become very complex because these applications have to know all object types they will use. To avoid this complexity, we have studied a generic approach to the creation of very useful kinds of client object-oriented applications, e.g. shell interpreters, browsers, and so on. We argue that a powerful object environment requires generic tools to con gure, administrate, test and browse object frameworks. These tools must not be statically linked to a set of object types, but they have to dynamically adapt to their object environment. They have to use any object types at runtime but may not know any such types at compilation time.
Testing software components: In
client/server application development, programmers must write some pieces of code to check the validity and correctness of their components. These testing codes are obsolete when components are completely implemented. A generic tool like a shell interpreter is a time-saving tool. It is possible to test immediately and interactively pieces of object implementations during development. Con guration and administration: Many objects (services, frameworks) need to have client programs to con gure them. The number of client programs is often due to the number of services provided by the object type. Generally, these clients are designed using static approach (i.e. using clients stubs). We propose to use an interpreted scripting language to allow server application tuning. Thus, all these clients can be written with few script instructions.
"Glue" between software components: A generic approach can be used
to associate independent existing software components to create some new components. The de nition of a new component merges the functionnalities of the connected components. Moreover, these new glued components can be used from standard Corba applications as classical objects. In this way, we investigate the use of the advanced dynamic invocation mechanism provided by CORBA: our applications adapt to objects and interfaces dynamically at runtime using the Interface Repository and build requests with the Dynamic Invocation Interface.
2.2 CorbaScript
All current operating systems, such as Unix, include a shell interpreter to control and manage resources (e.g. applications, les and users). The number of dierent kinds of resources is often limited by the OS and is not extensible. The shell interpreter is designed to know only 2.1 Usefulness of a Generic Ap- these kinds of resources. Batch or interactive scripts permit users to launch programs, to maproach nipulate les and to construct command chainSuch tools based on a generic approach can be ing through, for instance, the Unix pipe mechaused for: nism.
A parallel can be made with a shell for a Corba environment which would be used to invoke operations on objects. This tool could not know all possible object types at compilation time, thus it is a generic application. As the rst Goode tool, Corba resources are managed and controled by the CorbaScript shell one. As described before, testing, managing, administrating and con guring any Corba object framework are supported by this uniform interactive tool. CorbaScript is an interpreted scripting language to apply any operation on any Corba object. The following main keys are provided:
an interactive scripting language: Cor-
baScript is an interactive shell tool to operate on any Corba object. Users write scripts to perform actions on them. A script is a set of instructions such as displaying a value, calling an operation, aecting a variable, controlling ow statements and managing exceptions. dynamic typing: Each CorbaScript value is an object on which users can apply operations, read or write attributes. These actions are checked on the y to verify their validities. Integers, doubles, booleans, characters, strings, arrays are the primitive value types. procedural and modular: Scripts can be stored into modules and the import instruction loads them. A module can contain variables and procedures. A procedure is a sequence of instructions and can have untyped parameters. Then, modules are reusable components. object-oriented: Users' scripts manipulate local values and any distant Corba objects. In this way, a script only acts as a client program. Another major CorbaScript feature is the possibility of designing Corba objects via script classes. Then local Corba objects can be instanciated and can be invoked by distant Corba objects. extensibility: Scripts, modules and classes are the main reusable components acting as a "software glue" between distributed Corba objects. Furthermore, CorbaScript is designed as an extensible framework to provide a powerful integration tool.
Critical or particular tasks can be supported by adding procedures and new types implemented by C/C++ codes. These codes are directly accessible from users' scripts. From the implementation point of view, Corba objects are dynamically invoked through the Dynamic Invocation Interface. The CorbaScript interpreter hides the complexity of this API. It translates scripts into dynamic invocations. Invocations are checked thanks to the object interface signatures, described in IDL and retrieved from the Interface Repository. Local Corba objects are supported by the Dynamic Skeleton Interface [9]. We have implemented a prototype of the DSI on Orbix 2.0 [3] because currently it does not include it. The next implementation step is to port CorbaScript on other Corba environments: rst to improve its portability, second to connect it with a standard Interface Repository 2.0, and nally to avoid the problems in the Orbix DII implementation 1 . The CorbaScript interpreter is a powerful tool to invoke operations on objects but it needs users program scripts. As the second Goode tool, we present CorbaWeb allowing the user to interact with Corba objects by the way of a Web browser. But before introducing this tool, the next section discusses the ways of integrating objects in the World Wide Web.
3 WWW and Corba The World Wide Web is a large scale system to access distributed resources mainly made up of hypermedia documents e.g. HTML pages and the MIME format, and executable programs stored on http servers e.g. search services. Programs can be either executed on the server machine using the Common Gateway Interface (CGI) protocol [4] or executed on the client side with, for instance, Java applets or Netscape HTML/LiveScripts. 1 When putting an IDL structure into an Any value, the Orbix Orb calls a function generated in the static stubs for this IDL structure. This implies that stubs must be linked into generic applications!
3.1 Integrating Non Standard Resources
resources can be implemented by Corba objects. This integration requires to extend standard servers via the CGI protocol or by other speci c server APIs. Nevertheless, two kinds of gateways can be considered: Static gateways are speci c Corba programs which call object operations via precompiled IDL client stubs. But this looks like standard gateway programming and requires speci c developments for each object type. When a new object type is added, a new gateway must be developed. Generic gateways allow WWW clients to access, display and invoke any Corba object. This enables one to navigate over Corba objects as easily as users navigate over the Web. Furthermore, invoking operations on objects can be done in the same way. A generic gateway cannot know all object types at compilation time. Object types are dynamicallydiscovered via the Interface Repository, or any other type managers. Objects are dynamically invoked through the Dynamic Invocation Interface. Both static and generic gateways may automatically generate HTML form pages from IDL interfaces. A WWW client can navigate through Corba object links using dynamically generated URLs for each object. Also, a parallel can be made between a set of objects and an hypertext-linked set of resources. Hyperlinks can be useful to generalize distributed object composition and dependence links, whereas URLs provide a uniform naming of objects. Both URLs and hyperlinks are pragmatic and well-known technologies to retrieve, access and navigate over objects. The 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.
Currently, to access an external non standard resource from a WWW server, the solution is to develop a set of programs which act as a gateway between the resource and the server. In that way, the major drawback of those programs is that they are speci cally written to perform computations on server data or to provide access to resources such as databases. If a resource does not have such a gateway program, it is inaccessible from browsers. The challenge is to make available a plethora of new services without developing these speci c softwares for each of them. As an exciting idea, Andrew Black and Jonathan Walpole have pointed out several features of http servers that make them close to Object-Oriented Operating Systems (OOOS) [1]: a uniform naming of distributed resources via URLs, persistent objects stored in server host le systems, a meta-protocol HTTP with a set of basic operations to invoke resources and extensibility through the CGI protocol. But WWW lacks a uniform resource model and will truly become an OOOS when millions of services will be transparently incorporated into it. Moreover WWW users want many extensions: changing HTTP protocol, integrating new kinds of Web resources, extending Web browsers. This problem can be overcome thanks to a uniform model of resource interface, and mobile portable front-ends, that could be generically integrated in the WWW. Thus we submit that objects can encompass all kinds of WWW resources within a single paradigm. Objects should be dynamically available to clients as soon as they are created. Legacy objects should be easily plugged in without any modi cation. The Corba object-oriented approach oers good properties to encapsulate and structure Web components under the same paradigm. It brings modularity, exibility and abstraction A uniform communicating protocol: to needed features encountered into the WWW. Communication between networked interoperable objects is supported by the Corba Internet Inter-Orb Protocol (IIOP) [9]. When 3.2 Objects in the WWW Corba objects will implement non standard There are several dierent solutions to integrate Web resources, IIOP will become a new the WWW and Corba worlds: WWW protocol with its own URL format (iiop://objectref.operation(parameters)). In the Objects on the WWW server side: By in- future, IIOP may replace HTTP to access any troducing Corba on the server side, new WWW distributed Web object.
Objects on the WWW browser side: side and a Corba 2.0 environment. This enables Object-oriented programming allows one to design reusable applets [2]. An applet is a portable mobile code executed on the Web browser side and stored in Web servers. The following scenarios can be imagined thanks to the concept of mobile code: Evolutive Web browsers, such as HotJava, will be built as a set of objects. New protocols and functionalities can be dynamically downloaded from the network and plugged in it. Applets can invoke Corba objects located in the Web server side via previous gateways or with the IIOP. These applets are GUI front-ends to remote objects and allow operation invocations. Applets can access user's desktop environment modelized by local Corba objects, e.g. the graphical user interface Fresco and desktop applications. Applets can instanciate Corba objects in the user environment. These objects can be noti ed by distant Corba objects. Asynchronous noti cation can be supported to prevent users from server modi cations. Communication between users' applets will be supported by networked Corba objects. This allows one to support internet groupware applications. Whatever the technologies chosen, the future Web infrastructure will contain the following concepts: a set of universal protocols to access any distributed Web object, a universal mobile code interpreter to execute applets in clients and to send mobile agents from clients to servers and nally a universal object model to support Web objects. In the next section, we present our work on the integration between the WWW and Corba worlds [7]. This work targets to explore the issues of objects and generic gateways on the Web server side.
to navigate over and invoke operations on Corba objects as easily as users navigate over the Web. It is usable from any browser and it is based on http server extensions through the CGI protocol. The browser manages the user interactivity and sends users' actions to the server. The CorbaWeb environment receives users' actions and executes operations on Corba objects. Thanks to CorbaWeb, a WWW client can navigate through Corba object links using dynamically generated URLs for each object. HTML forms are automatically generated from IDL interfaces allowing operation invocations on any Corba object. The object states are displayed by Web representations, for instance HTML documents, and are generated by speci c viewing scripts.
4.2 Architecture
The CorbaWeb architecture (cf. Figure 1) is composed of the following parts: The standard Web environment where any Web browser acts as a uniform graphical user-friendly interface to browse and to invoke operations on Corba objects. A Web server extension through CGI: Currently, an http server communicates with CorbaWeb via the standard CGI protocol. An alternative solution is to use a more speci c server API: for instance, linking the CorbaWeb environment into the server program. A set of meta scripts allows one to specify the basic gateway functionalities (e.g. invocation, navigation and representation) and provides extensibility for the CorbaWeb environment. CorbaWeb repositories: The Web representation of objects is generated by speci c viewing scripts retrieved from the CorbaWeb Representation Repository. In the future, we plan to develop new meta scripts associated with their own meta data repositories. A CorbaScript interpreter: CorbaScript is our interpreted scripting lan4.1 Overview guage to invoke IDL operations on any The CorbaWeb environment [6] aims at providCorba object. All CorbaWeb scripts are ing a generic gateway between the Web server written in this language.
4 CorbaWeb
Any WWW Client
Any WWW Client
... HTTP protocol
Any WWW Server
Multimedia Document Repository
meta scripts
CGI
CorbaScript Interpreter
O.R.B.
CorbaWeb Environment CorbaWeb Representation Repository
Future Meta Data Repositories
specific viewing scripts
D.I.I.
Corba Bus
Any Corba Services & Facilities
Interface Repository
Standard Corba Environment
...
Any Object Server
Any Application Objects
Figure 1: CorbaWeb Architecture
Any Object Server
A standard Corba environment: Ob- of this interface. It generates a form for each opjects are dynamically invoked through the Dynamic Invocation Interface: Invocations are checked thanks to the object IDL signatures retrieved from the Interface Repository. Any application objects: CorbaWeb is the generic gateway providing Web accesses to any application object. These objects only need to be described by IDL interfaces and could be implemented with any programming language or any system support.
4.3 Meta Scripts
Any Object-Oriented Operating System contains a set of meta operations such as invocation or object creation. In CorbaWeb, these meta operations are described by meta scripts. Each meta script implements a meta operation on Corba objects. We have de ned the following meta scripts: the Exec one executes one operation on one object, the Interface one automatically generates Graphical User Interfaces (i.e. HTML Forms) from IDL interfaces and the View one generates an HTML representation of the object state (via scripts stored in the CorbaWeb Representation Repository).
4.3.1 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. This executed script can raise exceptions and the meta script is able to catch them and signal it to the Web user. 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 de ned operation on any object type.
4.3.2 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
eration or attribute. When an operation takes parameters, it generates HTML input text elds or other widgets.
4.3.3 View Meta Script
The previous meta scripts de ne 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' pro les. We de ne a pro le as a kind of user such as a physician's pro le or a receptionist's pro le. A view script is associated to each couple of an object type and a pro le. These scripts are composed of CorbaScript instructions which generate an HTML document representing the object state. They are stored into the CorbaWeb Representation Repository. Thus, the view meta script takes two parameters: an object reference and a pro le. It retrieves from the CorbaWeb Repository the appropriate view script according to the object type and the pro le. 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. Note that the navigation across structured information is achieved by anchors. These anchors are URLs dynamically generated referring to the view meta script.
4.4 Perspectives
CorbaWeb allows WWW clients to access, display and invoke any Corba object, so new WWW resources could be implemented by Corba objects. New meta scripts can be designed to extend the CorbaWeb environment. For instance in the near future, VRML documents could be generated by a VRML meta script to navigate in 3D objects. Currently, the CorbaWeb environment has been implemented on SUN Sparc station with IONA Orbix 2.0, a commercial Corba implementation. CorbaWeb is experimentally used to access the medical information of the Hospital Center of Lille. Nevertheless, research eorts have to be made on object noti cations to synchronize WWW clients with object modi cations. Another perspective under construction is a general model of user access control on distributed objects.
The aim is to provide end-to-end security, from [7] Merle, P., Gransart, C., and Geib, J.-M. Future Trends for a Global Object Web. In WWW to distributed objects.
Joint W3C/OMG Workshop on Distributed Objects and Mobile Code, Boston, Massachusetts, June 2425, 1996 (June 1996), OMG/W3C. [8] OMG. The Common Object Request Broker : Architecture and Speci cation. OMG TC DocThe World Wide Web becomes an Objectument 93-12-43, Object Management Group, Oriented Operating System thanks to the Headquaters, 492 Old Connecticut Path, Framgeneric gateway CorbaWeb allowing the WWW ingham, MA 01701, USA, Dec. 1993. world to access the Corba world. The generic WWW uniform interface enables not only to [9] OMG. Universal Networked Objects. OMG TC Document 94-9-32, Object Management Group, navigate on distributed objects, but also to perHeadquaters, 492 Old Connecticut Path, Framform actions on them. By interfacing WWW ingham, MA 01701, USA, Sept. 1994. servers with ORB middleware layer and by us-
5 Conclusion
ing IDL descriptions and dynamic invocations, object invocations can be performed transparently from any browser. Our Generic Object-Oriented Dynamic Environment may open new opportunities for a very broad range of generic applications. This paper demonstrates that Corba objects can become user-friendly thanks to the Goode tools, CorbaScript and CorbaWeb.
References
[1] Black, A. P., and Walpole, J. Objects to the rescue! or httpd: the next generation operating system. In Proceedings of the 6th ACM-SIGOPS European Workshop (Sept. 1994), ACM Press, pp. 100104. [2] Gosling, J., and McGilton, H. The Java Language Environment: a White Paper. Technical report, Sun Microsystems Inc., 7550 Garcia Avenue, Mountain View, CA 94043 U.S.A., Oct. 1995. . [3] IONA Technologies Ltd. Orbix 2: Programming Guide and Reference Guide, 2.0 ed. 8-34 Percy Place, Dublin 4, Ireland, Nov. 1995. [4] McCool, R. The Common Gateway Interface. NCSA, 1995. . [5] Merle, P., Gransart, C., and Geib, J.M. CorbaScript and CorbaWeb: A Generic Object-Oriented Dynamic Environment upon CORBA. In Proceedings of TOOLS Europe'96 (Feb. 1996), Prentice-Hall. [6] Merle, P., Gransart, C., and Geib, J.-M. CorbaWeb: A Generic Object Navigator. In The Fifth International World Wide Web Conference, Paris, France, May 610, 1996 (May 1996).
