0% found this document useful (0 votes)
223 views

lab manual distributed systems_01

Lab Manual Distributed System

Uploaded by

Kranti Gajmal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
223 views

lab manual distributed systems_01

Lab Manual Distributed System

Uploaded by

Kranti Gajmal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 38

GHARDA FOUNDATION’S

GHARDA INSTITUTE OF TECHNOLOGY


A/P:-LAVEL, TALUKA: KHED,DIST. RATNAGIRI, STATE:MAHARASTRA, PIN:- 415 708
TELEPHONE NO:- 02356-262795/97/98 FAX NO :- 02356-262795

LABORATORY
MANUAL
Department
Of
Information Technology

Distributed Systems

Semester: - VI

GHARDA INSTITUTE OF TECHNOLOGY Page 1


(Affiliated to Mumbai University, Mumbai and Approved
by AICTE, New Delhi)

Academic Year:
Name

Subject

Departmen
t

Roll No. Division

Semester Branch

Batch Exam No.

GHARDA INSTITUTE OF TECHNOLOGY Page 2


(Affiliated to Mumbai University, Mumbai and Approved
by AICTE, New Delhi)

Certificate

This is to certify that Mr./Ms._______________________ Roll


no: _____Division:____ has completed term work in the
subject of _____________________________ for the semester
_____ of the academic year _________________.

Faculty In charge HOD


Principal

GHARDA INSTITUTE OF TECHNOLOGY Page 3


GHARDA FOUNDATION’S
GHARDA INSTITUTE OF TECHNOLOGY
A/P:-LAVEL, TALUKA: KHED,DIST. RATNAGIRI, STATE:MAHARASTRA, PIN:- 415 708
TELEPHONE NO:- 02356-262795/97/98 FAX NO :- 02356-262795

Aims and Objectives


1. To improve quality and result 100%
2. Practical facility and well equipment.
3. Internet facility.
4. Well teaching staff.
5. To provide department library facility.
6. To provide department study facility.
7. By giving personal attention towards students.

GHARDA INSTITUTE OF TECHNOLOGY Page 4


GHARDA FOUNDATION’S
GHARDA INSTITUTE OF TECHNOLOGY
A/P:-LAVEL, TALUKA: KHED,DIST. RATNAGIRI, STATE:MAHARASTRA, PIN:- 415 708
TELEPHONE NO:- 02356-262795/97/98 FAX NO :- 02356-262795

Software & Hardware Requirement

Software Required:

1. Jdk-1_5_0
2. Weblogic.
3. .net

Hardware Required:

Processor: Pentium III


RAM: 128 MB
Hard Disk: 40 GB

GHARDA INSTITUTE OF TECHNOLOGY Page 5


GHARDA FOUNDATION’S
GHARDA INSTITUTE OF TECHNOLOGY
A/P:-LAVEL, TALUKA: KHED,DIST. RATNAGIRI, STATE:MAHARASTRA, PIN:- 415 708
TELEPHONE NO:- 02356-262795/97/98 FAX NO :- 02356-
262795

LIST OF EXPERIMENTS

Sr.No. Name of the Experiment


01 Study of client-server programming.
02 Client Server based program using RMI
03 Implementation of Clock Synchronization (logical/physical)
04 Implementation of Election algorithm.
05 Implementation of Mutual Exclusion algorithms
06 Program multithreaded client/server processes.

07 Program to demonstrate process/code migration.

08 Write a distributed application using EJB


09 Write a program using CORBA to demonstrate object brokering.
10 Use .Net framework to deploy a distributed application.

GHARDA INSTITUTE OF TECHNOLOGY Page 6


GHARDA FOUNDATION’S
GHARDA INSTITUTE OF TECHNOLOGY
A/P:-LAVEL, TALUKA: KHED,DIST. RATNAGIRI, STATE:MAHARASTRA, PIN:- 415 708
TELEPHONE NO:- 02356-262795/97/98 FAX NO :- 02356-262795

University of Mumbai
Branch:- Information
Class: T.E Semester: VI
Technology

Subject : Middleware and Enterprise Integration Technology


Lecture 4
Periods per Week
Practical 2
(each 60 min)
Tutorial -
Hours Marks
Theory 3 100
Practical & Oral - 25
Oral - -
Term Work - 25
Evaluation System Total 150

GHARDA INSTITUTE OF TECHNOLOGY Page 7


GHARDA FOUNDATION’S
GHARDA INSTITUTE OF TECHNOLOGY
A/P:-LAVEL, TALUKA: KHED,DIST. RATNAGIRI, STATE:MAHARASTRA, PIN:- 415 708
TELEPHONE NO:- 02356-262795/97/98 FAX NO :- 02356-262795

