Remote Database Access in the Distributed Computing Environment

Transcription

1 SOFTWARE PRACTICE AND EXPERIENCE, VOL. 24(4), (APRIL 1994) Remote Database Access in the Distributed Computing Environment johnny wong and william marshall Department of Computer Science, 225 Computer Science Building, Iowa State University, Ames, IA 50011, U.S.A. ( {wong, marshall} cs.iastate.edu) and robert goodman IBM Rochester, Rochester, MN 55901, U.S.A. ( rgoodman rchland.vnet.ibm.com) SUMMARY This paper describes the design, implementation and testing of a set of software modules that are used for remote database access in a distributed computing environment. The goal of our research and development is to implement a client server model using Structured Query Language (SQL) functions in the Open Software Foundation s (OSF) distributed computing environment (DCE). This design is compared with another which simply uses the sockets application programming interface (API), running over the transmission control protocol/internet protocol (TCP/IP), and is implemented in subroutines that act similar to the remote procedure call (RPC) generated stub code. The prototypes for the remote SQL access project are implemented using an IBM RISC System/6000 (the client) running the AIX operating system and an IBM AS/400 (the server) running the OS/400 operating system. We selected the AS/400 for its database abilities, and the RISC System/6000 since the DCE software is available for it. key words: Distributed computing Structured query language Communication Database INTRODUCTION This paper describes the design and implementation of a client server model between a host database machine and a Unix client that wishes to access the host s database using the OSF DCE. Another version of the program uses the sockets API. The prototypes are implemented using an IBM RISC System/6000 (the client) running the AIX operating system and an IBM AS/400 (the server) running the OS/400 operating system. We selected the AS/400 for its database abilities, and the RISC System/6000 since the OSF DCE software is available for it. A brief introduction is given to the concepts of client server computing. An overview of DCE and SQL is then presented. Based on the availability of such software modules, remote database access using DCE RPC and using the sockets API are designed and implemented. Evaluations and comparisons of the different designs and implementations are shown. We found that software development for CCC /94/ Received 29 January by John Wiley & Sons, Ltd. Revised 23 November 1993

2 422 j. wong and r. goodman distributed computing using OSF DCE is simpler and more efficient than using the sockets API. This is due to the integrated services for distributed computing provided by OSF DCE. Finally, an example of how remote database access could be used is presented. CLIENT SERVER MODEL The client server model divides distributed computing functions into two parts: the client side and the server side. The client is an entity that requests a service and receives the result or benefit. The server is an entity that offers services. 1 A service is a set of functions that manage a certain type of resources on behalf of the client requests. An example is a client asking a print server to print a file. The terms client and server are relative. In fact, a machine can, and often is, a client for one task, while being a server for another task at the same time. Clients may deal with many servers to finish a task. Servers are specialized and run a task constantly, waiting for client requests. To ensure flexibility and usability of a distributed system, the distributed operating system should be completely transparent to the user. In the client server model, server transparency refers to the invisibility of the server location. System organization is trivial for interactions between a single client and server, but incremental growth and reliability concerns require multi-server-per-request structures. Using a pool of identical servers, any server is capable of handling the same set of operations. The client broadcasts its request to all servers of the pool. The servers can then start an internal cooperation protocol to determine which server should handle the request. A standard way of achieving fault tolerance in distributed computing is by using replicated servers. Normally, all requests are addressed to a primary server, but in the presence of a fault one of the secondary servers will be elected to handle incoming requests. Cooperation protocols exist to enforce data consistency and service resiliency. A service manager can be used to accept requests from clients and assign them to servers. When a server is ready to handle requests, it informs the service manager. A client sends its request to the service manager who identifies an appropriate server to handle this type of request. It sends the request to the server and waits for an answer. The server accepts the request, processes it and sends the response back to the service manager. The service manager forwards the answer to the client. The advantages of using a service manager are 1 1. The client s code remains independent of the number of servers involved. 2. The server s code remains independent of the number of other participating servers. 3. Specific code written to provide increased performance or fault-tolerance is encapsulated within the service manager. Ideally, the coordination algorithms are not part of the client s and server s code. As such, clients and servers are unaware of nonfunctional aspects of the service they are contributing to. This again has the advantage that changes to the quality of service (e.g. degree of fault-tolerance) do not require coding changes in the clients and servers involved. The service manager is only conceptual, since many performance and reliability

