Report on mini project(Student database handling using RMI)
- 1. BHARATI VIDYAPEETH COLLEGE OF ENGINEERING, SECTOR NO.7,C.B.D. NAVI MUMBAI-400614 A Report On “STUDENT DATABASE HANDLING USING RMI” Under Guidance Of Prof. SHILPA M. SATRE Department of INFORMATION TECHNOLOGY Submitted By Department Of Information Technology Engineering(2016-17) Roll No. Name of Students 41 Sonali Mali 42 Shraddha Mane 43 Amey Mhatre 44 Omkar Mhatre Date Of Submission :-
- 2. BHARATI VIDYAPEETH COLLEGE OF ENGINEERING, SECTOR NO.7,C.B.D. NAVI MUMBAI-400614 CERTIFICATE This is to certify that the following students of third year Information Technology department have successfully completed the report on "STUDENT DATABASE HANDLING USING RMI” in partial fulfillment of the course Distributed system as prescribed by the University Of Mumbai. Roll No. Name of Students 41 Sonali Mali 42 Shraddha Mane 43 Amey Mhatre 44 Omkar Mhatre Prof.S.M.Satre Prof. S.M. Patil Dr. M.Z. Shaikh (Project Guide) (Head Of Department) (Principal)
- 3. BHARATI VIDYAPEETH COLLEGE OF ENGINEERING, NAVI MUMBAI. Vision: The vision of our project is to study a client-server based application using RMI. Mission : The mission of our project is to insert the record through interactiveforms and easy to retrieve which store into database.
- 4. DECLARATION I declare that final semester report entitled “ STUDENT DATABASE HANDLING USING RMI” is my own work conducted under the supervision of the guide Mrs. Shilpa Satre from Bharati Vidyapeeth College of Engineering. Also I declare that following student also worked in this project: 1) Shraddha Mane 2) Sonali Mali 3) Amey Mhatre 4) Omkar Mhatre Information Technology Department, Bharati Vidyapeeth Collage of Engineering. Submitted To: Department of Information Technology, Bharati Vidyapeeth College of Engineering Mumbai University, Kharghar. State: Maharashtra.
- 5. ACKNOWLEDGEMENT We express esteemed gratitude and sincere thanks to our worthy project guide Prof. Shilpa Satre madam, our vocabulary is yet to find suitable words benefiting to high standard of knowledge set by her and extreme sincerity and affection with which she has regularly encourage us to put heart and soul in this work. We are much obliged to our honourable H.O.D Prof. S. M. Patil sir whose support and co-operation was always helpful and encouraging. We also convey great thanks to our honourable principal Dr.M. Z. Shaikh sir. Our parents who always bear with us in every critical situation and provide the support whenever required. As we give expression to our love and appreciation our heart is fill. And we in sincere appreciation of your valuable help. Please accept our respect and gratitude.
- 6. ABSTRACT Java RMI is a mechanism to allow the invocation of methods that reside on different Java Virtual Machines (JVMs). The JVMs may be on different machines or they could be on the same machine. In either case, the method runs in a different address space than the calling process. Java RMI is an object-oriented remote procedure call mechanism. In this article a server-client application is described, which is realised with an Java server and Java client using Java RMI. The application is about a student record. The client can: insert a data: The client can add a record of student into database and server stores this data into database. get a record: The client requests for a particular record. The server returns a available data related to that student to the client. delete a record: The client sends a roll no to the server, which will delete the corresponding record.
- 7. TABLE OF CONTENTS 1. Introduction. 2. Methodology. 1. Architecture. 2. How tobuild it. 3. ProposedMethodology. 1. Hardware and Software Requirement. 1.1 Hardware Requirements. 1.2 Software Requirements. 4. Result andAnalysis. 1. Performance Evaluation. 2. Graphical User Interface. 5. Future Work. 6. Conclusion. 7. References. List of figures: Figure No. Title Page NO. 1. Architecture of RMI. 2. 3.
- 8. INTRODUCTION This project is very introductory, they only introduce the basic idea of RMI in Java and present a very simple example. They do not look at the more interesting and complicated ideas of generating and returning objects from the remote server, calling back functions in the client or anything more than the basic calling of remote functions. For more information you should refer to a longer tutorial or book. The Java RMI is Java’s native scheme for creating and using remote objects. Java RMI provides the following elements: 1. Remote object implementations. 2. Client interfaces, or stubs, to remote objects. 3. A remote object registry for finding objects on the network. 4. A network protocol for communication between remote objects and their client (this protocol is JRMP, i.e. Java Remote Method Protocol). 5. A facility for automatically creating (activating) remote objects on-demand. Each of these elements (except the last one) has a Java interface defined for it in the java.rmi package and its subclasses. RMI is part of the core Java API and has been enhanced for JDK 1.2 (Java 2 platform) in recognition of the critical need for support for distributed objects in distributed-application development. With RMI, you can get a reference to an object that “lives” in a remote process on remote hosts and invoke methods on it as if it were a local object running within the same Java virtual machine as your code. Each remote object implements a remote interface that specifies which of its methods can be invoked by clients.
- 9. Prior to RMI, a distributed application involved socket programming, where a raw communication channel was used to pass messages and data between two remote processes. The programmer needed to define a low-level message protocol and data transmission format between processes in the distributed application. With RMI, you can “export” an object as a remote object, so that other remote processes/agents can access it directly as a Java object. RMI handles all the underlying networking needed to make your remote method calls work. RMI is a Java-only distributed object scheme; the distributed objects in an RMI-based distributed application have to be implemented in Java. This could be a problem when interfacing with legacy applications. CORBA, on the other hand, is a language-independent distributed object scheme. It is however, more complex to work with than RMI. There are three entities involved in running a program that uses RMI: client: this is the program that you write to access remote methods server: this is the program that you write to implement the remote methods - clients connect to the server and request that a method be executed. The remote methods to the client are local methods to the server. Object registry: this is a program that you use. The object registry runs on a known port (1099 by default) A server, upon starting, registers its objects with a textual name with the object registry. A client, before performing invoking a remote method, must first contact the object registry to obtain access to the remote object.
- 10. METHODOLOGY RMI Architecture The RMI runtime architecture There are three layers that comprise the basic remote-object communication facilities in RMI: 1. The stub/skeleton layer, which provides the interface that client and server application objects use to interact with each other. 2. The remote reference layer, which is the middleware between the stub/skeleton layer and the underlying transport protocol. 3. The transport protocol layer, which is the binary data protocol that sends remote object requests over the wire. In the figure, the server is the application that provides remotely accessible objects, while the client is any remote application that communicates with these server objects. Description of the architecture: 1. The client uses the client-side stub to make a request of the remote object. The server object receives this request from a server-side object skeleton. 2. A client initiates an RMI invocation by calling a method on a stub object. The stub maintains an internal reference to the remote object it represents and forwards the method invocation request through the remote reference layer by marshaling the method arguments into serialized form and asking the remote reference layer to forward the method request and arguments to the appropriate remote object.
- 11. 3. Marshaling involves converting local objects into portable form so that they can be transmitted to a remote process. Each object (e.g. a String object, an array object, or a user defined object) is checked as it is marshaled, to determine whether it implements the java.rmi.Remote interface. If it does, its remote reference is used as its marshaled data. If it isn’t a Remote object but is rather a Serializable object, the object is serialized into bytes that are sent to the remote host and reconstructed into a copy of the local object. If the object is neither Remote nor Serializable, the stub throws a java.rmi.MarshalException back to the client. 4. If the marshaling of method arguments succeeds, the client-side remote reference layer receives the remote reference and marshaled arguments from the stub. 5. The remote reference layer converts the client request into low-level RMI transport requests, i.e., into a single network-level request and sends it over the wire to the sole remote object (since in Java 2 the communication style supported is the point-to-point object references) that corresponds to the remote reference passed along with the request. 6. On the server, the server-side remote reference layer receives the transport-level request and converts it into a request for the server skeleton that matches the referenced object. 7. The skeleton converts the remote request into the appropriate method call on the actual server object. This involves unmarshaling the method arguments into the server environment and passing them to the server object. Arguments sent as remote references are converted into local stubs on the server, and arguments sent as serialized objects are converted into local copies of the originals. 8. If the method calls generates a return value or an exception, the skeleton marshals the object for transport back to the client and forwards it through the server reference layer. 9. The result is sent back using the appropriate transport protocol (e.g. Socket API using TCP/IP), where it passes through the client reference layer and stub, is unmarshaled by the stub, and is finally handed back to the client thread that invoked the remote method.
- 12. How to build it and run it So far the concept has been introduced and example programs presented but it is important to put these together in the correct order. The following is a brief summary: • first write the interface and compile it: javac RemoteAccount.java • compile the object implementation: javac RemoteAccountImpl.java • now in order to generate stubs that are linked to to client code to enable it to call the object, it is necessary to run the rmic program: rmic RemoteAccountImpl this generates RemoteAccountImp_Stub.class, this file must be copied to the directory on the client machine where the client programs will be compiled. • now compile the client program: javac RemAccTest.java • everything should be compiled, now start the rmiregistry program on the server machine: rmiregistry • now start the remote object server program: java RemoteAccountImpl 1000 note that this one needs a command-line argument giving the initial balance in the account, • now run the client program and it should work (?): java RemAccTest plink.feis.herts.ac.uk this program needs a command-line argument that is the name of the computer on which the server program is running. Later versions of Java don’t need the program rmic to be run explicitly. Also earlier versions still provide for the automatic downloading of the stub files from the server to the client. However I have spelt out each step to ensure that it will work under any circumstances and because, although a bit longer, it is probably simpler.
- 13. PROPOSED METHODLOGY The project is about to handle all the information of the student regarding their personal information. Also it manages resources which were managed and handled by manpower previously. The main purpose of the project is to integrate distinct sections of the organization into consistent manner so that complex functions can be handled smoothly by any technical or non-technical persons. 3. HARDWARE AND SOFTWARE REQUIREMENTS The following are minimum hardware and requirements that should be present to run the project successfully. Table 3.1 Tools and Technology Development technologies SQL server, visual studio Development tools SQL server, visual studio Database SQL Operating system Windows XP Profession Edition, Windows Vista Enterprise Edition Hardware P-IV 2.4, 1 GB RAM, 80 GB HDD Hardware Requirements Table 3.2 Hardware Requirement Client Configuration Pentium IV, 750 MHz, 20GB HDD Operating System: Windows XP/2000 onwords RAM: 256 MB minimum 400MB Minimum Free Space on Drive Server Configuration Operating System: Windows XP onwords RAM: 512MB Minimum 40GB Minimum Free Space on Drive 750MHz
- 14. Software Requirements Table 3.3 Software Requirement System Software JDK v1.8.0 Eclipse v4.4
- 20. FUTURE WORK
- 21. CONCLUSION RMI provides a solid platform for truly object oriented distributed computing. You can use RMI to connect to Java components or to existing components written in other languages. As Java proves itself in your environment, you can expand your Java use and get all the benefits-no porting, low maintenance costs, and a safe, secure environment. RMI gives you a platform to expand Java into any part your system in an incremental fashion, adding new Java servers and clients when it makes sense. As you add Java, its full benefits flow through all the Java in your system. RMI makes this easy, secure, and powerful.
- 22. REFERENCES Wikipedia http://www.corba.org www.slideshare.net