SYLLABUS

Objectives of the Course:

• IT systems are more and more integrated with other software systems.
• The knowledge of integrating these systems by using Distributed systems
can be a key competence for IT engineers.Distributed systems is commonly understood
as an intermediary software layer between the application and the operating
system, which encapsulates the heterogeneity of the underlying communication
network, operating system or hardware platform.
• This course provides details about the modern component platforms. Based on
practical examples, details about modern middleware technologies are studied.
Students get the chance to gain in-depth knowledge popular middleware
platforms.

Sr
Hour
n
s
o Module Contents
1 Fundamentals Introduction, Distributed Computing Models, Software
Concepts, Issues in designing Distributed System, Client –
Server Model

2 Communication Message Passing , Introduction to Message Passing,


Advantages and features of Message Passing, Message
Format, Message Buffering, Multi Data gram Messaging ,
Group Communication
Remote Procedure Call (RPC): Basic RPC Operations,
Parameter Passing, Extended RPC Models
Remote Object Invocation: Distributed Objects, Binding a
Client to an Object, Static Vs Dynamic RMI, Parameter

GHARDA INSTITUTE OF TECHNOLOGY Page 8


Passing, Java RMI
Message Oriented Communication: Persistence and
synchronicity in communication, Message Oriented
Transient and Persistent Communications

3 Processes Threads, Code Migration: Approaches to Code Migration,


Migration and Local Resources, Migration in
Heterogeneous Systems

4 Synchronization Clock Synchronization, Physical and Logical Clocks,


Global State, Election Algorithms, Mutual Exclusion,
Distributed Transactions, Deadlocks

5 Consistency and Introduction, Data-Centric Consistency Models, Client


Replication Centric Consistency Models, Distributed Protocols

6 Distributed Overview of EJB S/W Architecture, view of EJB


Technologies and Conversation, Building and Deploying EJB, Roles in EJB,
Frameworks Types of Enterprise Beans, Lifecycle of Beans ,
Developing Applications using EJB Framework.
Introduction to CORBA, CORBA Components and
architecture, Method Invocation, Static and Dynamic
Invocation in CORBA, CORBA IDL, Developing
Application using CORBA
Introduction to .NET, .NET architecture, . NET Remoting
Comparison of RMI, CORBA, EJB, .NET

7 Service Oriented Defining SOA, Business value of SOA, SOA


Architecture characteristics, Concept of a service, SOA Architecture,
Deploying SOA applications

Text Books
Sunita Mahajan, Seema Shah, “ Distributed Computing”, Oxford, second edition.
Andrew S. Tanenbaum & Maarten van Steen “ Distributed Systems : Principles and
paradigms” Prentice Hall of India Private Limited
G. Sudha Sadasivam, Radha Shankarmani, "Middleware and Enterprise Integration
Technologies " , Wiley Precise Textbook

References:
1. Pradeep K. Sinha “Distributed Operating Systems”, Prentice Hall of India Private

GHARDA INSTITUTE OF TECHNOLOGY Page 9


Limited
2. Thomas Erl "Service Oriented Architecture : Concepts, Technology and Design" Prentice
Hall
4. G. Coulouris, J. Dollimore and T. Kindberg “Distributed Systems :

Term work: 25 marks

Term work should consist of at least 10 practical experiments with 1 mini project
and assignments covering the topics of the syllabus

Distribution of marks for term work shall be as follows:


Laboratory work (10 Experiments) 10 Marks

Mini Project 05 Marks

Assignments 05 Marks

Attendance 05 Marks

GHARDA INSTITUTE OF TECHNOLOGY Page 10


EXPERIMENT NO. 1

Title: Study of client-server programming.

Software: Jdk1.6

Theory:

Client-server computing or networking is a distributed application architecture that


partitions tasks or work loads between service providers (servers) and service requesters,
called clients.Often clients and servers operate over a computer network on separate hardware.
A server machine is a high-performance host that is running one or more server programs
which share its resources with clients. Clients therefore initiate communication sessions with
servers which await (listen to) incoming requests.

 The client-server characteristic describes the relationship of cooperating programs in


an application. The server component provides a function or service to one or many
clients, which initiate requests for such services.
 Functions such as email exchange, web access and database access, are built on the
client-server model. For example, a web browser is a client program running on a
user's computer that may access information stored on a web server on the Internet.

 The client-server model has become one of the central ideas of network computing.