3 remote database access 423 problems exist in its implementation. If there is only one central service manager, this may become a performance bottleneck and a single point of failure. In a distributed system, we strive to avoid centralized control structure to retain the benefits of distributed computing. DCE OVERVIEW The distributed computing environment (DCE) from the Open Systems Foundation (OSF) is a set of services that supports the creation, use, and maintenance of distributed applications in a heterogeneous environment. DCE is designed to bring a common set of interfaces to any operating system and hardware combination that will easily allow a system of clients and servers to use the strengths and minimize the weaknesses of the different architectures. 2 Why distributed computing? By placing machines on a network, computing resources are able to work together. Machines and people that used to work alone now see the need to share equipment and files. Specialized equipment such as laser printers does not need to be duplicated. In many cases a distributed system of small computers may be more cost effective, robust and flexible than a few large computers. Unfortunately, with these new features come potential problems. Multiple copies of data must be consistent and clocks on different systems need to be synchronized. These and other issues of this type must be addressed by a system that provides distributed computing support. Why DCE? Given the reasons for and challenges in distributed computing, why should DCE be used in a particular distributed computing system? (a) DCE provides interoperability and portability across heterogeneous platforms. (b) DCE provides tools and services that support distributed applications. (c) DCE s set of service is integrated and comprehensive. (d) DCE provides global interoperability with computing environments outside of DCE. DCE s architecture allows different hardware or operating systems to communicate. DCE applications are portable to any platform that supports DCE. Tools such as RPC interact with directory and security services to provide a highlevel interface for developing applications. The tools supplied by DCE all work together to provide a coherent set of utilities for using and operating a distributed system. Many DCE services are distributed applications themselves. Services are included that address many new problems found in distributed systems such as data consistency and clock synchronization. DCE tools also interact with existing standards such as X.500 and the domain name service, allowing DCE applications to interoperate with non-dce applications. Some of the potential uses of DCE include distributed system management for heterogeneous systems and various client/server applications.

4 424 j. wong and r. goodman Functional architecture of DCE The distributed computing environment provides a layer between the operating system and distributed applications. 2 A diagram of the architecture is shown in Figure 1. Overview of DCE technology components In this section we provide a function overview of the DCE components and give a high-level overview of the operations. DCE provides support for threads if it does not already exist in the operating system. However, to function well, thread support needs to be integrated into the operating system. Traditional programs execute sequentially. Better performance can be obtained when the program can be structured so that it can be executed concurrently. Threads allow multiple flows of control within a single process, so that overall performance is improved. The remote procedure call (RPC) mechanism is the foundation of communication between client and server within the DCE environment. The DCE RPC is comprised of the interface definition language and its associated compiler, the network data representation, and the run-time library. The cell directory service is used to maintain local copies of information, such as a database of users, hosts and server locations. An application can query the directory server when it needs information. The distributed time service (DTS) keeps the system clocks on different hosts synchronized. It provides a way of keeping a host s time close to the correct time, Figure 1. DCE architecture

