Programming in Java

1. Programming in Java RMI 蔡文能 交通大學資訊工程學系 tsaiwn@csie.nctu.edu.tw http://www.csie.nctu.edu.tw/~tsaiwn/java/

2. Agenda • RMI Introduction • RPC vs. RMI • Remote Procedure Call • Remote Method invocation • RPC example • RMI Architecture • Client stub and Server skeleton • RMI Deployment and RMI registry • RMI Example • From function to Distributed computing • DLL, RPC/RMI, CORBA, Web Services

5. RMI Introduction • RMI enables the programmer to create distributed Java applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. • A Java program can make a call on a remote object once it obtains a reference to the remote object, either by looking up the remote object in the naming service provided by RMI or by receiving the reference as an argument or a return value. A client can call a remote object in a server, and that server can also be a client of other remote objects. • RMI uses object serialization to marshal and unmarshal parameters.

6. Serialization • Action of encoding of an object into a stream of bytes • RMI performs marshalling/unmarshalling via Java Serialization • Marshalling is the process of encoding arguments and results for transmission • Thus, objects to be marshalled or unmarshalled must be serializable ( should implements java.io.serializable)

7. RMI Overview • Remote Method Invocation • Java version of RPC network Object Client Remote Object Server method invocation ha.nctu.edu.tw hehe.nctu.edu.tw

8. Remote Procedure Call (RPC) Client Server blah, blah, blah bar = foo(a,b); blah, blah, blah RPC int foo(int x, int y ) { if (x>100) return(y-2); else if (x>10) return(y-x); else return(x+y); } protocol

9. Why RPC/RMI Calling a function/method at a remote server: • Advanced form of communication • Sockets and MPI: data transfer • RPC/RMI: control transfer • Transparency in function calls • No distinguish between local and remote calls (in theoretical) • Also applied to IPC on the same machine • Ease of use • Compiled-time argument type checking • Automatic stub generation IPC : Inter-Process Communication

10. Applications RPC, RMI, and events Middleware Request reply protocol layers eXternal Data Representation(XDR) Operating System Middleware Layers 分層負責, 分工合作

11. RPC – Remote Procedure Call • There are a number of popular RPC specifications. • Sun RPC is widely used. • NFS (Network File System) is RPC based. • RPC clients are processes that call remote procedures. • RPC servers are processes that include procedure(s) that can be called by clients. • Rich set of support tools. • The RPC Library is a collection of tools for automating the creation of RPC clients and servers.

12. Sun RPC • RPCGEN command • There is a tool for automating the creation of RPC clients and servers. • The program rpcgendoes most of the work for you. This rpcgen is usually knows as RPC compiler. • The input to rpcgen is a protocol definition in the form of a list of remote procedures and parameter types.

13. RPCGEN Protocol Description Input File foo.xx rpcgen % rpcgen –C foo.xx Client Stubs Server skeleton header file XDR filters foo_clnt.c foo_xdr.c foo.h foo_svc.c C Source Code

14. RPC Programming • RPC Library • XDR routines • RPC run time library • call rpc service • register with portmapper • dispatch incoming request to correct procedure • Program Generator • rpcgen

15. RPC Run-time Library • High- and Low-level functions that can be used by clients and servers. • High-level functions provide simple access to RPC services. • For client: int callrpc( . . . ) • For server: int registerrpc( . . . ) • svc_run()is a dispatcher on server • A dispatcher waits for incoming connections and invokes the appropriate function to handle each incoming request.

16. Procedure Arguments • To reduce the complexity of the interface specification, Sun RPC includes support for a single argument to a remote procedure.* • Typically the single argument is a structure that contains a number of values. * Newer versions can handle multiple args.

17. Procedure Identification • Each procedure is identified by: • Hostname (IP Address) • Program Identifier (32 bit integer) • Procedure Identifier (32 bit integer) • Program Version identifier • for testing and migration.

18. Program Identifiers • Each remote program has a unique ID. • Sun divided up the IDs: 0x00000000 - 0x1fffffff 0x20000000 - 0x3fffffff 0x40000000 - 0x5fffffff 0x60000000 - 0xffffffff Sun SysAdmin Transient Reserved

19. Procedure Identifiers &Program Version Numbers • Procedure Identifiers usually start at 1 and are numbered sequentially • Version Numbers typically start at 1 and are numbered sequentially.

