Using CORBA for Internet-Based Workgroup Applications

John Caspers(*) and Anton Eliëns(**)

(*)University of Amsterdam

(caspers@wins.uva.nl)

(**)Vrije Universiteit Amsterdam

(eliens@cs.vu.nl)

slide: Using CORBA for Internet-Based Workgroup Applications

abstract

The OMG Common Object Request Broker Architecture (CORBA) offers a promising platform for employing distributed object technology in a language-independent manner. To gain experience with this technology, we developed a small-scale Internet-based workgroup application employing distributed objects.

This experience has led us to the identification of a number of limitations and practical problems that may hinder the widespread adoption of this technology.

slide: Abstract

Introduction

The Object Management Group, Inc. (OMG) is an international organization supported by over 500 members, including information system vendors, software developers and users, and promotes object-oriented technology in software development. The Object Management Architecture (OMA) provides the conceptual infrastructure upon which all OMG specifications are based [OMG92]. The Common Object Request Broker Architecture and Specification (CORBA) specifies how objects interoperate and which support implementations must provide to be CORBA-compliant [OMG95]. Such implementations, commonly called Object Request Brokers or ORBs, make it possible to use objects stored in one or more object servers from within multiple clients in a heterogeneous network environment.

The languages server and client are written in depend on the language mappings supported by the ORBs used. To be called CORBA-compliant, an ORB should at least support one language binding, which can be C, C++ or Smalltalk. Interoperability between different ORBs is also an separate compliance point, and CORBA 2.0 specifies how ORBs can work together using the General Inter-ORB Prototol. The Internet Inter-ORB Protocol (IIOP) is used to interconnect ORBs via TCP/IP. See [CORBA] for a brief tutorial on CORBA.

In this project, we used ORBeline from PostModern Computing [POM96], a CORBA 2.0-compliant ORB which supports the C and C++ language bindings, as well as the IIOP protocol.

CORBA and Java

After the introduction of the object-oriented language Java on the Internet, several vendors Computing} have adapted their ORB to include Java support. This makes it possible to implement an Internet-based CORBA connection that is initiated via a World-Wide Web page. The server is accessed by a Java applet running on the client, without the need for separate software or licenses at the client side.

PostModern Computing released a Java language mapping called Black Widow [POM96a], which can be used to access a server written in ORBeline or another ORB from within Java-enabled Internet browsers such as Netscape. The Java mapping however, is at the time of writing not yet specified by OMG and developers should not expect their current CORBA-enabled Java applications to be portable until after the Java mapping has been specified.

Using CORBA

CORBA has been proposed as a technology enabling objects to communicate seamlessly over a network, regardless of language or operating system. Our experience with developing a small set of Internet workgroup tools has led to the observation of a number of limitations inherent to the CORBA architecture, affecting design, development and deployment of distributed object-oriented software.

Structure

The structure of this paper is as follows: section 2 gives an explanation of the architecture we used for the workgroup system. Sections 3 and 4 detail the limitations we experienced. In section 5, we present a summary and our conclusions.

Implementing a Simple Workgroup Application

The goal of the project was to develop a prototype for an Internet-based workgroup architecture using CORBA technology. CORBA provides a means for developing distributed object applications, while Internet provides a standard and widely accessible network infrastructure. Users should not need special client software to use the system, other than a Java-enabled browser such as Netscape.

Architecture of the Implementation

The implementation is kept very simple with respect to collaborative computing and consists of several distributed object types, interrelated as shown in Figure 1 (using the OMT notation). The most important notion of our system is the agent, which we define as a representative of a user that can perform simple operations on the user's behalf, such as sending messages to and making appointments with other agents.

Each user participating is represented by a personal agent, which has an agenda and a message queue. Each agenda consists of several appointments. A workgroup has a membership list consisting of zero or more agents present in the system. An Agent can be a member of zero or more workgroups.

Possible operations on agents are sending messages to and making appointments with other agents, subscribing to a workgroup, making an appointment with a workgroup or sending a message to all workgroup members.

Figure 1: Object Model

slide: Object Model

All interaction of the user with the system is done via Java applets, which combine a graphical user interface with Internet access and CORBA functionality. The server is implemented in C++. We used PostModern's CORBA 2.0-compliant product ORBeline to implement the server and BlackWidow from the same vendor to implement the Java clients. The server can run on most UNIX platforms, as well as on Windows NT, while the Java applets, running on top of a Java Virtual Machine, can theoretically run on every platform that Java supports. In addition, a C++ browser/monitor was developed that can be used to interrogate agents and workgroups and to monitor message flows.