5 remote database access 425 the coordinated universal time (UTC), by querying several time servers and calculating an average time from the responses. The DCE security service (SS) ensures secure communications and controlled access to resources in the distributed environment. The DCE SS consists of several components that provide for user authentication, secure communication, authorized access to resources, and proper enforcement of security policy. The global directory service (GDS) implements the international standard directory service based on the X.500 standard. It provides a global namespace that connects the local DCE cells into a world-wide hierarchy, connecting cells in different organizations. The distributed file systems (DFS) is based on the Andrew file system (AFS) and provides location transparency of the file. This allows users to access files stored anywhere in the network. File access is based on the file name. The file can be shared by different users from different machines. STANDARD SQL STATEMENTS Database queries on the AS/400 are specified using Structured Query Language (SQL). ANSI SQL has been implemented on many different systems for database use. 3 Basic SQL statements 1. SELECT performs a query to extract records from a table. 2. INSERT adds a new record into a table. 3. DELETE deletes every record of a file which an expression is true. 4. UPDATE updates the values of specified fields in certain records of a table. 5. CREATE TABLE creates a new table. 6. CREATE COLLECTION creates a new library for storing SQL tables, indexes and other objects. Embedded SQL statements Many common programming languages on the AS/400, including RPG, COBOL, Pascal and C, support embedded SQL statements. For example, an update statement looks like: EXEC SQL EXECUTE IMMEDIATE UPDATE CATALOG SET QUANTITY = :qty WHERE ITEM = :item; The statement will set the quantity field to the value of the :qty variable when the item field is equal to the :item variable. The host language variables are preceded by colons and are used exactly like SQL constants. A select statement is coded in a similar manner. There are two types of SQL statements, static and dynamic. Static SQL statements

6 426 j. wong and r. goodman are hard coded into the program, and some processing can be done at compile time. Dynamic SQL statements are generated as the program runs. Therefore, nothing is known about them until run time. In the prototype, all SQL statements are executed dynamically. REMOTE SQL ACCESS USING DCE RPC Background The challenge is to implement the SQL client server code using DCE. The RISC System/6000 implementation of OSF DCE is more stable due to the Unix background of the DCE system. The code for the AS/400 is still in the prototype phase and very little testing has been done on it. If an error occurs, it is often tedious to track the problems since there is little error checking in the DCE RPC implementation. On the AS/400 it is difficult to determine if the errors are in the user code or in the RPC implementation. Figure 2 is a flowchart showing how an RPC application is built. 2 The user supplies the client application, the server application and an interface definition language (IDL) file which contains type definitions and a description of each RPC routine and its parameters. IDL is a high-level descriptive language whose syntax resembles that of ANSI C. 4 Different modules from an IDL file are shown in Figures 4 6. It will be discussed in detail later. To create a distributed application from the parts, the first step is to run the IDL compiler on the IDL file. The compiler generates a client stub, server stub and a header file. The header file contains the type definitions from the IDL file and prototypes for the RPC routines. The client stub links with the client application to Figure 2. DCE RPC programming process

7 remote database access 427 Figure 3. Modules used for DCE between Unix and the AS/400 form the client executable. The server stub and the server application also link together to form the server executable. At run time, the client stub procedures look exactly like the remote procedures the client wants to call. It intercepts the calls to the server and marshals the parameters onto the network. On the server side, the server takes the parameters off the network and passes them to the actual routines. After the procedure ends, the parameters are returned in the same manner. Architecture of the DCE prototype The design of this program (Figure 3) is made modular due to the simple concept of RPCs in general. If this program is not executed remotely, the sql client routine can be linked directly with the sql manager routine. The IDL file for the remote SQL is quite straightforward. Part of the IDL file are shown in Figures 4 6. The IDL file defines common structures and the input and output parameters. The interface header (Figure 4) is generated automatically. Each program contains a unique universal identifier (UUID). A UUID is a hexadecimal number that contains information that makes it different from all other UUIDs. To ensure this, the UUID contains a time stamp from the creation and the identifier of the host of origin. 4 The header also contains the version number, any global configurations and the name on the RPC interface. Next in the IDL (Figure 5) are the global definitions. This is a superset of the C language typedefs. There are many more typedefs in the final prototype, but the Figure 4. The interface definition language (IDL) header

8 428 j. wong and r. goodman Figure 5. Typedef of the sqlda structure Figure 6. Description of the parameters that are passed to the Do select routine

