Module-5

Designing with Distributed Objects

(Chapter12,Book1)
Designing with Distributed Objects
• As businesses grow, =>set up operations over large geographic
areas => may span multiple states or even countries and often
find it desirable to process data at their point of origin or create
results at the location where they are needed.
• Distributed processing offers a number of advantages.
1. It is more economical and efficient to process data at the
point of origin.
2. Distributed systems make it easier for users to access and
share resources.
3. They also offer higher reliability and availability:
➢ failure of a single computer does not cripple the system
as a whole.
4. It is also more cost effective to add more computing power.
 Distributed computing is not without its share of drawbacks :
1. The software for implementing them is complex
• It must coordinate actions between a number of possibly
heterogeneous computer systems;
• if data is replicated, the copies must be made mutually consistent.
1. Data access may be slow because information may have to be
transferred across communication links
2. securing the data is a challenge.
• As data is distributed over multiple systems and transported over
communication links,
• Care must be taken to guarantee that it is not lost, corrupted, or stolen.
Two approaches to building a distributed system.
1. The first mechanism uses Java Remote Method Invocation (Java
RMI), which is a piece of software, generally called middleware,
that helps mask heterogeneity.
2. The second approach uses the world-wide web itself to access
data processed at remote sites.
Client/Server Systems
Distributed systems can be classified into
1. Peer-to-peer systems and
• In the former, every computer system (or node) in the
distributed system runs the same set of algorithms; they are
all equals, in some sense.
2. Client-server systems.
• There are two types of nodes: clients and servers.
• A client machine sends requests to one or more servers,
which process the requests, and return the results to the
client.
• Many applications can use this model and these days the
software at many clients are web browsers.
Basic Architecture of Client/Server Systems

• Each client runs a program

that provides a user
interface, which may or not
be a GUI.
• The server hosts an object-
oriented system.
• clients send requests to the
server, these requests are
processed by the object-
oriented system at the
server, and the results are
returned.
Client/Server systems • The results are then shown
to end-users via the user
interface at the clients
 Difficulty in accessing objects in a different JVM
This difficulty can be handled in one of
two ways:
1. By using object-oriented support software:
(Java RMI)
• The software solves the problem by the use of
proxies that receive method calls on ‘remote’
objects, ship these calls, and then collect and
return the results to the object that invoked
the call.
• The client could have a custom-built piece of
software that interacts with the server
software.
2. By avoiding direct use of remote objects by using the Hyper Text Transfer
Protocol (HTTP).
• The system sends requests and collects responses via encoded text messages.
• The object(s) to be used to accomplish the task, the parameters, etc., are all
transmitted via these messages.
 Java Remote Method Invocation
• Java RMI is to support the building of
Client/Server systems
• server hosts an object-oriented system that
the client can access programmatically.
• The objects at the server maintained for
access by the client are termed remote
objects.
• A client accesses a remote object by getting
what is called a remote reference to the
remote object.
• After that the client may invoke methods of the object.
• The basic idea behind RMI is to employ the proxy design pattern.
• This pattern is used when it is inefficient or inconvenient (even impossible,
perhaps) to use the actual object.
• The proxy pattern creates a proxy object at each client site that accesses the
remote object.
• The proxy object implements all of the remote object’s operations that the
remote object wants to be available to the client.
Java Remote Method Invocation contd…
• When the client calls a
remote method, the
corresponding method of
the proxy object is
invoked.
• The proxy object then
assembles a message that
contains the remote object’s
identity, method name, and
parameters.
• This assembly is called
marshalling
Java Remote Method Invocation contd…
• In this process, the method call must be represented with
enough information so that the remote site knows the object
to be used, the method to be invoked, and the parameters to
be supplied.
• When the message is received by it, the server performs
demarshalling, whereby the process is reversed.

Setting up a remote object system is accomplished by the following steps:

1. Define the functionality that must be made available to clients.
This is accomplished by creating remote interfaces.
2. Implement the remote interfaces via remote classes.
3. Create a server that serves the remote objects.
4. Set up the client.
1. Remote Interfaces
a. Define the system functionality that will be exported to clients=> implies
the creation of a Java interface
b. The functionality exported of a remote object is defined via what is called
a remote interface.
c. A remote interface is a Java interface that extends the interface
java.rmi.Remote, which contains no methods and simply serves as a
marker.
d. Clients are restricted to accessing methods defined in the remote
interface. Called remote method invocation
Remote method invocations can fail due to
a number of reasons:
1. The remote object may have crashed,
2. The server may have failed, or
3. The communication link between the
client and the server may not be
operational, etc.
as a result, all remote methods must be
declared to throw this exception.
 2. Implementing a Remote Interface:
1. After the remote interfaces are defined, the next step is to
implement them via remote classes.
2. Parameters to and return values from a remote method may be of
primitive type, of remote type, or of a local type.
3. All arguments to a remote object and all return values from a
remote object must be serializable.
4. They also implement the java.io.Serializable interface.
5. Parameters of non-remote types are passed by copy
6. They are serialized using the object serialization mechanism,
7. They too must implement the Serializable interface.
8. Remote objects must somehow be capable of being transmitted
over networks.
9. A convenient way to accomplish this is to extend the class
java.rmi.server.UnicastRemoteObject.
The implementation of BookInterface

Book must be
compiled using
the RMI compiler
by invoking the
command rmic as
below.
rmic Book
 Passing of remote objects as references:
• When an exported remote object is
passed as a parameter or returned
from a remote method call, the stub
for that remote object is passed
instead of the object itself.
• The stub itself contains a reference to
the serialized object and implements
all of the remote interfaces that the
remote object implements.
• All calls to the remote interface go
through the stub to the remote
object.
• Parameters or return values that are not remote objects are passed by value.
• Any changes to the object’s state by the client are reflected only in the client’s
copy, not in the server’s instance.
• Similarly, if the server updates its instance, the changes are not reflected in the
client’s copy.
 3. Creating the Server
• Before a remote object can be accessed, it must be instantiated and stored
in an object registry, so that clients can obtain its reference.
• Such a registry is provided in the form of the class java.rmi.Naming.
• The method bind is used to register an object and has the following
signature:

The process of creating and binding the name is given below.

The complete code for activating and storing the Book
object is shown below.
 4. The Client
A client may get a reference to the remote object it wants
to access in one of two ways:
1. It can obtain a reference from the Naming class using
the method lookup.
2. It can get a reference as a return value from another
method call.
 4. The Client
A client may get a reference to the remote object it wants to
access in one of two ways:
1. It can obtain a reference from the Naming class using the method lookup.
we assume that an object of type SomeInterface has been entered into the
local registry under the name SomeName.

The client can invoke remote methods on the object. the BookInterface object
are called and displayed

Department of ISE BMS Institute of Technology and Mgmt

 12.2.5 Setting up the System
• To run the system, create two directories, say server and client, and
• Copy the files BookInterface.java, Book.java, and BookServer.java
into server and the file BookUser.java into client.
• Then compile the three Java files in server and then invoke the
command
rmic Book
• This command creates the stub file Book_Stub.class. Copy the client
program into client and compile it.
Run RMI registry and the server program using the following commands
(on Windows).

Finally, run the client as below from the client directory.

 12.3 Implementing an Object-Oriented System on the Web