The server is running as a daemon on one or more servers. ORBeline allows clients to transparently connect to multiple servers running on servers in the same subnet, and even has limited support for object replication and fault tolerance.

The Java client applets are first transferred to the client by the HTTP server using a web page and then contact the object server through IIOP, the Internet Inter-ORB Protocol. The client applets run in Netscape or HotJava and contain the CORBA client communications software as well as the client application code. The object server can reside on a different machine than the Web server and is running an IIOP gatekeeper, for instance on {\sc tcp} port 15000, that is part of the ORB. All further communication is done through this gatekeeper.

Availability of objects

The most important limitations we experienced concern the availability of objects in a CORBA environment. Conceptually, it would be desireable that an Agent object could reside anywhere on the network, not only on a server but also on the user's workstation. This enables a user with different working locations or with a mobile computer to keep the agent nearby and make appointments and read messages while travelling or at home. Figure 2 illustrates this concept.

Figure 2: A conceptual architecture where agents physically reside on the clients

slide: Architecture

We found this concept hard to realize in a CORBA environment due to the asymmetric architecture of clients and servers, as explained in the next section.

CORBA Clients and Servers

In CORBA, a clear distinction is made between clients and servers. The server contains the implementation of objects which can be accessed by clients. A server requires an ORB to be present at the same host, while a client contains only the basic code to communicate with servers through this ORB. A server can also act as a client and invoke methods on objects residing on other servers. It is however not possible to activate methods of objects residing on clients. If a system wants to make objects on clients available to other processes, the clients should be configured as servers too, creating a peer-to-peer architecture. This is undesirable due to the overhead involved with running an ORB; also, licensing could cause problems. Incorporation of ORB functionality within the operating system might be a solution for this problem in the future. The following sections explain in more detail the problems we experienced.

Dynamic Object Creation

When the server is running, CORBA clients can start creating objects and invoking methods on these objects. The creation of objects is always performed on the server and cannot be done directly by the client, e.g. using new. A typical solution is to define an object factory on the server, which can be activated by the client to generate objects dynamically. The drawback of this solution is that for every nontrivial object class X, a method such as {\tt create_X} must be defined in the IDL definition of the factory interface\footnote{The IDL compiler generates a static method {\tt _factory()} for each class, but this method only works for the default constructor.}.

Accessing objects

When objects are created on the server, they are available for the client through proxy objects. For each interface X, the IDL compiler generates several types at the client side: the proxy class X, a pointer typedef {\tt X_ptr}\footnote{Although the CORBA 2.0 specification does not require {\tt X_ptr} to be defined as a pointer typedef.} and an object reference class {\tt X_var}, comparable to a C++ ``smart pointer''.\footnote{A smart pointer is an object that can be used as a pointer but may provide additonal checks and facilities for initialization.} After object creation, the server returns an {\tt X_ptr} to the client using a network stream.

Figure 3 shows the class inheritance hierarchy corresponding to an IDL interface for X. The IDL compiler generates a client proxy class with the same name as the interface. This class is used directly by the client applications. The member functions of X first marshal the function's parameters for a client object Xc to a network stream and then invoke the method on the corresponding server object Xs. Figure 3 also shows the server-side skeleton class {\tt _sk_X} and implementation class {\tt X_imp}.\footnote{The name {\tt _sk_X} is generated by ORBeline, the name {\tt X_imp} is chosen by the programmer.} The skeleton class embeds the ORB-related functionality needed to communicate with the object. The implementation class must be defined by the system developer.

Figure 3: The class tree of an IDL-defined interface

slide: Interfaces

Figure 4 details the objects present in the client and server processes, where Xs is the server object (on the right) and Xc the corresponding client proxy (on the left). Xc is an instance of the client proxu X and Xs is an instance of the server class {\tt X_imp}.

When a client creates an instance of X, the object reference to Xs as returned from the server is actually the address of Xc. It is however not possible to pass an object reference (the address of Xc) from the client back to the server. Since Xc refers to a proxy object locally at the client, the server cannot handle this memory location. This is partly inherent to the CORBA architecture, where clients cannot act as servers while servers can act as clients.

Figure 4: The object in the client (left) and server processes

slide: Processes

A possible workaround is to let the client use a nickname or a global object id provided for each CORBA object. The global object id is generated automatically for each object but is big (typically over 100 bytes) and provides little if any user-understandable information about the object. A nickname forces the programmer to implement a custom directory service for the system at the server side and make this service available through an IDL interface.

The Naming Service, part of Common Object Service Specification I (COSS I, [OMG94]), provides a hierarchical name-to-object association which makes it easier for the client to find objects on servers. Still a client cannot pass an object reference back to the server, however.