9 remote database access 429 only part that requires special attention is the sqlvar structure within the sqlda type structure, so it is included in the Figure. In the line [size is(sqln),length is(sqln)] struct sqlvar the size is construct allows for variable length structures to be passed. It instructs the compiler to generate the code necessary to handle variable length structures. The variable sqln holds the total number of sqlvars in the structure. By using this variable, the length of the whole structure can be determined. The final part of the IDL file (Figure 6) contains prototypes for all remote functions. The line [in,out,ptr] sqlda type **dp, tells the IDL compiler that **dp, a handle (pointer) of type sqlda type will be passed into and out of the Do Select routine. Parameters can be declared as being passed in one direction only as well as being bidirectional. Pointers can be passed between client and server, but when a pointer is used, the IDL compiler needs to be able to determine the size of the structure at run time to pass the actual memory that it points to. Implementation The server code (sql server) is standard code for most DCE programs, with only minor variations for initialization purposes. The server registers itself with the cell directory server and then listens for connections on the port. When a connection arrives, the server hands the request to the appropriate manager routine. On the AS/400, manager routines (sql manager) are written in C with embedded SQL. These consist of a few basic functions which are able to handle almost any SQL statement that can be interactively executed. The following is a list of functions that are implemented by using remote procedure call facilities: Do Select Do Fetch Do Exec Do Update Do Delete Do Close Do Select accepts an SQL select statement. The first step for the server is to prepare the dynamic SQL statement. Then the SQL DESCRIBE command creates a table that describes the layout of the returned records in the data area. Next a cursor is created and the query is opened. After a Do Select has been performed, Do Fetch can be called to return a record. Do Fetch returns one record from the currently open cursor in the SQL data area. The Do Exec procedure is used to execute any SQL command that does not require any special input and returns a success or failure value. Examples include INSERT, CREATE TABLE, CREATE COLLECTION, CREATE VIEW and DROP VIEW. The Do Exec procedure prepares the dynamic SQL statement and then executes it.

10 430 j. wong and r. goodman The Do Update procedure implements a special case of the standard SQL update command. After calling Do Select and Do Fetch to reach a desired record, Do Update is called to update that specific record. The actual SQL command that executed is update tablename set fieldname = value The procedure can add the WHERE CURRENT OF cursor clause so that it will update only the current record. Updates on the entire file are handled through the Do Exec procedure. Do Delete is another special case. It is used to delete the record that the cursor is currently on. The only parameter specifies the currently open table name. Deletion of a range of records meeting a certain criterion can be handled through the Do Exec procedure. Do Close closes the open cursor and frees allocated data areas. Testing the prototype To prototype the design, a simple menu routine (sql client) has been created to interface with the user. This menu is number driven and presents an interface to the RPC routines. For each routine, a menu option prompts for the queries and other SQL statements. The menu is designed for testing purposes to compile on both the RISC System/6000 and the AS/400. During the first part of testing on the AS/400 the menu interfaces to the actual manager routines that execute the SQL code. This demonstrates that the SQL manager executes correctly and the menu asks for the correct items and passes them to the manager correctly. The next step isolates the menu from the manager routines using DCE RPC. On the RISC System/6000, the IDL file for the Do * procedures is compiled using the IDL compiler. (Parts of the IDL file are shown in Figures 4 6). To demonstrate that the IDL file is syntactically precise and the correct parameters are being passed between the client and server using DCE RPC, dummy routines are used to modify variables and print status messages. These cases specifically test the variable length record structure and examine what happens when the manager routines change pointers to point to different places or allocate memory. Initially, the menu and the dummy routines are linked together to test the code without the RPC. The client and server are then run a separate processes using the DCE RPC to connect them. The routines demonstrate that the correct parameters are passed and the IDL file is correctly defined. After testing the program carefully, the server is started on the AS/400 and registered with the cell directory server (CDS). The client on the RISC System/6000 uses the CDS to find the database server and then establishes a connection to the server. Using the menu, query results from the AS/400 display on the RISC System/6000. REMOTE SQL ACCESS USING SOCKETS API The previously mentioned testing shows that the parts are working. To compare remote database access using only a simple transport mechanism, the basic func-

