Distributed Systems Architecture

Transcription

1 Distributed Systems Architecture Lab Session 1. Introduction to ZeroC Ice Francisco Moya November 15, 2011 In this session we will learn to use basic Ice tools to develop a very simple distributed application. It will be developed in two steps. First, we will describe a bottom-up approach to building a distributed hello world example. Although quite similar, this is not the usual workflow for experienced Ice developers, but we will use it as an excuse to introduce several important concepts. Afterwards we will use some of the services provided by Ice to enhance the developer experience in the actual computer network. 1 Introduction Most object-oriented distributed middlewares, such as ZeroC Ice, use a technique developed in the late 80 s and early 90 s called Remote Method Invocation (RMI). This technique essentially attempts to replicate the behavior of normal method invocations to model remote interactions among components. Figure 1 shows a schematic view of the inner workings of a client computer invoking a method on a remote object running on a server computer. A remote object is an object whose methods may be invoked remotely. This is implemented by interposing an intermediate infrastructure such as the one depicted in figure 1. Remote objects are constructed in a similar way to ordinary objects, but they require an additional registration operation to publish their functionality through the network. Figure 1: Remote method invocation. 1

2 November 15, 2011 lab-ice-intro-java.nw 2 Figure 2: Simplified sequence diagram for a successful RMI. The interaction sequence shown in 2 shows the whole process. When a remote client invokes a remote method on a remote object it just invokes an ordinary method on a local proxy object residing in the same computer. Then the proxy object translates this invocation into a request message sent through the network by a communications kernel and waits for a response. At the server computer the request message is decoded and forwarded to a skeleton. The skeleton identifies the destination object, the method to be invoked and the arguments, and performs the actual invocation on the remote object implementation. Afterwards, it packages the return value in a response message which is then sent back through the network. The proxy, which was waiting for the response, decodes the return value which is then returned to the client. The proxy acts as a representative of the remote object at the client-side. It behaves as a pointer to the remote object although the object is not in the same address space. The proxy implements the same methods as the remote object but everything is translated to a request message through the network. The skeleton is the complementary part in the server side. It receives request messages from proxies and return response messages when the actual method is invoked. Fortunately proxies and skeletons are automatically generated from an abstract specification of the interfaces. Therefore everything related to the network is provided by the middleware. Most of the details of network programming are not visible to the programmer of distributed applications. In the following sections we will describe in detail how to develop a simple distributed application using a specific object-oriented distributed middleware, the Internet Communications Engine (Ice), developed by ZeroC, Inc. 2 Overall architecture design The first step in the development of any distributed application is the identification of the components and the characterization of the interactions among them. In this example we will implement a distributed version of the well-known hello world application. The application will be composed of two components. A server component runs on a computer and awaits for text messages to display in the console. A client component runs on a different computer and sends the well-known "Hello,

3 November 15, 2011 lab-ice-intro-java.nw 3 Figure 3: Overall architecture of the distributed hello world example. World!" message to the server. Any of these components may be run on any computer. They may even be run on the same computer. This property is frequently referred to as location transparency and plays an important role in the development of truly scalable distributed applications. 3 Interface specification Once the global architecture and the interactions among components are well-defined then these interactions must be translated into a formal specification. Most modern middlewares use an abstract interface description language (IDL) to specify possible interactions in terms of object interfaces. ZeroC Ice uses a language called Slice as the only specification language. Slice is some kind of an hybrid among C++, Java, or C# but remains as a purely declarative language. There is no way to express a sequece of actions. Since our application does only require interactions initiated by the client and served by the server component then we just need a single remote interface. That interface must be implemented in the server-side and exercised from the client-side. 3 Hello.ice 3 module UCLM { interface Hello { void puts(string str); ; ;