Many business applications being written today use the client-server model. So do the
Internet's main application protocols, such as HTTP, SMTP, Telnet, DNS. In
marketing, the term has been used to distinguish distributed computing by smaller
dispersed computers from the "monolithic" centralized computing of mainframe
computers. But this distinction has largely disappeared as mainframes and their
applications have also turned to the client-server model and become part of network
computing.

 Each instance of the client software can send data requests to one or more connected
servers. In turn, the servers can accept these requests, process them, and return the
requested information to the client.

 The most basic type of client-server architecture employs only two types of hosts:
clients and servers. This type of architecture is sometimes referred to as two-tier. It
allows devices to share files and resources. The two tier architecture means that the
client acts as one tier and application in combination with server acts as another tier.

 The interaction between client and server is often described using sequence diagrams.
Sequence diagrams are standardized in the Unified Modeling Language.

GHARDA INSTITUTE OF TECHNOLOGY Page 11


Advantages

 In most cases, a client-server architecture enables the roles and responsibilities of a


computing system to be distributed among several independent computers that are
known to each other only through a network. This creates an additional advantage to
this architecture: greater ease of maintenance
 All data is stored on the servers, which generally have far greater security controls
than most clients. Servers can better control access and resources, to guarantee that
only those clients with the appropriate permissions may access and change data.
 Since data storage is centralized, updates to that data are far easier to administer than
what would be possible under a P2P paradigm. Under a P2P architecture, data updates
may need to be distributed and applied to each peer in the network, which is both time-
consuming and error-prone,as there can be thousands or even millions of peers.
 Many mature client-server technologies are already available which were designed to
ensure security, friendliness of the user interface, and ease of use.

Disadvantages

 Traffic congestion on the network has been an issue since the inception of the client-
server paradigm.As the number of simultaneous client requests to a given server
increases, the server can become overloaded. Contrast that to a P2P network, where its
aggregated bandwidth actually increases as nodes are added, since the P2P network's
overall bandwidth can be roughly computed as the sum of the bandwidths of every
node in that network.
 The client-server paradigm lacks the robustness of a good P2P network. Under client-
server, should a critical server fail, clients’ requests cannot be fulfilled.

Program:

Output:

GHARDA INSTITUTE OF TECHNOLOGY Page 12


EXPERIMENT NO. 2

AIM: Client Server based program using RMI

SOFTWARE: Jdk1.6.0

THEORY:
Remote Method Invocation (RMI)
 The only hint that it is a remote method is the “Naming.lookup”call with a URL
(Hidden) Java RMI classes do all the “heavy lifting” – opening network sockets,
transfer the function arguments, retrieve the results,close the network sockets
 On the server side, there is a “Naming.rebind” call in the main method (to bind the
server to a network location/URL)
● Again, the Java RMI classes to the “heavy lifting” -- converting the remote method
call into a “regular” method call on “normal” Java code running within the server.

Distributed Object Model


 Definitions:
o remote object - an object whose methods can be invoked from another Java
Virtual Machine
o remote interface - a Java interface that declares the methods of a remote object.
A remote object may be described by multiple remote interfaces
o remote method invocation (RMI) - the action of invoking a method of a
remote interface on a remote object.
 RMI has the same syntax as a local method invocation.

 Similarity with local objects:


o A reference to a remote object can be passed as an argument or returned as a
result in any method invocation (local or remote).
o A remote object can be cast (with Java casting) to any of the set of remote
interfaces supported by its implementation
o The instanceof operator can be used to test the remote interfaces
supported by a remote object.

GHARDA INSTITUTE OF TECHNOLOGY Page 13


Remote Interfaces and Classes

public interface BankAccount extends Remote


{
public void deposit (float amount)
throws java.rmi.RemoteException;
public void withdraw (float amount)
throws OverdrawnException,
java.rmi.RemoteException;
public float balance()
throws java.rmi.RemoteException; }

Remote class hierarchy

 RemoteObject - Remote semantics of class Object


 RemoteServer - abstract specification of remote reference: object creation and
exporting
 Subclasses of RemoteServer - concrete semantics of remote reference. Example:
UnicastRemoteObject defines a singleton remote object whose references are
valid only while the server process is alive.

Implementing a Remote Interface


 Extend java.rmi.server.UnicastRemoteObject (or other remote implementation class)
 Implement at least one remote interface
 Can define methods that do not appear in the remote interface, but those methods can
only be used locally.

Invocation of Remote Methods


 Clients interact with stub objects with exactly the same set of remote interfaces defined