11 remote database access 431 tionality of the RPC has been implemented using a socket programming interface. 6 Since the current client and server modules work well, the support routines are designed to link with the current modules, adding socket functions without changing the basic modules. Only minor modifications to the client code are required to initiate the socket connection. The server code requires no changes. Architecture of the socket prototype The design and implementation of the remote database access module using sockets API is shown in Figure 7. Five routines provide the basics for socket client and server. To create a basic interface to the operating system, the cci lo routines are used. The cci lo routines compile on the AS/400 and RISC System/6000 and provide a consistent, high-level interface to socket APIs to read and write blocks of data. On the RISC System/6000, cci lo interfaces directly to sockets APIs in the AIX operating system. On the AS/400, socket interaction must be in Pascal, so cci assist provides a minimal interface between cci lo and OS/400 TCP/IP calls. Interfacing between the cci lo routines and the original client, the tcp client code accepts the calls from sql client to the Do * routines. It converts any necessary data structures and sends the parameters to the database server using cci lo. For most of the data structures that were used in this example, the RISC System/6000 and the AS/400 have the same data representation for integers and the SQL structures. Routines were used to convert strings from EBCDIC to ASCII and back. All data conversion was done on the RISC System/6000. On the server side, the server (sql server) establishes a TCP port to read commands from, and then waits for the client. Upon receiving a command, the server calls the appropriate routine in the manager (sql manager). After the database function ends, the server sends the data back to the client. The client and manager routines for the TCP socket prototype use the same code as the DCE implementation. EVALUATION In the prototypes, the sockets API and DCE RPC provide almost the same functionality, but in a fully functional DCE system there are many features that are not available using a simple TCP/IP transport mechanism. Figure 7. Remote SQL using TCP sockets

12 432 j. wong and r. goodman DCE RPC evaluation DCE RPC is fairly easy to set up. The IDL files are powerful, yet simple. There is a significant delay as the RPC autobinding process takes place for the first RPC call. However, for any subsequent calls, the location information is cached. Hence the delay for subsequent calls is much shorter than the original delay. Sockets API evaluation The prototype is based on the current implementation of TCP/IP on the AS/400. TCP/IP is written in Pascal, so our C programs interface with Pascal code residing above the TCP layer. The socket programming interface needs to be directly addressable from AS/400 C. Comparison DCE RPC is designed to shield the programmer from the details of the network and differences between client and server architectures. DCE allows client server applications to be quickly developed for different platforms. DCE s name services provide naming and location transparency. The TCP prototype has the host name and port hard-coded. In DCE, it is possible to use the cell directory servers and autobinding features to locate the server automatically. The database server can be relocated without any coding changes to the application programs since the server registers itself with the cell directory service. Every time a DCE service starts it registers its current location with the cell directory service. DCE also provides data conversion, which has been coded into the TCP version. Basic data types are defined in the IDL file. This conversion handles converting strings from EBCDIC to ASCII. DCE supports the following basic data types and sizes. 4 (a) integer, hyper, long, short, and small (b) floating-point, float and double (c) char, unsigned (d) boolean, 8 bits (e) byte, 8 bits no conversion. DCE also provides several constructed data types such as structures and unions. When passing parameters of these types between machines of different architectures and byte ordering, DCE handles the conversions, except for data types defined as byte. Any object defined as type byte is protected from data conversion. The authenticated remote procedure call enables distributed applications to participate in authenticated network communications. Applications may select the authentication protocol and the authorization protocol to be used, and set various protocolindependent protection levels for communication with remote principals (users, servers and computers). 4 Authenticated RPC is designed to provide secure communications without requiring additional work on the part of the programmer. Security in a distributed environment depends on local security and network security. When local security is breached, the network is not secure either. DCE security handles two main questions: 1. Is the principal the one who it claims to be? (Authentication).