20. Iterative Server • Sun RPC specifies that at most one remote procedure within a program can be invoked at any given time. • If a 2nd procedure is called, the call blocks until the 1st procedure has completed. • Having an iterative server is useful for applications that may share data among procedures. • Example: database - to avoid insert/delete/modify collisions. • We can provide concurrency when necessary...

21. RPC example (1/7) • This program shows you how to use a server program, a client program and an interface definition file to let the client program call the functions in the server program and get the results. • Files: • ①test_proc.c --- the server file • ②test_client.c --- the client file • ③test.xx --- the Interface Definition file of RPC • Files generated by rpcgen: rpcgen –C test.xx • test_clnt.c • test_svc.c • test.h

22. RPC example (2/7) • File test_proc.c (1/1) for server side #include "test.h" int *addd_1_svc(int *argp, struct svc_req *rqstp) { static int result; result = *argp + 1; return (&result); } int *decc_1_svc(int *argp, struct svc_req *rqstp) { static int result; result = *argp - 1; return (&result); }

23. RPC example (3/7) • File test_client.c (1/3) for client side #include "test.h" /* test_client.c , page1 */ voidtest_prog_1(char *host) { CLIENT *clnt; int *result_1; int addd_1_arg; int *result_2; int decc_1_arg; #ifndefDEBUG clnt = clnt_create(host, TEST_PROG, TEST_VERS, "netpath"); if (clnt == (CLIENT *) NULL) /* NULL is 0 */ { clnt_pcreateerror(host); exit(1); } /* to be continued */

24. RPC example (4/7) • File test_client.c (2/3) for client side #endif/* DEBUG */ /* test_client.c , page2 */ scanf ("%d",&addd_1_arg); scanf ("%d",&decc_1_arg); result_1 = addd_1(&addd_1_arg, clnt); if (result_1 == (int *) NULL) { clnt_perror(clnt, "call failed"); } result_2 = decc_1(&decc_1_arg, clnt); if (result_2 == (int *) NULL) { clnt_perror(clnt, "call failed"); } printf ("addd_1_result = %d\n",*result_1); printf ("decc_1_result = %d\n",*result_2); #ifndefDEBUG clnt_destroy(clnt); #endif/* DEBUG */ } /* test_prog_1 *//* to be continued */

25. RPC example (5/7) • File test_client.c (3/3) for client side /* test_client.c , page3 */ main(int argc, char *argv[]) { char *host; if (argc < 2) /* no host name given */ { printf("usage: %s server_host\n", argv[0]); exit(1); } host = argv[1]; test_prog_1(host); }

26. RPC example (6/7) • File : test.xx rpcgen –C test.xx program TEST_PROG { version TEST_VERS { int ADDD(int)=1; int DECC(int)=2; }=1; }=0x31234567;

27. RPC example (7/7) • Use rpcgen , C compiler, and Linking/loader • By rpcgentest.xx, you can get test_clnt.c, test_svc.c and test.h. • Compile/link on the client gcc -o test test_client.ctest_clnt.c-lnsl • Compile/link/run on the server(ccsun2.csie.nctu.edu.tw) gcc -o test_svc test_svc.ctest_proc.c -lrpcsvc-lnsl ./test_svc& • Run clien program on the client ./test ccsun2.csie.nctu.edu.tw Demo on Sun machines

28. rpcgen –C test.xx

29. Test RPC -- Server Side

30. Test RPC -- Client Side 輸入兩列: 57 89 把第一個數加 1, 把第二個數減一

31. const MAX = 1000; typedef int FileIdentifier; typedef int FilePointer; typedef int Length; struct Data { int length; char buffer[MAX]; }; struct writeargs { FileIdentifier f; FilePointer position; Data data; }; Another example of rpcgen file struct readargs { FileIdentifier f; FilePointer position; Length length; }; program FILEREADWRITE { version VERSION { void WRITE(writeargs)=1; Data READ(readargs)=2; 2 }=2; } = 9999;

32. High-Level Library Limitation • The High-Level RPC library calls support UDP only (no TCP). • You must use lower-level RPC library functions if you want to use TCP. • The High-Level library calls do not support any kind of authentication.

33. Low-level RPC Library • Full control over all IPC options • TCP & UDP • Timeout values • Asynchronous procedure calls • Multi-tasking Servers • Broadcasting IPC : Inter-Process Communication

34. The General RMI Architecture • The server must first bind its name to the registry • The client lookup the server name in the registry to establish remote references. • The Stub serializing the parameters to skeleton, the skeleton (框架) invoking the remote method and serializing the result back to the client stub (存根).