by the remote class
 Stubs (generated by rmic compiler) implement the remote interfaces - they have the
same type as remote objects! (can use instanceof and casting)
 Caller of a remote method must be prepared to handle RemoteException

System Architecture
 3 independent layers:
o Stub-skeleton layer - client stubs and server skeletons
o Remote reference layer - Semantics of remote reference

GHARDA INSTITUTE OF TECHNOLOGY Page 14


o Transport layer - connection set up, management and object tracking

Stub-skeleton Layer

 Interface to applications. Stub functions:


o Initiating a call to the remote object (via remote reference layer).
o Marshaling arguments (using serialization)
o Informing the remote reference layer that the call should be invoked.
o Unmarshaling the return value or exception from a marshal stream.
o Informing the remote reference layer that the call is complete.
 Skeleton functions:
o Unmarshaling arguments from the marshal stream.
o Making the up-call to the actual remote object implementation.
o Marshaling the return value of the call or an exception (if one occurred) onto
the marshal stream.
 Stub and skeleton (bytecode) generated by RMI compiler (rmic)

ALGORITHM:

1. Create the classes for Interface, Implementation, Server and Client.


2. The interface class contains the method to download the specified file.
3. The implementation class defines function to download the file.
4. The server class creates the instance for implementation class and calls rebind
method.
5. The client class has the object of interface class and object calls the result of
arithmetic operation.
6. Using RMI complier state and skeleton is generated.
7. Start the RMI registry.
8. Start the client and server.

Program:

OUTPUT:

GHARDA INSTITUTE OF TECHNOLOGY Page 15


EXPERIMENT NO. 3

AIM: Implementation of Clock Synchronization (logical/physical)

SOFTWARE: Jdk1.6.0

THEORY:

Logical clocks
A logical clock is a mechanism for capturing chronological and causal
relationships in a distributed system. Distributed system may have no
physically synchronous global clock, and logical clock allow to get
global ordering on events from different processes in such systems.
First implementation, the Lamport timestamps, was proposed by Leslie
Lamport in 1978 (Turing Award in 2013).

In logical clock systems each process have two data structures with
logical local time and logical global time. Logical local time is used by
the process to mark its own events, and logical global time is the local
information about global time. A special protocol is used to update
logical local time after each local event, and logical global time when
processes exchange data.[1]

Logical clocks are useful in computation analysis, distributed


algorithm design, individual event tracking, exploring computational
progress.

Logical clock algorithms of note are:

 Lamport timestamps, which are monotonically increasing software


counters.
 Vector clocks, that allow for partial ordering of events in a distributed
system.

GHARDA INSTITUTE OF TECHNOLOGY Page 16


 Version vectors, order replicas, according to updates, in an optimistic
replicated system.
 Matrix clocks, an extension of vector clocks that also contains information
about other processes' views of the system.

Logical clocks & concurrency

Assign a “clock” value to each event


–if ab then clock(a) < clock(b)
–since time cannot run backwards
If a and b occur on different processes that do not exchange messages, then
neither a b nor b a are true
-These events are concurrent
-Otherwise, they are causal

Lamport’s algorithm
Lamport’s algorithm remedies the situation by forcing a resequencing of
timestamps to ensure that the happens before relationship is properly depicted
forevents related to sending and receiving messages. It works as follows:Each
process has a clock, which can be a imple counter thatis incremented for each
event.The sending of a message is an event and each message carries with it a
timestamp obtained from the current value of the clock at that process (sequence
number). The arrival of a message at a process is also an event will also receive
a timestamp – by the receiving process, of course. The process’ clock is
cremented prior to timestamping the event, as it would be for any other event. If
the clock value is less than the timestamp in the received message, the system’s
clock is adjusted to the (message’s timestamp + 1). Otherwise nothing is done.
The event is now timestamped.
- Each message carries a timestamp of the sender’s clock.
- When a message arrives:
if receiver’s clock < message_timestamp set system clock to
(message_timestamp+ 1)
–else do nothing
- Clock must be advanced between any two events in the same process.
- Algorithm allows us to maintain time ordering among related events

Program:

GHARDA INSTITUTE OF TECHNOLOGY Page 17


OUTPUT:

Experiment No 4
AIM: Implementation of Mutual exclusion.

SOFTWARE: Jdk1.6.0

THEORY:

MUTUAL EXCLUSION

When a process has to read or update certain shared data structures, it first enters
a critical region to achieve mutual exclusion and ensure that no other process
will use the shared data structures at the same time. In single- processor systems,
critical regions are protected using semaphores, monitors, and similar constructs.