13 remote database access Does it have the right to do what it is requesting? (Authorization). Kerberos 5 7 is used to provide a trusted central authority that grants permission to principals. To provide secure network transmissions, DCE provides the ability to encrypt all network communications. Another advantage of using OSF DCE is that changes in the location of the server do not require code changes in the clients and servers involved. This is because when a server is ready to handle requests, it will inform the cell directory server of its location. This allows the server to be located in the least used machine. EXAMPLE Database access using DCE could be useful in a project to bring high-tech to the classroom. A catalog database is needed to allow the user to browse through only those courseware modules of interest. A courseware module can be anything from a single text file to an executable multimedia program with numerous data files. This project involves the efficient retrieval of courseware modules from remote sites. The multimedia information delivery system (MIDS) is a menu-driven or graphical user interface (GUI) package that allows the user to query a database server that stores the description and location of courseware files. Queries could be sent to the server via remote procedure calls. The server would execute the queries and then return the summary information about the courseware module. If the user is interested in a particular courseware module the system can then retrieve the desired modules without the user having to know the details of the transport mechanism. To allow the MIDS modules to be independent of each other, DCE RPC could be used to query the database server for the location of the courseware package. Since DCE is supported on many platforms, the client and servers can easily run on different hardware. The databases would be located using the cell directory services, allowing flexibility at each site and reducing the need for the client to know the exact location of the servers. When the user requests a module, the database server would return the location of the module. The cell directory services would provide flexibility in storing the modules. It could be accessible across the distributed file system, or it could be retrieved by forwarding the request to another cell. CONCLUSION DCE helps ease the development of distributed applications. The DCE library functions as supplied by OSF need to do more run-time error checking to check the parameters supplied by the user code. Currently, these routines do not have error handling, and frequently crash on bad input. The performance issue is under investigation. Many basic concepts in DCE, such as threads and a distributed, hierarchical file system, will enhance the performance of the prototype. On a multiprocessor machine, threads will increase the server performance. A hierarchical file system can improve the performance of finding a file. acknowledgements The authors are grateful for all the ideas, help and code from Al Currit of IBM Rochester; Sunil Gaitonde and his department at IBM Rochester for the DCE RPC

14 434 j. wong and r. goodman prototype on the AS/400. The systems support people, Kevin McGuire at IBM and Dave Buckley, Gary Lee and Chris McCoy at Iowa State University, helped make changes to the systems and installed software for the project. David Martin Jr. at Iowa State University provided assistance with La T EX questions. This work is supported by the IBM Corporation under agreement number disclaimer This paper may contain examples of code and names of companies. This code is given for presentation purposes and has not been tested by IBM. Therefore, IBM cannot guarantee its reliability in a customer s environment and the code is provided AS IS. IBM EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE WARRANTIES OF FITNESS FOR PARTICULAR PURPOSE AND MERCHANTABILITY. Any names appearing in this paper are designed to be fictitious and IBM makes no representation as to the accuracy of the names or data presented in accordance therewith. trademarks AIX, AS/400, OS/400 and RISC System/6000 are trademarks of the IBM Corporation in the United States or other countries or both. IBM is a registered trademark of International Business Machines Corporation. AFS is a trademark of the Transarc Corporation. OSF is a trademark of Open Software Foundation, Inc. UNIX is a trademark of UNIX System Laboratories, Inc. in the U.S. and other countries. REFERENCES 1. Jürgen Nehmer and Friedemann Mattern, Framework for the organization of cooperative services in distributed client-server systems, Journal of Computer Communications, 15(4), (1992). 2. Open Software Foundation, 11 Cambridge Center, Cambridge, MA 02142, U.S.A. Introduction to DCE, 31 December Jeffrey D. Ullman, Principles of Database and Knowledge-Base Systems, Volume 1: Classical Database Systems, Computer Science Press, 1803 Research Boulevard Rockville, Maryland 20850, U.S.A., Open Software Foundation, 11 Cambridge Center, Cambridge, MA 02142, U.S.A. OSF DCE Version 1.0 DCE Application Development Guide, 31 December Jennifer G. Steiner, Clifford Neumann and Jeffrey I. Schiller, Kerberos: an authentication service for open network systems, Proc Winter USENIX Conference, Dallas, Texas, W. Richard Stevens, UNIX Network Programming, Prentice-Hall, Englewood Cliffs, New Jersey 07632, U.S.A., G. W. Treese, Berkeley UNIX on 1000 workstations: Athena changes to 4.3BSD, Proc Winter USENIX Conference, Dallas, Texas, 1988, pp