• world-wide web is the most popular medium for hosting distributed
applications.
• The browser acts as a general purpose client that can interact with any
application that talks to it using the Hyper Text Transfer Protocol (HTTP).
• All business logic and data processing take place at the server.
• Typically, the browser receives web pages from the server in HTML and
displays the contents according to the format, a number of tags and
values for the tags, specified in it.
• The browser simply acts as a ‘dumb’ program displaying whatever it gets
from the application and transmitting user data from the client site to the
server.
• The HTML program shipped from a server to a client often needs to be
customised : the code has to suit the context.
• This requires that HTML code for the screen be dynamically constructed.
This is done by code at the server.
• For server-side processing competing technologies such as Java Server
Pages and Java Servlets, Active Server Pages (ASP), and PHP.
12.3.1 HTML and Java Servlets
• Any system that ultimately displays web pages via a browser has to
create HTML code.
• HTML code displays text, graphics such as images, links that users
can click to move to other web pages, and forms for the user to
enter data.
• An HTML program can be thought of as containing a header, a
body, and a trailer.
• The header contains code like the following:
• There are two primary ways in which form data is encoded by
the browser:
• One is GET and the other is POST.
• GET means that form data is to be encoded into a URL while
• POST makes data appear within the message itself.

• Refer page number 400 and on for other HTML

tags.
 12.3.2 Deploying the Library System on the World-Wide
Web:
How servlets and HTML cooperate to serve web pages?

• HTML page is displayed on the client’s browser.

• The page includes, among other things, a form that allows the user to
enter some data.
• The client makes some entries in the form’s fields and submits them, say,
by clicking a button.
• The data in the form is then transmitted to the server and given to a Java
servlet, which processes the data and generates HTML code that is then
transmitted to the client’s browser, which displays the page.
12.3.2 Deploying the Library System on the World-Wide
Web: contd…
1. Developing User Requirements
➢ Interface requirements
2. Design and Implementation
a. Structuring the files
b. How to remember a user
c. Configuration
d. Structure of servlets in the web-based library
system
e. Execution flow
 1. Developing User Requirements
• Determine the system requirements:
1. The user must be able to type in a URL in the browser and connect to the library
system.
2. Users are classified into two categories: superusers and ordinary members
➢ superusers can execute any command when logged in from a terminal in the
library, whereas ordinary members cannot access some ‘privileged
commands’.
a. Only superusers can issue the following commands: add a member, add a
book, return a book, remove a book, process holds, save data to disk, and
retrieve data from disk.
b. Ordinarymembers and superusersmay invoke the following commands: issue
and renew books, place and remove holds, and print transactions.
c. Every user eventually issues the exit command to terminate his/her session.
1. Some commands can be issued from the library only. These include all of the
commands that only the superuser has access to and the command to issue
books.
2. A superuser cannot issue any commands from outside of the library. They can log
in, but the only command choice will be to exit the system.
5. Superusers have special user ids and corresponding password. For regular
members, their library member id will be their user id and their phone number
will be the passwo
 Interface requirements
• Large number of sequences of interactions are possible
between the user and the interface.
• Depict the requirements through state transition diagrams.
Logging in and the Initial Menu:

1.The Issue Book

command is available only
if the user logs in from a
terminal in
the library.

2. Commands to place a hold, remove a hold, print transactions, and renew books
are available to members of the library (not superusers) from anywhere.
3.Certain commands are available only to superusers who log in from a library
terminal: these are for returning or deleting books, adding members and books,
processing holds, and saving data to and retrieving data from disk.
 Add Book: State transition diagram for add book

• When the command to add a

book is chosen, the system
constructs the initial screen to
add a book,
• which should contain three
fields for entering the title,
author, and id of the book,
and then display it and enter
the Add Book state.
• By clicking on a button, it should be possible for the user to submit these
values to system.
• The system must then call the appropriate method in the Library class to
create a Book object and enter it into the catalog.
• The result of the operation is displayed in the Command Completed state.
State transition diagram for saving data

• From the Command Completed state, the system must

allow the user to add another book or go back to the
menu.
• In the Add Book state, the user has the option to cancel
the operation and go back to the main menu.
 State transition diagram for issuing books

A book may be checked out in two

different ways:
1. A member is allowed to check it
out himself/herself.
2. he/she may give the book to a
library staff member, who checks
out the book for the member