A Centralized Algorithm

The most straightforward way to achieve mutual exclusion in a distributed


system is to simulate how it is done in a one-processor system. One process is
elected as the coordinator (e.g., the one running on the machine with the highest
network address). Whenever a process wants to enter a critical region, it sends a
request message to the coordinator stating which critical region it wants to enter
and asking for permission. If no other process is currently in that critical region,
the coordinator sends back a reply granting permission, as shown in Fig. (a).
When the reply arrives, the requesting process enters the critical region

0 1 2 0 1 2 0 1 2
request ok request Release

ok
3 3 No reply 3
Queue is 2
empty

GHARDA INSTITUTE OF TECHNOLOGY Page 18


(a) (b) (c)

FIG (a) Process 1 asks the coordinator for permission to enter a critical
region. Permission is granted. (b) Process 2 then asks permission to enter the
same critical region. The coordinator does not reply. (c) When process 1 exits
the critical region, it tells the coordinator, which then replies to 2
A Token Ring Algorithm

A completely different approach to achieving mutual exclusion in a distributed


system is illustrated in Fig. Here we have a bus network, as shown in Fig. (a),
(e.g., Ethernet), with no inherent ordering of the processes. In software, a logical
ring is constructed in which each process is assigned a position in the ring, as
shown in Fig. (b). The ring positions may be allocated in numerical order of
network addresses or some other means. It does not matter what the ordering is.
All that matters is that each process knows who is next in line after itself .

Fig(b):Token Ring
For this algorithm, we assume that there is a group of processes with noinherent
ordering of processes, but that some ordering can be imposed on the group. For
example, we can identify each process by its machine address and process ID to
obtain an ordering. Using this imposed ordering, a logical ring is constructed in
software. Each process is assigned a position in the ring and each process must
know who is next to it in the ring (Figure b).The ring is initialized by giving a
token to process 0. The token circulates around the ring (process n passes it to
(n+1)mod ringsize.When a process acquires the token, it checks to see if it is
attempting to enter the critical section. If so, it enters and does its work. On exit,
it passes the token to itsneighbor.If a process isn't interested in entering a critical
section, it simply asses the token along.

GHARDA INSTITUTE OF TECHNOLOGY Page 19


Program:

Output:
Experiment No. 5
AIM: Implementation of Election.

SOFTWARE: Jdk1.6.0

THEORY:

Election algorithms
We often need one process to act as a coordinator. It may not matter which
process does this, but there should be group agreement on only one. An
assumption in election algorithms is that all processes are exactly the same with
no distinguishing characteristics. Each process can obtain a unique identifier (for
example, a machine address and process ID) and each process knows of every
other process but does not know which is up and which is down.Bully
algorithmThe bully algorithm selects the process with the largest identifier as the
coordinator. It works as follows:

1.When a process pdetects that the coordinator is not responding to requests, it


initiates an election:
a.p sends an election message to all processes with higher numbers.
b.If nobody responds, then p wins and takes over.
c.If one of the processes answers, then p's job is done.

2.If a process receives an election message from a lower -numbered process at


any
time, it:
a.sends an OK message back.
b.holds an election (unless its already holding one).

3.A process announces its victory by sending all processes a message telling
them that it is the new coordinator.

4.If a process that has been down recovers, it holds an election.

GHARDA INSTITUTE OF TECHNOLOGY Page 20


Ring algorithm

The ring algorithm uses the same ring arrangement as in the token ring mutual
exclusion algorithm, but does not employ a token. Processes are physically or
logically ordered so that each knows its successor.If any process detects failure,
it constructs an electionmessage with its process I.D. (e.g. network address and
local process I.D.) and sends it to its successor.If the successor is down, it skips
over it and sends the message to the next party. This process is repeated until a
running process is located.At each step, the process adds its own process I.D. to
the list in the message.Eventually, the message comes back to the process that
started it:

1.The process sees its ID in the list.

2.It changes the message type to coordinator

3.The list is circulated again, with each process selecting the highest numbered
ID in
the list to act as coordinator.

4.When the coordinator message has circulated fully, it is deleted.

Multiple messages may circulate if multiple processes detected failure. This


creates a bit of
overhead but produces the same results.

Program:

GHARDA INSTITUTE OF TECHNOLOGY Page 21


Output:

Experiment No: 07
Aim: Program to implement multithreaded client server using socket

Theory:

Sockets Programming in Java

A socket is the one end-point of a two-way communication link between two programs
running over the network. Running over the network means that the programs run on
different computers, usually referred as the local and the remote computers. However one
can run the two programs on the same computer. Such communicating programs constitutes a
client/server application. The server implements a dedicated logic, called service. The clients
connect to the server to get served, for example, to obtain some data or to ask for the
computation of some data. Different client/server applications implement different kind of
services.

A socked is a complex data structure that contains an internet address and a port number. A
socket, however, is referenced by its descriptor, like a file which is referenced by a file
descriptor.

This connection is established as follows:

1. When the server receives a connection request on its specific server port, it creates a
new socket for it and binds a port number to it.
2. It sends the new port number to the client to inform it that the connection is
established.
3. The server goes on now by listening on two ports:
o it waits for new incoming connection requests on its specific port, and
o it reads and writes messages on established connection (on new port) with the
accepted client.

The server communicates with the client by reading from and writing to the new port. If
other connection requests arrive, the server accepts them in the similar way creating a new
port for each new connection. Thus, at any instant, the server must be able to communicate
simultaneously with many clients and to wait on the same time for incoming requests on its
specific server port. The communication with each client is done via the sockets created for
each communication.

GHARDA INSTITUTE OF TECHNOLOGY Page 22


SERVER CLIENT
,--------------. ,--------------.
| ,-| | |
| accept | |<---------------------| create |
| `-| | |
| ,-| |-. |
| read/write | | <------------------->| | read/write |
| `-| |-' |
`--------------' `--------------'

The java.net package in the Java development environment provides the class Socket that
implements the client side and the class serverSocket class that implements the server side
sockets.

1) Opening a socket
2) The client side