35. The Stub (存根) and Skeleton (框架) • A client invokes a remote method, the call is first forwarded to stub. • The stub is responsible for sending the remote call over to the server-side skeleton • The stub opening a socket to the remote server, marshaling the object parameters and forwarding the data stream to the skeleton. • A skeleton contains a method that receives the remote calls, unmarshals the parameters, and invokes the actual remote object implementation. • Java RMI is NOT an all-purpose ORB architecture like CORBA

36. Stub • Stub (存根; 客戶端代理) • Client side • Acts as an implementation of a remote interface • Communicates with the real object over the network • The stub class is generated from corresponding remote class by the RMI compiler rmic Note: As of the J2SE 5.0 release, stub classes for remote objects no longer need to be pregenerated using the rmic stub compiler, unless the remote object needs to support clients running in pre-5.0 VMs.

37. skeleton • Skeleton (框架; 服務端代理) • Server side • Carries on a conversation with the stub; • Reads the parameters for the method call from the link • Call the real remote service • Writes the return value from the service back to the stub Note: Before J2SE 5.0 (i.e., JDK 1.4 and older version, rmicis required to generate the skeleton ???_Skel.class And ???_Stub.class for client (Where ??? Is your server Class name)

38. RMI (in Java) “Flat” directory structure which attempts to provide some notion of location transparency-- client code uses a single name to find a server Client Code Implement “Factories” using declarative descriptions of activatable objects Naming Service Activation Daemon Client Stub network Server Skeleton JVM Asociated to Activation Group One JVM per ActivationGroup. Automatically launched by Activation daemon and contains (potentially) many small scale, semi-independent servers which can share resources (like connection pools) and which live under the same security restrictions Server Object

39. Java Interfaces • Similar to Class • No implementation! All methods are abstract (virtual function for C++ ). • Everything is public. • No constructor • an Interface is an API that can be implemented by a Class. • In Java a class can only extend a single superclass (single inheritence). But a Java class can implement any number of interfaces.

40. Serializable interface • In Java a class can only extend a single superclass (single inheritence). • A class can implement any number of interfaces. • end result is very similar to multiple inheritence. • A class is Serializable if it implements the interface Serializable. A Serializable class is one whose instances can be marshaled (turned into a linear sequence of bits). Serializable objects can be transmitted from one computer to another, as well as be stored into a file.

41. Java RMI classes • Java.rmi.Remote • Interface supporting remote objects • java.rmi.server.UnicastRemoteObject • Continuously running server • java.rmi.activation.Activatable • Server started by rmid daemon • java.rmi.Naming • Lookup: Returns stub given a name • Java.rmi.registry.Registry , LocateRegistry • java.rmi.RMISecurityManager • Validates rights to access downloaded object

42. Client App. Server App. Stubs Skeleton Remote Reference Remote Reference Transport Transport RMI Adds a few layers to TCP/IP

43. Remote reference layer • Defines and supports the invocation semantics of the RMI connection • Provides a RemoteRef object that represents the link to the remote service implementation object • The stub objects use the invoke( ) method in RemoteRef to forward the method call

44. Transport layer • Provides basic connectivity • makes the connection between JVMs • Based on TCP/IP connections between machines in a network • The network works are done by the client stub and the server Skelton.

45. Finding Remote Objects • It would be awkward if we needed to include a hostname, port and protocol with every remote method invocation. • RMI provides a Naming Service through the RMI Registry that simplifies how programs specify the location of remote objects. • This naming service is a JDK utility called rmiregistry that runs at a well known address (by default).

46. Find Servers using Naming Service • Simple interface to registry • Implemented via 5 static methods on an object: public static String[] list(String name) public static Remotelookup(String name) public static void bind(String name, Remote obj) public static void rebind(String name, Remote obj) public static void unbind(String name)

47. java.rmi.Naming

48. java.rmi.registry.LocateRegistry

49. java.rmi.registry.Registry

50. Steps for Developing an RMI System 1. Define the remote interface extends java.rmi.Remote that declares the methods that will be available remotely. 2. Develop the remote server class by implementing the remote interface. The server program must create a remote object and register it with the namingservice. 3. Develop the client program. 4. Compile the Java source files. 5. Use rmic to Generate the client stubs and server skeletons. 6. Start the RMI registry. 7. Start the remote server objects. 8. Run the client