1 / 21

Changing the the way of designing distributed applications

Changing the the way of designing distributed applications. Communication design orientation: The design of the protocol goes first and then the development of the system is done based on the protocol.

mandek
Download Presentation

Changing the the way of designing distributed applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Changing the the way ofdesigning distributed applications • Communication design orientation: The design of the protocol goes first and then the development of the system is done based on the protocol. • Application design orientation: The development and design of the system is done like if everything is local and then the application is divided into modules that will be running on different machines. • This first strategy has a more complicated design but the programming will use less resources. • The second is better when the communications are complicated, at the point to make the application difficult.

  2. Alternative Technologies • Development of networks => Development of distributed systems • Development of middleware (libraries,tools,services, etc..) that support the programming of distributed systems • Based on TCP/IP protocol • The programming language is more high-level • The problem of the distributed applications is not a particular case.

  3. Remote Procedure Calls (RPC) • Motivation: Development of NFS (SUN) • A client can call a function in an application running on a server just like if it is locally implemented. • Sends the parameters and receives the results in a correct format(Integer,String,float...) • eXternal Data Representation • Serialization.

  4. Remote Procedure Calls • The client stops the execution until the results are received. RPC Client RPC Server Call(parameters) Receive results Server framework: provided by the middleware

  5. The Interface file • Specifies the protocol of the remote function: name, required parameters (how many, and what type), result (type) • It is called “interface” file because server and the client get the needed information. RPC Client Interface definition file The client usesthe interface tocompile RPC Server The serverimplements it

  6. Remote Objects • As the object orientation paradigm developed the “remote object” approach replaced the previous paradigm. • An Application can call a method of an object located on another JVM. • The interface file is the key concept of the implementation. RemoteObjectServer Invokes the method Gets the result

  7. Defines the methods (just the header) that could be remotely invoked. • Gets a reference to the remote object. • Use the method and, • Receives the results as if it is locally located. • Defines a particular class to implement the methods specified in the interface • Creates the remote object from this class. • It is published in some registry service, to be located by the clients. Necessary files interface Use for compilation Implements Server program Client program

  8. getDate() Example: Remote Date Server • The only method of the object will be getDate(), this method will return as a result the date of the computer where it is located. Remote Server getDate() Tue Jun 12 17:20:24

  9. Must import java.rmi.* • Must extend the Remote class • Each declared method must throw a RemoteException The interface file import java.rmi.*; import java.util.Date; public interface RemoteDate extends Remote { public Date getDate() throws RemoteException; }

  10. Remote RemoteObject Remote Interface Definition of the class forthe remote object DateServer.java Defining a class to implement remote objects. Extends Implements Extends

  11. The client program import java.rmi.*; import java.rmi.server.*; import java.util.Date; public class DateClient { public static void main( String args[] ) { try { RemoteDate dateobj = (RemoteDate)Naming.lookup( "rmi://"+args[0]+"/DateServer" ); Date datum = dateobj.getDate(); System.out.println( “Server Date : " + datum ); } catch ( Exception e ){ System.out.println(e); } } }

  12. Remote Object Server Client Stub Skel The Stub and Skel files • The communications are implemented by the stub and skel files. • They are generated when the sourcecode is compiled using the rmic command. • With the 1.5 version of java they are generated automatically.

  13. rmiregistry Client Remote Object Server The name registry server • It is a server for registring and making public the remote objects. • The server of the remote object registers the object in it and the clients obtain a reference to the object from it. • Must run in the host server, and have access to the stub and skel files. • Must be reinitialized before the server registers the object. 2 3 1 4

  14. Client Remote Object Server ¿ What file and where? • The client need the interface and stub file. • The server need the Stub and Skel file. DateServer.class RemoteDate.class DateServer_stub.class (until 1.4) DateServer_skel.class (until 1.4) DateClient.class RemoteDate.class DateServer_stub.class (until 1.4)

  15. DateServer.java RemoteDate.java DateClient.java DateServer.class RemoteDate.class DateClient.class DateServer_skel.class DateServer_stub.class Generating stub & skel(for java 1.4 or earlier) • The class file of the implementation must be compiled again with the rmic command. javac javac javac rmic

  16. Remote Number Server Client Client Client Initiating the rmiregistry from the application. • It is possible to initiate the rmiregistry from an application calling a java method. • The following example will also demostrate concurrent problems. getNumber() 1 3 2 getNumber() getNumber()

  17. Remote Object Client Remote Object Server The RMI based chat • The client must receive the messages of the server. • The client implements a remote object wich is passed to the server as a parameter!!! • The server does not need to locate the client addClient(this) sendMessage(text) newMessage(text)

  18. Access to files Client A remote file server • open file read/write • close file • Read line • Write line • What happends if: • It is asked to open a non-existing file. • It is asked to read a non-opened file. • More errors are generated.

  19. Automatic activation of the remote server • Sometimes it is not convienient to have many servers running at the same time, just when it is necessary. • RMI provides a schema to activate objects. • Only one server is always running (the rmideamon), that will wakeup the objects when it is necesary. (Call from a client ) • It is necessary to write and run a “set-up” program to registry the sleeping server with the rmid that will wake it up. • For the client there is no difference.

  20. Steps to write an activable server • Rewrite the Server to extend an “activable” class instead of the RemoteUnicastObject. import java.rmi.activation.*; public class MyRemoteClass extends Activable implement MyInterface • Replace the constructor to one that has 2 parameters. public MyRemoteClass(ActivationID id, MarshalledObject data) throws RemoteException { super(id, 0); } • Compile it with javac and rmic. • Write and compile the Setup program

  21. Steps to run it • Run the ClassFileServer and rmiregistry • Run the rmid rmid –J-Djava.security.policy=policy.txt • Run the Setup program Java -Djava.security.policy=policy.txt – Djava.rmi.server.codebase=http://hostname:port/ Setup • Run the client. Java -Djava.security.policy=policy.txt – Djava.rmi.server.codebase=http://hostname:port/ client

More Related