When programming a client, a socket must be opened like below:

Socket MyClient;
MyClient = new Socket("MachineName", PortNumber);

This code, however, must be put in a try/catch block to catch the IOException:

Socket MyClient;

GHARDA INSTITUTE OF TECHNOLOGY Page 23


try {
MyClient = new Socket("MachineName", PortNumber);
}
catch (IOException e) {
System.out.println(e);
}

where

 MachineName is the machine name to open a connection to and


 PortNumber is the port number on which the server to connect to is listening

2)The server side

When programming a server, a server socket must be created first, like below:

ServerSocket MyService;
try {
MyServerice = new ServerSocket(PortNumber);
}
catch (IOException e) {
System.out.println(e);
}

The server socket is dedicated to listen to and accept connections from clients.
After accepting a request from a client the server creates a client socket to
communicate (to send/receive data) with the client, like below :

Socket clientSocket = null;

GHARDA INSTITUTE OF TECHNOLOGY Page 24


try {
serviceSocket = MyService.accept();
}
catch (IOException e) {
System.out.println(e);
}

Now the server can send/receive data to/from the clients. Since the sockets are like
the file descriptors the send/receive operations are implemented like read/write file
operations on the input/output streams.

2) Creating an input stream

On the client side, you can use the DataInputStream class to create an input
stream to receive responses from the server:

DataInputStream input;

