Explain the process of implementing a remote interface.

1. Define the Remote Interface

•A remote interface specifies the functionality (methods) that can be accessed
remotely by clients.
• This interface must extend the java.rmi.Remote interface to indicate that it is a remote
interface.
• All methods in the remote interface must declare that they can throw
java.rmi.RemoteException to handle any errors in communication between the client
and server.
2. Implement the Remote Interface• After defining the remote interface, the next step is to
implement the remote interface
in a remote class.
• The remote class must also implement the java.io.Serializable interface so that objects
can be transmitted over the network.
• To allow the remote object to be accessed from a client, the class should extend
java.rmi.server.UnicastRemoteObject.
3. Compile the Remote Class
• The remote class needs to be compiled and processed using the RMI compiler, which
generates stub objects. These stubs act as proxies for the actual remote objects and
handle communication with clients.
4. Bind the Remote Object
• Once the remote class is compiled, it is bound to the RMI registry. The RMI registry
is a service that allows clients to look up remote objects by name and establish a
connection with them.
5. Client Accessing the Remote Object
• On the client side, the remote object is accessed via the stub. The client interacts with
the stub, which forwards the method calls to the actual remote object on the server.
• The client communicates with the stub as if it is directly interacting with the remote
object.

Analyze a basic architecture of client/server systems.

Analysis of the Basic Architecture of Client/Server Systems

Overview:

Client/Server systems consist of a server that hosts the core application or services and multiple
clients that request and utilize those services. Communication between clients and the server
typically involves request-response mechanisms.

●​ we assume that although the client/server systems we build may have multiple clients,
they will have just one server.
●​ It is not difficult to extend the techniques to multiple servers, so this is not a serious
restriction. Figure shows a system with one server and three clients.
●​ Each client runs a program that provides a user interface, which may or not be a GUI.
●​ The server hosts an object-oriented system.
●​ Like any other client/server system, clients send requests to the server, these requests
are processed by the object-oriented system at the server, and the results are returned.
The results are then shown to end-users via the user interface at the clients.

Benefits of Client/Server Architecture:

1.​ Scalability:
○​ New clients can easily be added without significant changes to the server.
2.​ Centralized Management:
○​ Core logic resides on the server, simplifying updates and maintenance.
3.​ Flexibility:
○​ Clients and servers can be developed independently as long as they follow the
agreed communication protocol.

Drawbacks:

1.​ Dependency on Network:

○​ Requires a reliable network for smooth operation.
2.​ Potential Bottleneck at Server:
○​ A single server handling requests from multiple clients can lead to performance
issues.

Basic difficulty in accessing objects in Java Virtual Machine

When objects reside in separate Java Virtual Machines (JVMs), the following challenges
arise:
1. Independent Memory Spaces:
Each JVM has its own memory space, and the addresses of objects in one JVM are meaningless
to another. For example, if an object in JVM 1 tries to use the address of
an object in JVM 2, it may access incorrect memory locations or fail entirely.
2. Lack of Direct Access:
Objects in one JVM cannot directly call methods or access fields of objects in another
JVM because there is no shared memory or address space.
3. Address Conflicts:
If two objects in separate JVMs have the same memory address (e.g., A1 in JVM 1
and A1 in JVM 2), accessing one object's address from the other JVM can cause
unintended behavior or errors.
4. Communication Complexity:
Exchanging data between JVMs requires additional mechanisms (e.g., remote method
invocation or text-based protocols) to send method calls, parameters, and results
across the JVM boundaries.
5. Serialization Overhead:
For remote access, objects often need to be serialized (converted to a format for
transmission), which can be complex, especially for large or complex object
Structures.
These difficulties are addressed through specialized approaches like proxies in Java RMI or
using text-based communication protocols like HTTP
Short Notes on Marshalling and Demarshalling

Marshalling and demarshalling are processes involved in remote method invocation in

distributed systems, especially when using the proxy pattern:
1. Marshalling:
o This process occurs at the client side.
o When a client calls a method on a remote object, the proxy object intercepts
the call.
o The proxy assembles a message containing:
▪ The identity of the remote object.
▪ The method name to be invoked.
▪ The parameters required for the method.
o This message is prepared in a format suitable for transmission over the
network.
2. Demarshalling:
o This process occurs at the server side after receiving the message.
o The server unpacks the message and extracts the necessary details:
▪ The remote object to be accessed.
▪ The method to be invoked.▪ The parameters supplied.
o The server then executes the method on the remote object and assembles the
result to be sent back to the client.
⁠ xplain how the library system can be deployed in the world-wide-web?
E
Analyze a library system deploying on the World-Wide Web and its operations.

Analysis of a Library System Deployed on the World-Wide Web and Its Operations

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.

3. 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.

4. 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 password.

GET and POST Method

There are two primary ways in which form data is encoded by the browser: one is GET and

the other is POST.

1. GET Method

Purpose: Retrieve data from a server.

Usage in SAP: The GET method is commonly used to fetch records, display data from
SAP

databases, or retrieve metadata from SAP systems like OData services.

Characteristics:

Data is sent in the URL query string.

