Providing Easier Access to Remote Objects in Client-Server Systems
Total Page：16
File Type：pdf, Size：1020Kb
Providing Easier Access to Remote Objects in Client-Server Systems Jonathan Aldrich, James Dooley, Scott Mandelsohn, and Adam Rifkin California Institute of Technology {jonal, jdooley, scott, adam}@cs.caltech.edu Abstract Many existing systems, including Java's RMI, require a The Java Environment for Distributed Invocation (JEDI) programmer to run interface code through a preprocessor is efficient, dynamic, and easier to use than alternative to create stub and skeleton objects. We have developed an communication systems for distributed Java objects. alternative system for remote method calling, offering the Existing state-of-the-art mechanisms for remote method programmer complete control over communication while calls on Java objects, such as RMI, require users to simplifying the model of distributed computing. Since our perform a complicated series of steps. Furthermore, the system uses Java's serialization capabilities, a programmer compiled static interfaces these systems use limit their can automatically send any object to a remote machine. functionality. This paper presents the design and First, we will discuss and evaluate several existing implementation of JEDI's simpler approach utilizing systems, including RPC, RMI, CORBA and IIOP, dynamic proxies. We discuss a means of integrating DCOM, and Infospheres. These systems motivate the JEDI with a publicly available CORBA ORB, followed by design and implementation of JEDI, a system that allows the tests used to ensure the robustness of the JEDI system. dynamic method invocation (the ability to call any method Comparing this system's performance with that of other of a remote object at run-time without relying on statically communication facilities such as UDP, TCP, and RMI compiled interfaces) and requires fewer development demonstrates the efficiency of JEDI. A calendar- steps than other existing systems. Then we describe how a scheduling application illustrates the flexibility and developer would use JEDI. Next, we discuss several usability tradeoffs of employing JEDI in distributed experiments in client-server computing to determine the client-server applications. flexibility, scaleability, and ease-of-use of the JEDI system. These experiments include studying the integration of JEDI with CORBA, testing the performance 1. Introduction and reliability of JEDI, and using JEDI to develop an application from scratch. We conclude with a short summary of our JEDI findings. Java programs can use the Internet for distributed computations in many different ways [8]. One such technique involves message passing [9] between objects on different machines, as exemplified by Caltech's Infospheres [4], IBM's Aglets [14], and the iBus multicast 2. Existing Systems system [16]. Another technique involves accessing remote objects through a request broker active on a remote Until recently, Java lacked a native client-server machine using CORBA [17] or DCOM [6]. Some systems method invocation paradigm [24], but several communicate with remote objects through a gateway to a supplementary systems are available to provide this Web server using HTTP and CGI [1]. Method calls on functionality. remote objects may be made using Open Network In this section, we explore and compare some of the Computing Remote Procedure Calls [29] or Java's Remote current communication mechanisms in client-server Method Invocation [12]. With each of these techniques, systems: RPC, RMI, CORBA and IIOP, DCOM, and the the programmer must deal with creating extra interfaces Infospheres Infrastructure. (often in a different language) and must do other setup work to handle low-level communication details. 2.1. ONC Remote Procedure Calls This paper explores remote method calling facilities that automatically handle some of the more cumbersome For years, programmers have used ONC's Remote communication and synchronization responsibilities [21]. Procedure Call (RPC) system [29] to automate some of 1 the communication tasks between client programs and meshes well with the top-down design techniques of their servers. Although RPC was one of the first systems procedural programming. However, the RPC system to simplify the development of distributed applications requires that the programmer tediously set up all the over the use of plain socket connections, RPC does not remote methods in the interface description file, run the handle remote procedure calls automatically. The preprocessor, and implement the resulting stub files. programmer must first design the interfaces (step 1 in figure 1) on both the client side and server side so they 2.2. Java's Remote Method Invocation will connect properly when the distributed system is invoked. The Remote Method Invocation (RMI) system furnished by Java 1.1 allows RPC-like access to remote Design objects [12]. RMI includes support for data serialization, Interface remote class loading, and socket manipulation. 1 Design Interface Create .x file Implement 2 Interface RPCGEN 3 Java generates Compiler Server Implement Client Server Implement 4 RMI Object Client Stub Stub Server Compiler Implement Client Server Client Stub generates Skeleton C/C++ C/C++ Compiler Compiler 5 Java Start Compiler 8 RMI Registry Execute 9 Client Server 6 Client Server Object Object Object Object Registration Figure 1. Although the Remote Procedure Call 10 of Remote system somewhat simplified the job of a client-server 7 Execute Objects Client system developer, it still requires running separate interface files through a preprocessor and filling in Figure 2. RMI improves the RPC-like access for the resulting stub files. remote Java objects, but adds several extra tasks for the developer. Next, the user creates a .x file (step 2) that specifies the designed interface. This file is then run through To use RMI, an application developer creates a Java rpcgen (step 3) to construct client and server stubs. The interface for the object to be accessed remotely (step 1 of programmer then fills in the client and server stubs figure 2), and then writes a server class to implement this produced by rpcgen with code that implements the interface (step 2). The Java compiler compiles the server desired behaviors (step 4). This code is then compiled for code (step 3), and the RMI preprocessor rmic uses the execution (step 5). Some consider this system to be more resulting class to create the server skeleton and client-side straightforward than standalone sockets or message stub (step 4). The client may be written and compiled any passing, because the client can invoke operations on the time after the server interface is written (steps 5 and 6). server by using what looks like a local procedure call. Before the client can access a remote object on a server Making network communications into procedure calls (step 7), the RMI registry must be run (step 8), the server 2 object must be created in a Java VM (step 9), and the Client Object server must register itself in the RMI registry (step 10). Instantiation We believe that the extra preprocessing steps introduce Object unnecessary complexity. They add several additional object files to the compilation process, and restrict the Dynamic Server Object methods that can be run on remote objects to those that Client IDL Method Stubs Skeleton Adapter are described in a static interface. If a server object is Invocation updated to include new functionality and a new interface, the client will be unable to use the new interface without Broker Request resorting to Java's somewhat awkward reflection CORBA BUS capabilities. RMI is difficult for developers to use, because it does Figure 3. Through the CORBA bus, client objects not allow client programs to use new functionality in send requests for method invocations to the remote server programs without first recompiling (and ORB, which routes the request through the object adapter and server skeleton to the server object. redistributing) the client programs or using Java's reflection to get around this static limitation of RMI. To create a Java-based client-server application in Another cumbersome aspect of RMI is its requirement that CORBA, the programmer first writes a IDL file defining programmers must use the rmic preprocessor to generate the signatures of the methods that need to be called code for the server skeletons and client stubs. RMI can remotely. The IDL file is then run through a Java use only a few wire protocols (currently TCP/IP and preprocessor which creates an interface for the server HTTP), but some applications would benefit from the use object and a stub class that will forward method calls to of custom transport protocols available through a generic that server object. Then the programmer writes the client message infrastructure. The ACE framework [25][10] and program and an object that implements the server's the iBus project [16] both provide a layered component- interface. The client and server can then be compiled and based Java communication system that allows plug-in run. custom transport protocols to provide different quality of CORBA has support for clients to discover and use service facilities to applications. interfaces dynamically through its Dynamic Invocation ObjectSpace Voyager [18] provides remote method Interface (DII) [17]. When using DII, the client creates its invocation facilities much like RMI's, but makes the method calls at run-time, rather than calling methods in development process much simpler and provides the stub. A CORBA specification for the Dynamic additional features. Developers run an existing class Skeleton Interface (DSI), allows server objects to update through the Voyager preprocessor to create a stub class their interfaces at run-time [17]. Any method invoked with all the methods the original class had. This saves through the DSI is passed through a single upcall method them the work of writing an remote interface file and (written by the programmer) that is responsible for changing their code to implement the interface. Although checking the method name and forwarding it to the correct Voyager allows dynamic method calls, it requires implementation method. developers to specify methods with the unintelligible We looked at two particular ORB implementations.