try {

input = new DataInputStream(MyClient.getInputStream());

catch (IOException e) {

System.out.println(e);

The class DataInputStream allows you to read lines of text and Java primitive
data types in a portable way. It has several read methods such as read, readChar,
readInt, readDouble, and readLine. One has to use whichever function
depending on the type of data to receive from the server.

On the server side, the DataInputStream is used to receive inputs from the client:

GHARDA INSTITUTE OF TECHNOLOGY Page 25


DataInputStream input;

try {

input = new DataInputStream(serviceSocket.getInputStream());

catch (IOException e) {

System.out.println(e);

3. Create an output stream

On the client side, an output stream must be created to send the data to the server
socket using the class PrintStream or DataOutputStream of java.io package:

PrintStream output;

try {

output = new PrintStream(MyClient.getOutputStream());

catch (IOException e) {

System.out.println(e);

The class PrintStream implements the methods for displaying Java primitive data
types values, like write and println methods. Also, one may want to use the
DataOutputStream:

DataOutputStream output;

try {

output = new DataOutputStream(MyClient.getOutputStream());

catch (IOException e) {

System.out.println(e);

GHARDA INSTITUTE OF TECHNOLOGY Page 26


The class DataOutputStream allows you to write Java primitive data types; many
of its methods write a single Java primitive type to the output stream.

On the server side, one can use the class PrintStream to send data to the client.

PrintStream output;

try {

output = new PrintStream(serviceSocket.getOutputStream());

catch (IOException e) {

System.out.println(e);

4. Closing sockets

Closing a socked is like closing a file. You have to close a socket when you do not
need it any more. The output and the input streams must be closed as well but
before closing the socket.

On the client side you have to close the input and the output streams and the socket
like below:

try {

output.close();

input.close();

MyClient.close();

catch (IOException e) {

System.out.println(e);

On the server you have to close the input and output streams and the two sockets
as follows:

GHARDA INSTITUTE OF TECHNOLOGY Page 27


try {

output.close();

input.close();

serviceSocket.close();

MyService.close();

catch (IOException e) {

System.out.println(e);

Usually, on the server side you need to close only the client socket after the client
gets served. The server socket is kept open as long as the server is running. A new
client can connect to the server on the server socket to establish a new connection,
that is, a new client socket.

GHARDA INSTITUTE OF TECHNOLOGY Page 28


Experiment No. 7
AIM: Program to demonstrate process/code migration.

SOFTWARE:

THEORY:

Motivation for Code Migration


 Load Sharing in Distributed Systems
-Long-running processes can be migrated to idle processors
 Client-server systems
- Code for data entry shipped to client system.
- If large quantities of data need to be processed, it is better to ship the data processing
component to the client.
-Dynamically configurable client software.
 Enterprise and “Desktop Grids”, e.g. SETI@home
-Computationally-intensive tasks shipped to idle PCs around the network.

GHARDA INSTITUTE OF TECHNOLOGY Page 29


GHARDA INSTITUTE OF TECHNOLOGY Page 30
GHARDA INSTITUTE OF TECHNOLOGY Page 31
Experiment No. 8
AIM: Write a distributed application using EJB

SOFTWARE:

THEORY:

Written in the Java programming language, an enterprise bean is a server-side


component that encapsulates the business logic of an application. The business logic is the
code that fulfills the purpose of the application.

Types of Enterprise Beans

Table 3-1 Summary of Enterprise Bean Types

Enterprise Bean
Purpose
Type

Session Performs a task for a client

Entity Represents a business entity object that exists in persistent storage

Acts as a listener for the Java Message Service API, processing


Message-Driven
messages asynchronously

Session Bean:

A session bean represents a single client inside the J2EE server. To access an application
that is deployed on the server, the client invokes the session bean's methods.

As its name suggests, a session bean is similar to an interactive session. A session bean
is not shared--it may have just one client, in the same way that an interactive session may have
just one user. Like an interactive session, a session bean is not persistent. When the client
terminates, its session bean appears to terminate and is no longer associated with the client.

There are two types of session beans: stateful and stateless.

1. Stateful Session Beans

The state of an object consists of the values of its instance variables. In a stateful session
bean, the instance variables represent the state of a unique client-bean session. Because the
client interacts ("talks") with its bean, this state is often called the conversational state.

GHARDA INSTITUTE OF TECHNOLOGY Page 32


The state is retained for the duration of the client-bean session. If the client removes
the bean or terminates, the session ends and the state disappears. This transient nature of the
state is not a problem, however, because when the conversation between the client and the
bean ends there is no need to retain the state.

A stateful session bean is an enterprise bean (EJB component) that acts as a server-side
extension of the client that uses it. The stateful session bean is created by a client and will
work for only that client until the client connection is dropped or the bean is explicitly
removed. The stateful session bean is EJB component that implements the
javax.ejb.SessionBean interface and is deployed with the declarative attribute "stateful".
Stateful session beans are called "stateful" because they maintain a conversational state with
the client. In other words, they have state or instance fields that can be initialized and changed
by the client with each method invocation. The bean can use the conversational state as it
process business methods invoked by the client.

Stateful session beans are usually developed to act as agents for the client, managing
the interaction of other beans and performing work on behalf of the client application. An
example is a shopping cart stateful session bean that tracks a client's product choices and can
execute a sale when requested. Below is partial example of a stateful session bean that is used
as a shopping cart.

Program:

Output:

Experiment No. 9

GHARDA INSTITUTE OF TECHNOLOGY Page 33


AIM: Write a program using CORBA to demonstrate object brokering.

SOFTWARE:

THEORY:
CORBA, which stands for Common Object Request Broker Architecture, is an
industry standard developed by the (a consortium of more than 700 companies) to aid in
distributed objects programming.
CORBA is just a specification for creating and using distributed objects;
CORBA is not a programming language. The CORBA architecture is based on the object
model. This model is derived from the abstract core object model defined by the OMG in the
Object Management Architecture Guide,
CORBA -based system is a collection of objects that isolates the requestors of
services (clients) from the providers of services (servers) by a well-defined encapsulating
interface. It is important to note that CORBA objects differ from typical programming objects
in three ways:
• CORBA objects can run on any platform.
• CORBA objects can be located anywhere on the network.
• CORBA objects can be written in any language that has IDL mapping.

CORBA ARCHITECTURE

The OMG ’s Object Management Architecture ( OMA ) tries to define the various
high-level facilities that are necessary for distributed object-oriented computing. The core of
the OMA is the Object Request Broker (ORB), a mechanism that provides object location
tranparency,communication, and activation. Based on the OMA , the CORBA specification
which provides a description of the interfaces and facilities that must be provided by
compliant ORB s was released.
CORBA is composed of five major components: ORB , IDL , dynamic invocation
interface ( DII ), interface repositories (IR), and object adapters (OA).
The CORBA specification must have software to implement it. The software that
implements the CORBA specification is called the ORB. The ORB, which is the heart of
CORBA, is responsible for all the mechanisms required to perform these tasks:

Diagram:

GHARDA INSTITUTE OF TECHNOLOGY Page 34


• Both the client and the object implementation are isolated from the ORB by an IDL
interface.
• All requests are managed by the ORB. This means that every invocation (whether it is local
or remote) of a CORBA
object is passed to an ORB. In the case of a remote invocation, however, the invocation
passed from the ORB of the client to the ORB of the object implementation.

Diagram:

Fig:A request from a client to an object implementation

.
CLIENT AND OBJECT IMPLEMENTATIONS

GHARDA INSTITUTE OF TECHNOLOGY Page 35


A distributed application consists of objects running within clients and servers. Servers
provide objects to be used by clients as well as other servers. A client of an object has access
to the object reference, which is the information needed to specify an object within an ORB;
with that access, it can invoke operations on the object. A client knows the object through an
interface, therefore the client knows nothing about how the object is implemented. A client
generally sees objects and ORB interfaces through a language mapping.

Fig: Object Management Architecture (OMA)

OBJECT SERVICES

The OMA, which is shown in figure 11.4, is the next higher level that builds upon the
CORBA architecture. The goal of the OMA is to allow applications to provide their basic
functionality through a standard interface.
CORBAservices and CORBAfacilities. CORBAservices provides basic services that
almost every object needs; this includes naming service and event service. The
CORBAfacilities provides higher-level functionality at the application level

Program:

Output:

Experiment No: 10

GHARDA INSTITUTE OF TECHNOLOGY Page 36


Aim: Write a program to create application using .Net.

What is .NET?

The .NET Framework introduces a completely new model for the programming
and deployment of applications. .NET is Microsoft's vision of "software as a
service", a development environment in which you can build, create, and deploy
your applications and the next generation of components, the ability to use the
Web rather than your own computer for various services.

The Microsoft .NET Framework is a software framework that can be


installed on computers running Microsoft Windows operating systems. It
includes a large library of coded solutions to common programming problems
and a virtual machine that manages the execution of programs written
specifically for the framework. The .NET Framework is a Microsoft offering and
is intended to be used by most new applications created for the Windows
platform.

The framework's Base Class Library provides a large range of features


including user interface, data access, database connectivity, cryptography, web
application development, numeric algorithms, and network communications.
The class library is used by programmers, who combine it with their own code
to produce applications.

Programs written for the .NET Framework execute in a software


environment that manages the program's runtime requirements. Also part of
the .NET Framework, this runtime environment is known as the Common
Language Runtime (CLR). The CLR provides the appearance of an application
virtual machine so that programmers need not consider the capabilities of the
specific CPU that will execute the program. The CLR also provides other
important services such as security, memory management, and exception
handling. The class library and the CLR together constitute the .NET
Framework.

Principal design features-

GHARDA INSTITUTE OF TECHNOLOGY Page 37


 Language Independence
The .NET Framework introduces a Common Type System, or CTS. The
CTS specification defines all possible datatypes and programming
constructs supported by the CLR and how they may or may not interact
with each other.
 Base Class Library
The Base Class Library (BCL), part of the Framework Class Library
(FCL), is a library of functionality available to all languages using
the .NET Framework. The BCL provides classes which encapsulate a
number of common functions, including file reading and writing, graphic
rendering, database interaction and XML document manipulation.
 Simplified Deployment
The .NET framework includes design features and tools that help manage
the installation of computer software to ensure that it does not interfere
with previously installed software, and that it conforms to security
requirements.
 Security
The design is meant to address some of the vulnerabilities, such as buffer
overflows, that have been exploited by malicious software.
Additionally, .NET provides a common security model for all
applications.

Program:

Output:

GHARDA INSTITUTE OF TECHNOLOGY Page 38

You might also like