Limited in length due to URL length restrictions.

It is idempotent, meaning multiple identical requests will produce the same result

without changing the system state

• Example:

Requesting a search result:GET /search?q=example HTTP/1.1

2. POST Method
 Purpose: Send data to the server to create or update resources.

Usage in SAP: The POST method is used for operations like creating new records in
SAP

systems, triggering workflows, or submitting forms.

Characteristics:

Data is sent in the request body, not in the URL.

Supports large payloads and complex data structures.

It is not idempotent, meaning multiple identical requests can create multiple

resources or cause repeated actions.

• Example:

Submitting a form with user details:

POST /submit HTTP/1.1

Content-Type: application/x-www-form-urlencoded

username=example&password=securepassword

Implementing an Object-Oriented System on the Web

Client-Server Architecture:

●​ The client is typically a web browser (like Chrome or Firefox), and it shows content to the
user. It takes user input like clicks or form submissions.
●​ The server hosts the application (the software that does the work), processes the data, and
sends back dynamic content like web pages to the browser.

HTML and Dynamic Content:

●​ Web pages are created using HTML (the language used to structure content on the web).
●​ When a user interacts with a website (like choosing a flight or making a reservation), dynamic
HTML is generated. This means the server creates custom web pages based on the user's
choices and sends them to the browser.
●​ Technologies like Java Server Pages (JSP), Java Servlets, PHP, and ASP help create this
dynamic content.

Form Handling:

●​ Users often fill out forms on websites, like entering their name or choosing a product. These
are created using HTML forms.
●​ When a form is submitted, the data is sent to the server using two methods:
○​ GET: Appends the data to the URL.
○​ POST: Sends the data in the body of the request.
●​ The server processes this data, like checking if a product is available or saving a reservation.

Object-Oriented Principles on the Web:

●​ In an object-oriented system, we treat things like users, products, and reservations as objects.
These objects have attributes (data, like name, price) and methods (actions, like save or check
availability).
●​ For example, when someone submits a reservation, a reservation object is created on the
server, and its methods are used to process it.

Server-Side Technologies:

●​ Technologies like Java Servlets, JavaServer Pages (JSP), PHP, and ASP are used on the
server to handle requests, process data, and send back responses (like HTML, JSON, or
images).

Communication Between Client and Server:

●​ HTTP (HyperText Transfer Protocol) is the communication protocol used between the
browser (client) and the server. The browser sends requests (like a GET request to view a page)
and the server responds with the necessary data (like an HTML page).

Dynamic Web Pages:

 ●​ The server dynamically generates web pages. This means that instead of just sending a fixed
web page, the server customizes the content based on the data (like showing the correct flight
details or personalized reservation options).

Marshalling and Demarshalling:

●​ Marshalling is the process of preparing data (like an object) to be sent over the network.
Demarshalling is the reverse process, where the data is turned back into its original object
when it reaches its destination.
●​ For example, if you're requesting data from a server, marshalling ensures that your request
(including what you want and how to handle it) is properly encoded for transmission.

Security and Session Management:

●​ Security is important. Authentication ensures that the user is who they say they are, and
authorization ensures that the user has permission to do what they want to do.
●​ Session management tracks a user's actions across different pages. It helps maintain the user's
state (like if they're logged in) using cookies or tokens.

Explain directory structure for servlets

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. As we have seen earlier, this method has two parameters: a request parameter of
type HttpServletRequest and a response parameter of type HttpServletResponse.

Each command is organised as a combination of one to three servlets. They need a number of

common utility functions during the course of processing. These methods and doPost and

doGet are collected into a class named LibraryServlet. This class has the structure shown in

Fig. 12.14.

Most of the methods of LibraryServlet fall into one of five categories:

1. One group contains methods that store information about the user. This information

includes the user id, the type of terminal from which the user has logged in, etc. and are

stored in attributes associated with the session object. The methods are addAttribute,

setAttribute, getAttribute, and deleteAllAttributes.

2. Methods to validate users and help assess access rights. The validateSuper User method

checks whether the user is a superuser and validateOrdinary Member does the same job for

ordinary members. The method library Invocation returns true if and only if the user has

logged in from a terminal located within the library.

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. The method notLoggedIn returns true if and only if the

user has not currently logged in. The method noLoginError Message returns HTML code that

displays an error message when a person who has not logged in attempts to execute a

command.

5. The final group of commands deal with processing the request and responding to it. The

doGet message calls doPost, which does some minimal processing needed for all commands

and then calls the abstract runmethod, which individual servlets override.
How to deploy the user requirements? Explain the steps involved in it.

Answer:

As in any system, the first task is to determine the system requirements. We will, as has been

the case throughout the book, restrict the functionality so that the system‘s size is

manageable.

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 are

essentially designated library employees, and ordinary members are the general public who

borrow library books. The major difference between the two groups of users is that

superusers can execute any command when logged in from a terminal in the library, whereas

ordinary members cannot access some ‗privileged commands‘. In particular, the division is

as follows:

(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) Ordinary members and superusers may 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.

3. 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.

4. 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 password.