Callbacks at the Client Side

Because a server does not have access to client objects, it is not possible to have a server call a client object method, for instance as a callback. This makes it difficult to notify clients of changes in server objects, for instance needed for screen updates. An extension to IDL allowing client callbacks was realized in the commercial toolkit DOME [OOT96].

The Event Service, which is part of COSS I, allows objects to communicate asynchronously using events, but only for server objects.

Allowing client callbacks is further complicated by the fact that clients may already have an event loop, for example to dispatch window events. Adding callback capability to clients requires either the use of multiple threads or to merge these event loops.

Other Limitations of CORBA Implementations

In addition to the problems related to the creation and access of objects, we may note several problems of a more pragmatic nature.

Support for Non-CORBA Objects

All server objects available for clients are advertised in either IDL definitions or in an object registry. Objects from existing libraries or applications can only be made available if they are rewritten using CORBA conventions (with their interface advertised in IDL), or if CORBA object wrappers are written around them. Distribution as an orthogonal property for objects is not supported in the current version of CORBA. Partial solutions to this problem have been presented [RW96], but only address copying objects as a bytestream over the network, requiring their implementation to be present at both sides of the connection.

Mobile objects

As noted before, CORBA assumes a rather static distribution of client and server objects over the network. However, as in our application, there is a need for 'mobile objects' as well.

With the introduction of Java on the Internet, several vendors have extended their ORB implementations with a proprietary IDL-to-Java mapping. For the prototype, we used PostModern's Black Widow, which can be used to write CORBA clients as well as servers. Until an IDL-to-Java mapping has been standardized by the OMG, Java servers or clients are not likely to be portable between the existing proprietary implementations.

In a CORBA environment, Java applets are used as easy-transportable frontends. Java's concept of ``mobile code'' is only exploited during the initial phase of sending the client applet to the client computer using the HTTP protocol. When the Java client is running, it behaves like any other standalone CORBA client.

Compatibility of Generated Source Code

The interface definition for the network objects is defined in {\sc idl}, from which an {\sc idl} compiler (part of the ORB implementation) generates stubs (or proxies) and skeletons in the implementation language. The IDL compiler generates a ready-to-use stub on the client side and a skeleton on the server side. The skeleton is used by the programmer to implement the actual objects, usually by deriving a new class from the skeleton class. At {\sc idl} level, all ORBs conforming to the CORBA specification are compatible.

The skeleton definitions however, are in most cases vendor-specific. For instance, the skeleton class for an IDL-defined interface Agent is called AgentBOAImpl in Orbix and {\tt _sk_Agent} in Orbeline; the methods defined in the classes are also different, as are the generated source file names. This affects the definition of the derived implementation class, making CORBA server software less portable among ORBs. Especially large software systems would suffer portability problems.

Since the client is independent of the ORB used for the server implementation vice versa, it would be possible to write a prototype using distributed Smallltalk objects and rewrite the final implementation in C++, without affecting the clients.

Summary and conclusions

During the development of a simple workgroup application using CORBA, we experienced a number of limitations inherent to the CORBA architecture. This prevented the conceptual architecture of Figure 2 to be implemented efficiently.

The most important problem we faced was the distinction between clients and servers, where distributed objects can only reside on a server. If a client wants to make its objects available to other programs, it should be configured as a server as well, with an ORB running on the same host. This causes problems regarding overhead and licensing and is not a feasible situation for mass distribution of Java clients over the Internet, for instance. The same architecture limitation prevents servers from notifying clients using callbacks.

This feature makes it impossible for clients to pass distributed object references back to the server, forcing them to work with other identification mechanisms such as object ids or human-readable strings.

Other minor problems we observed concern the lack of support for existing non-CORBA objects in a distributed environment. Possible solutions are converting existing classes to CORBA and making their interface available through IDL, or to write CORBA object wrappers around these objects. The Java mapping should be used with caution until an OMG specification is published. Finally, not all parts of a CORBA system are compatible among ORBs at the source-code level.
In conclusion, CORBA allows for the development of flexible client-server systems and in that sense fullfills its promise of being a language- and platform-independent architecture. Not all systems can be built easily with CORBA, however. The design of a distributed object application should reflect the limitations of the CORBA architecture.

A possible future incorporation of an Object Request Broker within desktop operating systems might be a solution to allow clients to make objects available to others, perhaps in a limited fashion.

In addition, given the growing dominance of the Web as a client access point for a variety applications, the ability to access CORBA objects from within Java applets opens up an instant world-wide market for distributed object applications.