• In the first case, the system already has the user’s member id, so that should
not be asked again.
• In the second case, the library staff member needs to input the member id to
the system followed by the book id.
• After receiving a book id, the system must attempt to check out the book.
Whether the operation is successful or not, the system enters the Book Id
Processed state.
State transition diagram for renewing books
2. Design and Implementation
To deploy the system on the web, we need the following:
1. Classes associated with the library, create classes such as Library, Member,
Book, Catalog, and so on.
2. Permanent data (created by the save command) that stores information
about the members, books, who borrowed what, holds, etc.
3. HTML files that support a GUI for displaying information on a browser and
collecting data entered by the user.
• For example, when a book is to be returned, a screen that asks for the
book id should pop up on the browser. This screen will have a prompt
to enter the book id, a space for typing in the same, and a button to
submit the data to the system.
4. A set of files that interface between the GUI and the objects that actually
do the processing. Servlets will be used to accomplish this task.
Structuring the files
HTML code for delivery to the browser can be generated in one of two ways:
1. Embed the HTML code in the servlets. This has the disadvantage of
making the servlets hard to read, but more dynamic code can be
produced.
2. Read the HTML files from disk as a string and send the string to the
browser. This is less flexible because the code remains static.
➢ Create a separate HTML file for every type of page that needs to be
displayed. For example, create a file for entering the id of the book to be
returned, a second file for displaying the result of returning the book, a
third file for inputting the id of the book to be removed, a fourth one for
displaying the result of removing the book, etc.
➢ Exploit the commonalities between the commands and create a number
of HTML code fragments, a subset of which can be assembled to form an
HTML file suitable for a specific context.
Examples of HTML file fragments

For implementation of library application refer page

number from 410
How to remember a user
• Servlets typically deal with multiple users.
• When a servlet receives data from a browser, it must some how figure out
which user sent the message, what the user’s privileges are, etc.
• Each request from the browser to the server starts a new connection, and
once the request is served, the connection is torn down.
• Typical web transactions involve multiple request–response pairs.
• The system provides the necessary support by means of what are known as
sessions, which are of type HttpSession.
• When it receives a request from a browser, the servlet may call the method
getSession() on the HttpServletRequest object to create a session object, or
if a session is already associated with the request, to get a reference to it.
• When a user logs in, the system creates a session object as below.
HttpSession session = request.getSession();
• When the user logs out, the session is removed as below.
session.invalidate();
• Requests other than log in requires the user to be logged in. The following
code evaluates to true if the user does not have a session: that is, the user
has not logged in. request.getSession(false) == null
• A session object can be used to store information about the
session. In the library system, we would like to store the user id,
the type of terminal from which the user has logged in, and
some additional information related to the user.
1. void setAttribute(String name, Object value)
2. Object getAttribute(String name)
3. void removeAttribute(String name)
 Configuration
• The server runs with the support of Apache Tomcat, which is a
servlet container.
• A servlet container is a program that supports servlet execution.
• The servlets themselves are registered with the servlet container.
URL requests made by a user are converted to specific servlet
requests by the servlet container.
• The servlet container is responsible for initialising the servlets and
delivering requests made by the client browser to the appropriate
servlet.

Directory structure for the servlets

BMS Institute
BMS Institute of Technology
Technology and
andMgmt
Mgmt
 Structure of servlets in the web-based library system
• A servlet receives data from a
browser through a
HttpServletRequest object.
• This involves parameter names
and their values, IP address of the
user, and so on.
• For example, when the form to
add book is filled and the Add
button is clicked, the servlet’s
doPost method is invoked.
• This method has two parameters:
a request parameter of type
HttpServletRequest and a
response parameter of type
HttpServletResponse.
• These methods and doPost and
doGet are collected into a class
named LibraryServlet.
BMS Institute of Technology and Mgmt
Most of the methods of LibraryServlet fall into one of five
categories:
1. One group contains methods that store information about the
user.
2. Methods to validate users and help assess access rights.
3. The getFile method reads an HTML file and returns its contents
as a String object.
4. The fourth group of methods are used for handling users who
may have invoked a command without actually logging in.
5. The final group of commands deal with processing the request
and responding to it. Refer page number 414