4 November 15, 2011 lab-ice-intro-java.nw 4 Slice files usually have an.ice extension. Any Slice specification must define at least a module, which contains one or more interface specifications. In this case we use the UCLM module which contains the Hello interface. In our example there is just one possible type of interaction between remote components: The client may send a textual message to the server. Therefore we just need a single method puts which stands for put string and requires just the textual message (a string). 4 Proxy and skeleton generation The Slice file is used as the abstract specification of the remote interactions. Each of the components must know the Slice interfaces in order to be able to interact with other components. As described in section1, those components with an active role in the interactions (initiators or callers) must use proxies which implement the remote object interface and translates the invocations into messages through the network. Those components with a passive role in the interactions (components waiting for remote invocations) must use skeletons which translate network messages into actual method calls in the remote object implementation. Proxies and skeletons are generated by compiling the Slice specifications. There is a Slice compiler for each of the supported implementation languages. In this lab session we will be using Java and therefore we must use the slice2java Slice compiler. 4 Slice file compilation 4 slice2java Hello.ice

5 November 15, 2011 lab-ice-intro-java.nw 5 The compiler generates a bunch of files under the UCLM subdirectory: Client side Server side Hello.java HelloOperations.java HelloOperationsNC.java HelloPrx.java HelloDisp.java HelloPrxHelper.java HelloHolder.java HelloPrxHolder.java HelloDel.java HelloDelD.java HelloDelM.java The HelloPrx class implements the proxy and the HelloDisp class implements the base class for the skeleton. Most of the remaining files constitute implementation details that are hidden to the user. 5 Servant implementation 5a 5b The remote object implementation is usually called servant. There is a subtle difference between object and servant but we do not need to point this out in our first lab session. The compiler generated a class UCLM. HelloDisp that must be used as the base class of any servant implementation. The servant (object implementation) just needs to derive from UCLM. HelloDisp and implement the methods declared in the Hello interface. It is even easier if we use the Slice compiler switch --impl to generate a sample implementation. Generation of sample servant from a Slice file 5a slice2java --impl Hello.ice In this case the compiler generates an extra file named HelloI.java. This is just an example that may be used as a starting point for our own implementation. Let us look into the UCLM/HelloI.java file: Auto generated HelloI.java 5b package UCLM; public final class HelloI extends _HelloDisp { public HelloI() { public void puts(string str, Ice.Current current) {

6 November 15, 2011 lab-ice-intro-java.nw 6 6a This file declares a servant (object implementation). It is already defined as a derived class of UCLM. HelloDisp and declares the right Java syntax equivalent to the Slice specification. You probably noticed that a Slice string parameter is equivalent to a Java standard String, and a new parameter was appended to the end. The last parameter captures the context of the remote invocation. It will not be used in most of the lab sessions but we will show its usefulness later. The HelloI.java file is a stub with an empty implementation of the methods declared in the Slice file. The user must fill in the empty body of the methods. UCLM/HelloI.java 6a package UCLM; public final class HelloI extends _HelloDisp { public HelloI() { public void puts(string str, Ice.Current current) { Implementation of method puts 6b We just need to insert a trivial implementation of the puts method. We just use the standard Java console IO classes to print the string in the console. 6b Implementation of method puts 6b (6a) System.out.println(str); We already finished the servant implementation. Any instance of the HelloI class will be able to be invoked remotely if we first register the instance in the communications kernel. 6 Server application 6c The easiest way to develop a ZeroC Ice application is to derive a class from Ice.Application. Among other things this class takes care of proper initialization and finalization of the communications core (the communicator). We just need to provide a run method, which uses a signature similar to a main method. UCLM/Server.java 6c package UCLM; import Ice.*; class Server extends Ice.Application { public int run(string[] args) { Server implementation 7d return 0; ; Definition of main method 7e

7 November 15, 2011 lab-ice-intro-java.nw 7 One nice thing about this class is that the communications kernel is always available by invoking the communicator() method. This is extremely convenient to register a remote object. In Ice applications the connection between a remote object implementation and the communicator is achieved by means of an intermediate object adapter. A single object adapter may handle request messages for many remote objects. In the backstage the object adapter implements a concurrent multi-threaded server carefully fine-tuned to be able to process thousands of concurrent requests. The structure of most Ice applications is quite similar. We first create an object adapter, then we add to this adapter a set of remote object implementations (servants) and, finally, we activate the adapter to start processing requests from remote clients. 7a Object registration 7a (7d) ObjectAdapter oa = communicator().createobjectadapter("oa"); ObjectPrx prx = oa.add(new HelloI(), Identity of the remote object 7b ); oa.activate(); As the code shows, the add method requires two arguments, a servant (remote object implementation) and an object identity. This identity must be unique in the whole distributed system. Therefore a rather large identity is usually used. In this example we will be using an extremely simple identity for illustration purposes. Usually there is no need to know the structure of an object identity. The communicator may generate an appropriate identity from a user provided string. 7b Identity of the remote object 7b (7a) communicator().stringtoidentity("hello1") Once the object adapter is activated there is no need to do anything more. The activate method creates a new thread listening to network events. But we must do something because otherwise the run method would finish, and then the Ice.Application would shutdown the communicator. In these cases we may just wait for communicator shutdown. Besides, it would be convenient to shutdown the communicator if the user interrupts the program (typically by pressing Control-C). 7c Wait forever loop 7c (7d) shutdownoninterrupt(); communicator().waitforshutdown(); The server application is now complete. But for illustration purposes we will add some debugging information. When we add a servant to an object adapter, the object adapter returns a proxy. This proxy may be sent and use from anywhere in the whole computer network to contact the newly added remote object implementation. Let us print the returned proxy as a character string: 7d Server implementation 7d (6c) Object registration 7a System.out.println(communicator().proxyToString(prx)); Wait forever loop 7c Finally we just need to instantiate the server application. As in any Ice.Application we must invoke the main method which is quite similar to the standard main function. 7e Definition of main method 7e (6c) static public void main(string[] args) { Server app = new Server(); app.main("server", args);

8 November 15, 2011 lab-ice-intro-java.nw 8 8a 8b 8c To get a running executable we just need to compile Server.java using the java compiler together with the Ice library. Server compilation 8a javac -classpath /usr/share/java/ice.jar:. UCLM/Server.java The argument -classpath indicates that the compiler must look into the definitions included in the Ice library distribution and also in the current directory. 6.1 Running the server If we try to run the server now we would get a run-time error because object adapters require configuration. Ice configuration consists on a sequence of key-value pairs separated by = in a simple text file. For an object adapter we need to specify at least the endpoints, the transport protocols that should be used to contact the remote objects registered in the adapter. hello.cfg 8b OA.Endpoints=tcp -p 9090 The object adapter named OA will be available through TCP using port If no port is specified then a free port would be automatically selected. Now we may run the server specifying the new configuration file: Running the server 8c java -classpath /usr/share/java/ice.jar \ UCLM.Server --Ice.Config=hello.cfg

9 November 15, 2011 lab-ice-intro-java.nw 9 As a result the server will print something similar to the following: hello1 -t:tcp -h p 9090 Let us recall that the server prints a textual representation of the proxy created when a servant is added to an object adapter. The structure of the proxy is shown explicitly: A proxy holds the identity of the object it is pointing to (hello1 in this case). It may also be configured to interact with the remote side in different ways. In this case the proxy is configured as twoway (-t) which means that both request and response messages are acknowledged by the receiver. Finally a proxy contains a list of the endpoints used to contact the remote object. In this case the remote object may be contacted using the TCP protocol to connect to host at port Client application The client side is much simpler. Once we have a proxy we may use it as if it where a pointer to a local object. Therefore the main problem is how to get a proxy to the remote object. As we already explained above, proxies are returned by the add method of the object adapters at the server side. There are several techniques to make these proxies available to the client side but we will use the simplest one, reconstruction of the proxy form the textual representation given as a command line argument. Once we have a proxy we must coherce it into a specialized proxy implementing the Slice interface. In this case we need a UCLM.Hello proxy. This is easily achieved with the static method checkedcast of the UCLM.HelloPrxHelper class. Finally we may just invoke remote methods as if it were a local object. 9a Client implementation 9a (9b) ObjectPrx obj = communicator().stringtoproxy(args[0]); HelloPrx hello = HelloPrxHelper.checkedCast(obj); hello.puts("hello, World!"); 9b As in the case of the server, we use an Ice.Application to simplify the initialization and finalization of the communicator. UCLM/Client.java 9b package UCLM; import Ice.*; class Client extends Ice.Application { public int run(string[] args) { Client implementation 9a return 0; ; static public void main(string[] args) { Application app = new Client(); app.main("client", args);

10 November 15, 2011 lab-ice-intro-java.nw 10 10a To get a running executable we just need to compile Client.java together with the Ice library. Client compilation 10a javac -classpath /usr/share/java/ice.jar:. UCLM/Client.java 10b 7.1 Running the client The client may be run in any computer connected to the same network as the server. It is run by specifying the textual representation of the proxy in the command line: Running the client 10b java -classpath /usr/share/java/ice.jar UCLM.Client \ "hello1 -t:tcp -h p 9090" 10c 7.2 Troubleshooting Depending on the version of the Ice distribution and the Java distribution you use you may experience that the client is not able to contact the server. This is usually a configuration problem. By default modern operating systems use IPv6 and IPv4 as separate networking stacks. Therefore when a socket is bound to an IPv6 address it cannot communicate to an IPv4 peer. In GNU/Linux distributions you may change this default behaviour by editing /etc/sysctl.d/bindv6only.conf (preferred) or /etc/sysctl.conf to add the following parameter: /etc/sysctl.d/bindv6only.conf 10c net.ipv6.bindv6only = 0 8 Tips on packaging 10d 10e As this little example shows, running a Java program from the command line may be quite cumbersome. It is usually more user friendly to create a packaged JAR file with all of the information required to run the program. In order to create a JAR file you should use a manifest file stating the required Class-Path and the name of the class with the main static method. For example, for the server you may use the following minimal manifest file: Server.mft 10d Manifest-Version: 1.0 Class-Path: /usr/share/java/ice.jar Main-Class: UCLM.Server Note that the full path to the Ice library is included in the Class-Path declaration of the manifest file. Unlike the command line argument -classpath, multiple libraries should be separated by spaces. Be careful to end the Main-Class declaration with a newline character. Now you may build the JAR archive as follows: Generation of server JAR archive 10e jar cmf Server.mft Server.jar UCLM/*.class

11 November 15, 2011 lab-ice-intro-java.nw 11 All that is needed to run the server is this JAR archive. And the command line is much simpler: 11 Running the server JAR archive 11 java -jar Server.jar --Ice.Config=hello.cfg 9 Epilogue In this session we built a complete distributed application. Communication details are left out of the developers work. Try to modify the examples from this session in as many ways as possible. Here you have some suggestions: Substitute the checkedcast call by an uncheckedcast. Now experiment with the config file changing the endpoints to udp, or even tcp:udp. At the same time you will need to experiment changing the twoway communication mode (-t) to a datagram communication mode (-d). Add more methods with different types of arguments, with return values, and with more than one argument. Invoke them from the client. 10 Chunks /etc/sysctl.d/bindv6only.conf 10c Auto generated HelloI.java 5b Client compilation 10a Client implementation 9a Definition of main method 7e Generation of sample servant from a Slice file 5a Generation of server JAR archive 10e hello.cfg 8b Hello.ice 3 Identity of the remote object 7b Implementation of method puts 6b Object registration 7a Running the client 10b Running the server 8c Running the server JAR archive 11 Server compilation 8a Server implementation 7d Server.mft 10d Slice file compilation 4 UCLM/Client.java 9b UCLM/HelloI.java 6a UCLM/Server.java 6c Wait forever loop 7c