File Download Using Rmi In Java

admin



  1. Java Rmi Example Programs
  2. File Download Using Rmi In Java Compiler

Java RMI Example: Auction System for Bidding on products concurrently New Easy Tutorial for Java RMI using Eclipse How to transfer or copy a file between computers using java RMI Project Ideas for Java RMI: Distributed Applications Group Chat Example using Java RMI with a Graphical User Interface. Example:rmic CalculatorImpl The above command produce the “CalculatorImplStub.class” file.(7) Start the RMI remote Registry: The references of the objects are registered into the RMI Registry So now you need to start the RMI registry for that use the command start rmiregistry So the system will open rmiregistry.exe (like a blank command. The java.rmi.server.hostname property is the complete host name of the server where the publicly accessible classes reside. The java.rmi.security.policy property specifies the policy file with the permissions needed to run the remote server object and access the remote server classes for download. In this lesson, I am going to show you how to create a Spring Boot application which has functions to download files from the Web Server to a local computer, for example, photo, zip, pdf files, etc. Below is some ways for creating the file downloading function. RMI is used to build distributed applications; it provides remote communication between Java programs. It is provided in the package java.rmi. Architecture of an RMI Application. In an RMI application, we write two programs, a server program (resides on the server) and a client program (resides on the client).

Java rmi example programs

Introduction

This is a brief introduction to Java Remote Method Invocation (RMI).Java RMI is a mechanism that allows one to invoke a method on anobject that exists in another address space.The other address space could be on the same machine or a different one.The RMI mechanism is basically an object-oriented RPC mechanism.CORBA is another object-oriented RPC mechanism. CORBA differs fromJava RMI in a number of ways:

  1. CORBA is a language-independent standard.
  2. CORBA includes many other mechanisms in its standard (such as a standard for TP monitors) none of which are part of Java RMI.
  3. There is also no notion of an 'object request broker' in Java RMI.

Java RMI has recently been evolving toward becoming more compatiblewith CORBA. In particular, there is now a form of RMI called RMI/IIOP('RMI over IIOP') that uses the Internet Inter-ORB Protocol (IIOP)of CORBA as the underlying protocol for RMI communication.

This tutorial attempts to show the essence of RMI, without discussingany extraneous features.At one time, Sun provided an RMI guide,but it includes a lot of material that is not relevant to RMI itself,and this document apparently no longer exists.This guide discussed how to incorporate RMI into an Applet,how to use packages and how to place compiled classes in a differentdirectory than the source code.All of these are interesting in themselves, but they have nothingat all to do with RMI.As a result, Sun's guide is unnecessarily confusing.Moreover, Sun's guide and examples omitted a number of detailsthat are important for RMI.

There are three processes that participate in supporting remotemethod invocation.

  1. The Client is the process that is invoking a method ona remote object.
  2. The Server is the process that owns the remote object.The remote object is an ordinary object in the address space ofthe server process.
  3. The Object Registry is a name server that relates objects withnames. Objects are registered with the Object Registry. Once anobject has been registered, one can use the Object Registry to obtain accessto a remote object using the name of the object.

In this tutorial, we will give an example of a Client and a Serverthat solve the classical 'Hello, world!' problem.You should try extracting the code that is presented and runningit on your own computer.

There are two kinds of classes that can be used in Java RMI.

  1. A Remote class is one whose instances can be used remotely.An object of such a class can be referenced in two different ways:
    1. Within the address space where the object was constructed,the object is an ordinary object which can be used like any otherobject.
    2. Within other address spaces, the object can be referenced usingan object handle. While there are limitations on how one can usean object handle compared to an object, for the most part one can useobject handles in the same way as an ordinary object.
    For simplicity, an instance of a Remote class will be called aremote object.
  2. A Serializable class is one whose instances can be copiedfrom one address space to another.An instance of a Serializable class will be calleda serializable object.In other words, a serializable object is one that can be marshaled.Note that this concept has no connection to the concept of serializabilityin database management systems.

    If a serializable object is passed as a parameter (or return value)of a remote method invocation, then the value of the object willbe copied from one address space to the other.By contrast if a remote object is passed as a parameter (or return value),then the object handle will be copied from one address space to the other.

One might naturally wonder what would happen if a class were bothRemote and Serializable.While this might be possible in theory, it is a poor design tomix these two notions as it makes the design difficult to understand.

Serializable Classes

We now consider how to design Remote and Serializable classes.The easier of the two is a Serializable class.A class is Serializable if it implements the java.io.Serializableinterface. Subclasses of a Serializable class are also Serializable.Many of the standard classes are Serializable, so a subclass of oneof these is automatically also Serializable.Normally, any data within a Serializable class should also be Serializable.Although there are ways to include non-serializable objects withina serializable objects, it is awkward to do so. See the documentationof java.io.Serializable for more information about this.

Using a serializable object in a remote method invocation is straightforward.One simply passes the object using a parameter or as the return value.The type of the parameter or return value is the Serializable class.Note that both the Client and Server programs must have access to thedefinition of any Serializable class that is being used.If the Client and Server programs are on different machines,then class definitions of Serializable classes may have to bedownloaded from one machine to the other. Such a download could violatesystem security. This problem is discussed in theSecurity section.

The only Serializable class that will be used in the 'Hello, world!' exampleis the String class, so no problems with security arise.

Remote Classes and Interfaces

Next consider how to define a Remote class.This is more difficult than defining a Serializable class.A Remote class has two parts: the interface and the class itself.The Remote interface must have the following properties:

  1. The interface must be public.
  2. The interface must extend the interface java.rmi.Remote.
  3. Every method in the interface must declare that it throwsjava.rmi.RemoteException.Other exceptions may also be thrown.
The Remote class itself has the following properties:
  1. It must implement a Remote interface.
  2. It should extend the java.rmi.server.UnicastRemoteObjectclass. Objects of such a class exist in the address space of the serverand can be invoked remotely.While there are other ways to define a Remote class,this is the simplest way to ensure that objects of a class can beused as remote objects. See the documentation of the java.rmi.server package for more information.
  3. It can have methods that are not in its Remote interface.These can only be invoked locally.
Unlike the case of a Serializable class, it is not necessaryfor both the Client and the Server to have access to the definitionof the Remote class. The Server requires the definition of boththe Remote class and the Remote interface, but the Client onlyuses the Remote interface. Roughly speaking, the Remote interfacerepresents the type of an object handle, while the Remote classrepresents the type of an object. If a remote object is being usedremotely, its type must be declared to be the type of the Remoteinterface, not the type of the Remote class.

In the example program, we need a Remote class and its correspondingRemote interface. We call these Helloand HelloInterface, respectively.Here is the file HelloInterface.java:Here is the file Hello.java:

All of the Remote interfaces and classes should be compiled usingjavac.Once this has been completed, the stubs and skeletons for the Remoteinterfaces should be compiled by using the rmic stub compiler.The stub and skeleton of the example Remote interface are compiledwith the command:

The only problem one might encounter with this command is thatrmic might not be able to find the filesHello.class and HelloInterface.classeven though they are in the same directory where rmic isbeing executed.If this happens to you, then try setting the CLASSPATHenvironment variable to the current directory, as in the following command:If your CLASSPATH variable already has some directoriesin it, then you might want to add the current directory to the others.

Programming a Client

Having described how to define Remote and Serializable classes,we now discuss how to program the Client and Server.The Client itself is just a Java program.It need not be part of a Remote or Serializable class,although it will use Remote and Serializable classes.

A remote method invocation can return a remote object as its return value,but one must have a remote object in order to perform a remote methodinvocation. So to obtain a remote object one must already have one.Accordingly, there must be a separate mechanism for obtaining the firstremote object. The Object Registry fulfills this requirement.It allows one to obtain a remote object using only the name of theremote object.

The name of a remote object includes the following information:

  1. The Internet name (or address) of the machine that is running theObject Registry with which the remote object is being registered.If the Object Registry is running on the same machine as the onethat is making the request, then the name of the machine can be omitted.
  2. The port to which the Object Registry is listening.If the Object Registry is listening to the default port, 1099, thenthis does not have to be included in the name.
  3. The local name of the remote object within the Object Registry.
Here is the example Client program:

The Naming.lookup method obtains an object handle from theObject Registry running on turtles.baclawski.com and listeningto the default port. Note that the result of Naming.lookupmust be cast to the type of the Remote interface.

The remote method invocation in the example Client ishello.say(). It returns a String which is then printed.A remote method invocation can return a String object becauseString is a Serializable class.

The code for the Client can be placed in any convenient class.In the example Client, it was placed in a class HelloClient Commando 1 game download for pc. that contains only the program above.

Java rmi file transfer example

Programming a Server

The Server itself is just a Java program.It need not be a Remote or Serializable class, although it will use them.The Server does have some responsibilities:

  1. If class definitions for Serializable classes need to be downloadedfrom another machine, then the security policy of your program must be modified.Java provides a security manager class called RMISecurityManager for thispurpose. The RMISecurityManager defines a security policy that allowsthe downloading of Serializable classes from another machine.The 'Hello, World!' example does not need such downloads, since the onlySerializable class it uses is String. As a result it isn't necessaryto modify the security policy for the example program. If your program defines Serializable classes that need to be downloadedto another machine, then insert the statementSystem.setSecurityManager (new RMISecurityManager());as the first statement in the main program below.If this does not work for your program, then you should consultthe Security section below.
  2. At least one remote object must be registered with the Object Registry.The statement for this is:Naming.rebind (objectName, object);where object is the remote object being registered,and objectName is the String that names the remote object.
Here is the example Server:The rmiregistry Object Registry only accepts requeststo bind and unbind objects running on the same machine,so it is never necessary tospecify the name of the machine when one is registering an object.

The code for the Server can be placed in any convenient class.In the example Server, it was placed in a class HelloServerthat contains only the program above.

Starting the Server

Before starting the Server, one should first start the Object Registry,and leave it running in the background.If the rmiregistry is running in the same directory as the server code,then one can use this command:Otherwise, one will need to specify a classpath. For example,if the compiled classes are in the bin directory. The classpath could alsobe specified in the environment. Still another approach is to write yourown registry as described in The RMI Registry.

It takes a second or so for the Object Registry to start running and tostart listening on its socket. If one is using a script, then one shouldprogram a pause after starting the Object Registry. If one is typing atthe command line, it is unlikely that one could type fast enough to getahead of the Object Registry.

The Server should then be started; and, like the Object Registry,left running in the background.The example Server is started using the command:The Server will take a few seconds to start running, and to construct and register remote objects.So one should wait a few seconds before running any Clients.Printing a suitable message, as in the example Server, is helpfulfor determining when the Server is ready.

Running a Client

Java Rmi Example Programs

Th Client is run like any other java program.The example Client is executed using:

For this to run it is necessary for the HelloClient, HelloInterfaceand Hello_Stub classes be available on the client machine. In particular,the HelloClient.class, HelloInterface.classand Hello_Stub.class filesmust be in one of the directories specified in the CLASSPATH.

In theory, it should be possible for the client to download the necessaryclass files from the server without the need for these classes to be onthe client machine. In practice, this is very difficult to accomplishbecause classes can use other classes in other packages, and these otherpackages are determined by the CLASSPATH which is locally defined on eachmachine. More sophisticated (and more complex) remote method invocationmechanisms (such as CORBA) can achieve this, but simpler mechanisms like RMI cannot (at least not yet).

Security

One of the most common problems one encounters with RMI is a failuredue to security constraints. This section gives a very brief introductionto the Java security model as it relates to RMI. For a more completetreatment, one should read the documentation for the Java SecurityManagerand Policy classes and their related classes. Note that this sectionassumes that one is using Java 1.2 or later. Some of the statementsare not true for earlier versions.

A Java program may specify a security manager that determinesits security policy. A program will not have any security managerunless one is specified.One sets the security policy by constructing a SecurityManager object andcalling the setSecurityManager method of the System class.Certain operations require that there be a security manager.For example, RMI will download a Serializable class from another machineonly if there is a security manager and the security manager permitsthe downloading of the class from that machine.The RMISecurityManager class defines an example of a security managerthat normally permits such downloads.

Good vst free. However, many Java installations have instituted security policiesthat are more restrictive than the default. There are good reasonsfor instituting such policies, and one should not override them carelessly.In particular, if your Java virtual machine already has a securitymanager and if this security manager does not allow the setSecurityManagermethod to be invoked, then you will not be able to change security policiesother than as allowed by the existing security manager.This is the case for applets running in a browser. In order to protectthe client from potentially dangerous applets, the security manager ofapplets does not allow many operations, including reading and writing localfiles, as well as changing the security manager.

The rest of this section discusses some ways that can be used foroverriding security policies that prevent RMI from functioning properly.

The SecurityManager class has a large number of methodswhose name begins with check. For example, checkConnect (String host, int port).If a check method returns, then the permission was granted. For example, ifa call to checkConnect returns normally, then the current security policy allows the program to establish a socketconnection to the server socket at the specified host and port.If the current security policy does not allow one to connect to thishost and port, then the call throws an exception. This usually causes yourprogram to terminate with a message such as:The message above would occur when an RMI server or client was not allowedto connect to the RMI registry running on the same machine as the server or client.

As discussed above, one sets the security policy by passing an object of typeSecurityManager to the setSecurityManager method of the System class. Thereare several ways to modify the security policy of a program. The simplesttechnique is to define a subclass of SecurityManager and to callSystem.setSecurityManager on an object of this subclass.In the definition of this subclass, you should overridethose check methods for which you want a different policy. For example, if youfind that your 'Hello, World!' program refuses to connect to the registry,then you should override the checkConnect methods. There are two checkConnect methods. The first was discussed above,and the second checkConnect method has a third parameterthat specifies the security context of the request.

File Download Using Rmi In Java Compiler

The following code illustrates how to do this:

The code above uses an anonymous inner class. Such a classis convenient when the class will only be used to construct an objectin one place, as in this example. Of course, one could also definethe subclass of RMISecurityManager in the usual way.

Defining and installing a security manager was the original techniquefor specifying a security policy in Java. Unfortunately, it is verydifficult to design such a class so that it does not leave any securityholes. For this reason, a new technique was introduced in Java 1.2,which is backward compatible with the old technique.In the default security manager, all check methods(except checkPermission) are implemented by calling thecheckPermission method. The type of permissionbeing checked is specified by the parameter of type Permission passed to the checkPermission method.For example, the checkConnect method calls checkPermission with a SocketPermission object.The default implementation of checkPermission is to callthe checkPermission method of the AccessController class.This method checks whether the specified permission is implied by a list ofgranted permissions. The Permissions class is used for maintaininglists of granted permissions and for checking whether a particular permissionhas been granted.

This is the mechanism whereby the security manager checks permissions,but it does not explain how one specifies or changes the security policy.For this purpose there is yet another class, named Policy.Like SecurityManager, each program has a current security policythat can be obtained by calling Policy.getPolicy(),and one can set the current security policy using Policy.setPolicy,if one has permission to do so.The security policy is typically specified by a policy configuration file(or 'policy file' for short) which is read when the program starts andany time that a request is made to refresh the security policy.The policy file defines the permissions contained in a Policy object.It is not inaccurate to think of the policy file a kind of serialization of aPolicy object (except that a policy file is intended to be readable byhumans as well as by machines).As an example, the following will grant all permissions of any kind to coderesiding in the RMI directory on the C: drive:

The default security manager uses a policy that is defined in a collectionof policy files. For the locations of these files see the documentationof the policytool program.If one wishes to grant additional permissions, then one can specify themin a policy file and then request that they be loaded using optionssuch as the following:Both of the '-D' options specify system properties. The first system property has the same effectas executing the following statement as the first statement inyour program:The second system property above causes the specified policy-file(which is specified with a URL) to be added to the other policy fileswhen defining the entire security policy.The policytool can be used to construct the policy file,but one can also use any text editor.

As if this wasn't already complicated enough,there is yet another way to deal with the problem of downloadingSerializable classes.The command-line option -Djava.rmi.server.codebase=code-basespecifies a location from which Serializable classes may be downloaded.Of course, your security manager must recognize this system property,and not all of them will do so.Furthermore, as mentioned earlier,this is only necessary if you actually need to download Serializable classes.

Acknowledgements

Thanks to Dr. J. Tinkertool für mac. Stephen Judd of UPenn for his help in improving this tutorial.

Ken Baclawski
342 WVH
College of Computer and Information Science
Northeastern University
360 Huntington Avenue
Boston, MA 02115
ken@baclawski.com
(617) 373-4631 / Fax: (617) 373-5121

The original for this document is at https://ken.baclawski.com/tutorial/rmi.html.


© 1998, 2013 Kenneth Baclawski. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that redistributions and uses retain this copyright notice.