MODULE-5-DESIGNING WITH DISTRIBUTED OBJECTS

Introduction

Distributed systems involve multiple interconnected computer systems that process data
across different locations, providing advantages such as increased efficiency, reliability, and
cost-effectiveness. These systems allow data processing at the point of origin, resource
sharing, and improved fault tolerance since the failure of one system does not compromise
the entire network. However, distributed systems come with challenges, including the
complexity of software design, potential slow data access due to communication links, and
security concerns.

Two common approaches to building distributed, object-oriented systems are:

1. Java Remote Method Invocation (RMI): Middleware that abstracts system

heterogeneity and facilitates remote method execution.
2. Web-Based Access: Utilizing the internet to retrieve and process data at remote sites.

12.1 Client/Server Systems

Distributed systems can be categorized into peer-to-peer systems and client/server systems.
While peer-to-peer systems involve equal nodes running identical algorithms, the
client/server approach is more commonly used in commercial applications. In this model,
clients send requests to servers, which process them and return results. Modern client
software often includes web browsers, enabling interaction with servers.

12.1.1 Basic Architecture of Client/Server Systems

In its simplest form, a client/server system consists of multiple clients and a single server.
Each client runs a user interface (e.g., GUI or non-GUI) that interacts with users. The server
hosts an object-oriented system, processes client requests, and sends results back to the
clients. This design can easily be extended to include multiple servers.

A challenge in client/server systems arises when objects exist in different Java Virtual
Machines (JVMs). Each JVM has its own address space, so objects in one JVM cannot
directly access objects in another JVM. For instance, accessing an object in JVM2 from
JVM1 using its address may lead to errors due to conflicting memory interpretations.

Solutions for JVM Communication Issues

1. Object-Oriented Support Software:

o Uses proxies to handle method calls on remote objects.
o Proxies transfer calls between JVMs and return results to the invoking object.
o This forms the foundation of Java Remote Method Invocation (RMI),
discussed in Section 12.2.
2. HTTP-Based Communication:
o Avoids direct use of remote objects.
 o Clients and servers exchange encoded text messages, including parameters and
HTML/HTTP data.
o Commonly implemented with web browsers as client software, making them
application-agnostic.
o Popular for hosting systems on the web

12.2 Java Remote Method Invocation

This section explains Java Remote Method Invocation (RMI) and its implementation for
building client-server systems. Here's a summary of key points:

Overview of Java RMI

• RMI enables clients to programmatically access remote objects hosted on a server.

• Clients use a remote reference to invoke methods on remote objects.
• RMI uses the proxy design pattern to manage communication between the client and
server.

How RMI Works

• Proxies (Stubs): Act as client-side representatives for remote objects. Stubs handle
marshalling (assembling method calls into messages) and sending them to the server.
• Server-Side: The server unmarshalls messages, invokes the appropriate method on
the remote object, and sends results back.

Steps to Implement RMI

1. Define Remote Interfaces:

o Use Java interfaces extending java.rmi.Remote.
o Declare methods to throw java.rmi.RemoteException.
2. Implement Remote Classes:
o Implement remote interfaces.
o Extend java.rmi.server.UnicastRemoteObject for remote object creation.
o Ensure all arguments and return types are serializable.
3. Create and Register the Server:
o Instantiate remote objects.
o Register them with an RMI registry using java.rmi.Naming.
4. Setup the Client:
o Use Naming.lookup() to get remote object references.
o Invoke methods on these objects as required.

12.3 Implementing an Object-Oriented System on the Web (In Short)

Web-based applications have become widespread for tasks like booking tickets, shopping,
and making reservations. Here's a summary of their key aspects:

1. Client-Server Model:
 o The browser acts as a general-purpose client that communicates with servers
via HTTP.
o Browsers primarily display server-generated HTML and transmit user inputs
to servers.
o Minimal computation happens on the client side.
2. Dynamic Content Generation:
o Server-side code dynamically generates HTML to personalize user
experiences (e.g., displaying specific flight booking details).
3. Server-Side Technologies:
o Popular technologies for server-side processing include:
▪ Java Server Pages (JSP)
▪ Java Servlets
▪ Active Server Pages (ASP)
▪ PHP

12.3.1 HTML and Java Servlets (In Short)

HTML Basics:

• HTML pages are made of a header, body, and footer. Tags like <head>, <body>, and
<title> define elements in the document.
• Tags may include attributes, such as style, to modify appearance (e.g., color or
font).
• Forms allow users to input data via <form>, <input>, and <submit> tags.

Forms and Data Transmission:

• A form uses the action attribute to specify where the data is sent, and the method
attribute to define the transmission method (GET or POST).
o GET: Data is sent in the URL; suitable for idempotent (repeatable) actions.
o POST: Data is sent in the message body; used for non-idempotent actions.

Java Servlets:

• Java servlets handle the request-response cycle.

• A servlet extends the HttpServlet class and overrides doPost or doGet methods.
• Form data is retrieved using request.getParameter(), processed, and returned as
HTML using the response object.

Key Features of the Code:

1. HTML Form Example:

o <form action="/servlet/apackage.ProcessInput" method="post">
sends data to a ProcessInput servlet.
o <input type="text" name="userInput"> creates a text input field.
o <input type="submit" value="Process"> creates a submit button.
2. Servlet Example (ProcessInput):
o Captures user input with request.getParameter("userInput").
 o Constructs and returns a dynamic HTML response using
response.getWriter().println().

Overall Flow:

1. User enters data into an HTML form and submits it.

2. The browser sends the data to the server.
3. The server processes the data using a servlet and dynamically generates an HTML
response

12.3.2 Deploying the Library System on the World-Wide Web

This comprehensive text outlines the process of designing and implementing a web-based
library management system. It involves transitioning an object-oriented system to a web
platform, focusing on servlet-based architecture and dynamic HTML. Here's a condensed
summary of the key points:

1. Developing User Requirements

• URL Access: Users connect to the library system by typing its URL.
• User Types:
o Superusers: Library employees with elevated privileges, like adding books,
members, or processing holds. These operations are restricted to library
terminals.
o Ordinary Members: General users can issue or renew books, place/remove
holds, and view transactions, accessible from any terminal.
• Authentication: Superusers require unique IDs and passwords, while members use
library IDs and phone numbers.
• Command Execution: State diagrams detail access flow for logging in, issuing
books, and other operations.

2. Interface Requirements

• State Transition Diagrams: Depict user interactions for commands (e.g., Add Book,
Issue Book).
• Common Operations:
o Log in for access.
o Command execution with a cancel option.
o Exit to terminate sessions.

3. Design Components

• Library Classes: Existing object-oriented classes manage members, books, and

catalogs.
 • Persistent Data: Data storage for members, books, holds, and transactions.
• Dynamic HTML: Interfaces are designed with adaptable templates for commands.
o HTML Fragments: Reusable components minimize file duplication (e.g.,
headers, input forms).

4. Dynamic HTML Integration

• Templates: Embedded placeholders (e.g., RESULT) are dynamically replaced with

runtime data.
• Flexibility: Minimal manual updates reduce inconsistencies across pages.

5. Session Management

• Sessions track user identities, roles, and privileges across requests using
HttpSession. Methods include:
o Create a session: getSession()
o Store attributes: setAttribute(String name, Object value)
o Retrieve attributes: getAttribute(String name)
o End a session: invalidate()

6. Server Configuration

• The system operates on an Apache Tomcat server, which acts as a servlet container.
The servlets process user requests and deliver dynamic responses.

7.Servlet Structure and Functions

1. Common Class - LibraryServlet:

o Base class for all servlets.
o Provides common methods like addAttribute, setAttribute,
getAttribute, and deleteAllAttributes.
o Handles user validation (e.g., validateSuperUser).
o Common HTML processing methods (e.g., getFile).
2. Servlet Lifecycle:
o doPost and doGet methods handle requests from the browser.
o Process begins with doPost and calls the abstract run method, which each
subclass overrides.

8.User Authentication and Access Management

 • Session Attributes:
o Store details like user ID and session state.
o Check if a user is logged in (notLoggedIn).
• Access Rights Validation:
o Methods like validateSuperUser ensure proper permissions.

Command Handling

• Adding/Removing Books:
o Similar flow: form creation, submission handling, result generation.
• Renewing Books:
o More complex due to iterative processing of multiple books:
▪ Checkbox controls for selecting books to renew.
▪ Attributes store book details for state management across requests.

9.Login and Logout Process

Key Components:

1. LibraryServlet:
o Loads privileged users and IP addresses into memory during initialization.
o Provides methods for validating users and managing user sessions.
2. IndexServlet:
o Handles user login by accepting user ID and password.
o Calls the getMenu method in MenuBuilder for user validation and menu
creation.
3. MenuBuilder:
o Responsible for checking user credentials and assembling appropriate menus.
o Utilizes methods from LibraryServlet for user validation.

Process Workflow:

1. Login Process:
o User enters credentials (user ID and password).
o Validation:
▪ validateSuperUser: Checks if the user is a privileged superuser.
▪ validateOrdinaryMember: Checks if the user is a regular library
member.
▪ If validation fails, the login screen is redisplayed with an error
message.
o Attribute Setup:
▪ Sets attributes like userType (Privileged/Ordinary), location
(Library/Outside), and currentUserId in the request object.
 o Menu Generation:
▪ Calls the getMenu method to generate a personalized menu based on
user type and location.
2. Menu Options:
o Privileged Users:
▪ Commands like Add and Remove Book (if logged in from the library).
o Ordinary Members:
▪ Commands like Place Hold and Remove Hold.
o Global Commands:
▪ Available to all users, including the Exit command.
3. Location Check:
o Determines whether the login is from within the library or from an external
terminal.
o Adjusts the menu accordingly.
4. Logout Process:
o Resets user attributes and navigates back to the main or login menu.
o For privileged users, clears the currentUserId attribute.

Menu Assembly:

• The getMenu method uses the following files to construct the HTML:
1. HEADER: Common header content.
2. LIBRARY_COMMANDS: Commands for users in the library.
3. PRIVILEGED_COMMANDS: Additional commands for superusers.
4. GLOBAL_COMMANDS: Commands available universally.
5. EXIT_COMMAND: Exit option.
6. END_PAGE: Common footer content.