HOA1&2 - Module 3 - PREHISTORCI ARCHITECTURE OF KERALA.pptx
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
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.
