Unit II - Part A

1. Architectural models
Architectural models describe a system in terms of the computational and communication tasks performed
by its computational elements; the computational elements being individual computers or aggregates of
them supported by appropriate network interconnections. Client-server and peer-to-peer are two of the most
commonly used forms of architectural model for distributed systems.
2. Fundamental models
Fundamental models take an abstract perspective in order to describe solutions to individual issues faced by
most distributed systems. Message communication over a computer network can be affected by delays, can
suffer from a variety of failures and is vulnerable to security attacks.
3. Models under Fundamental model
The interaction model deals with performance and with the difficulty of setting time limits in a distributed
system, for example for message delivery.
The failure model attempts to give a precise specification of the faults that can be exhibited by processes
and communication channels. It defines reliable communication and correct processes.
The security model discusses the possible threats to processes and communication channels. It introduces
the concept of a secure channel, which is secure against those threats.
4. Objects
Objects have been introduced to enable and encourage the use of object oriented approaches in distributed
systems. Objects are accessed via interfaces, with an associated interface definition language (or IDL)
providing a specification of the methods defined on an object.
5. Components: to over come number of significant problems has been identified with distributed objects, and
the use of component technology has emerged. Components resemble objects in that they offer problemoriented abstractions for building distributed systems and are also accessed through interfaces.
6. Web services
Web services represent the third important paradigm for the development of distributed systems. Web
services are closely related to objects and components, again taking an approach based on encapsulation of
behaviour and access through interfaces. In contrast, however, web services are intrinsically integrated into
the World Wide Web.
7. Communication paradigms
Entities communicate in a distributed system using three types of communication paradigm:
Interprocess communication;
Remote invocation;
Indirect communication.
8. Interprocess communication
Inter process communication refers to the relatively low-level support for communication between processes
in distributed systems, including message-passing primitives, direct access to the API offered by Internet
protocols (socket programming) and support for multicast communication.

9. Remote invocation
Remote invocation represents the most common communication paradigm in distributed systems, covering a
range of techniques based on a two-way exchange between communicating entities in a distributed system
and resulting in the calling of a remote operation, procedure or method.
10. Request-reply protocols
Request-reply protocols are effectively a pattern imposed on an underlying message-passing service to
support client-server computing. In particular, such protocols typically involve a pair wise exchange of
messages from client to server and then from server back to client.
11. Remote procedure calls
In RPC, procedures in processes on remote computers can be called as if they are procedures in the local
address space. The underlying RPC system then hides important aspects of distribution, including the
encoding and decoding of parameters and results, the passing of messages and the preserving of the required
semantics for the procedure call. RPC systems therefore offer (at a minimum) access and location
transparency.
12. Remote method invocation
Remote method invocation (RMI) strongly resembles remote procedure calls but in a world of distributed
objects. With this approach, a calling object can invoke a method in a remote object. As with RPC, the
underlying details are generally hidden from the user.
13. Indirect communication
Receivers are also generally aware of the identity of senders, and in most cases both parties must exist at the
same time. In contrast, a number of techniques have emerged whereby communication is indirect, through a
third entity, allowing a strong degree of decoupling between senders and receivers. In particular:
Senders do not need to know who they are sending to (space uncoupling).
Senders and receivers do not need to exist at the same time (time uncoupling).
Key techniques for indirect communication include:
o
o
o
o
o

Group communication
Publish-subscribe systems
Message queues
Tuple spaces
Distributed shared memory

14. Caching
A cache is a store of recently used data objects that is closer to one client or a particular set of clients than
the objects themselves. When a new object is received from a server it is added to the local cache store,
replacing some existing objects if necessary.
15. Mobile code
Applets are a well-known and widely used example of mobile code the user running a browser selects a
link to an applet whose code is stored on a web server; the code is downloaded to the browser and runs. An
advantage of running the downloaded code locally is that it can give good interactive response since it does
not suffer from the delays or variability of bandwidth associated with network communication.

16. Mobile agents

A mobile agent is a running program (including both code and data) that travels from one computer to
another in a network carrying out a task on someones behalf, such as collecting information, and eventually
returning with the results.
17. Omission failures
The faults classified as omission failures refer to cases when a process or communication channel fails to
perform actions that it is supposed to do.
18. Process omission failures
The chief omission failure of a process is to crash. When we say that a process has crashed we mean that it
has halted and will not execute any further steps of its program ever.
19. Arbitrary failures
The term arbitrary or Byzantine failure is used to describe the worst possible failure semantics, in which any
type of error may occur. For example, a process may set wrong values in its data items, or it may return a
wrong value in response to an invocation. An arbitrary failure of a process is one in which it arbitrarily omits
intended processing steps or takes unintended processing steps. Arbitrary failures in processes cannot be
detected by seeing whether the process responds to invocations, because it might arbitrarily omit to reply.
20. Timing failures
Timing failures are applicable in synchronous distributed systems where time limits are set on process
execution time, message delivery time and clock drift rate. Any of the timing failure may result in responses
being unavailable to clients within a specified time interval.
21. Security model
The security of a distributed system can be achieved by securing the processes and the channels used for
their interactions and by protecting the objects that they encapsulate against unauthorized access. Protection
is described in terms of objects; although the concepts apply equally well to resources of all types.
22. Authentication
The use of shared secrets and encryption provides the basis for the authentication of messages proving the
identities supplied by their senders. The basic authentication technique is to include in a message an
encrypted portion that contains enough of the contents of the message to guarantee its authenticity.
23. Three alternative approaches to external data representation
CORBAs common data representation, which is concerned with an external representation for the
structured and primitive types that can be passed as the arguments and results of remote method invocations
in CORBA. It can be used by a variety of programming languages.
Javas object serialization, which is concerned with the flattening and external data representation of any
single object or tree of objects that may need to be transmitted in a message or stored on a disk. It is for use
only by Java.
XML (Extensible Markup Language), which defines a textual format for representing structured data. It
was originally intended for documents containing textual self-describing structured data for example
documents accessible on the Web but it is now also used to represent the data sent in messages exchanged
by clients and servers in web services.

24. Network virtualization

Network virtualization is concerned with the construction of many different virtual networks over an
existing network such as the Internet. Each virtual network can be designed to support a particular
distributed application. For example, one virtual network might support multimedia streaming, as in BBC
25. Overlay networks
An overlay network is a virtual network consisting of nodes and virtual links, which sits on top of an
underlying network (such as an IP network) and offers Performance improved services.
26. Synchronous and Asynchronous data transfer
The sender and the receiver must by synchronized to exchange a message in time is synchronized message
transfer. If the communication has no blocking semantics in passing messages between a sender and receiver
then it is asynchronous data transfer and is not time dependent.
27. Components needed in implementing RPC mechanisms
The client
The client stub
The RPC Runtime
The server stub
The server
28. Responsibilities of a client stub
On receipt of a call request form the client, it packs a specification of the target procedure and their
arguments into a message and then asks the local RPC runtime to send it to the server stub. On receipt of the
result of procedure execution, it unpacks the result and passes it to the client.
29. Responsibilities of a server stub
On reception of the call request message form the local RPC runtime, the server stub unpacks it and makes s
perfectly normal call to invoke the appropriate procedure in the server. On receipt of the result of procedure
execution form the server, the server stub packs the result into a message and then asks the local RPC
runtime to send it to the client stub.
30. Methods to generate Stubs
Manually - The RPC implementer provides a set of translation functions from which a user can construct his
or her own stubs.
Automatically - This uses Interface Definition Language (IDL) to define interface between a client and
server.
31. Use of RMI registry
A remote object registry is a bootstrap naming service that is used by RMI servers on the same host to bind
remote objects to names. Clients on local and remote hosts can then look up remote objects and make remote
method invocations
32. Group communication
Group communication offers a service whereby a message is sent to a group and then this message is
delivered to all members of the group, the sender is not aware of the identities of the receivers. Group
communication is an important building block for distributed systems, and particularly reliable distributed
systems.

33. Closed and open groups

A group is said to be closed if only members of the group may multicast to it. A process in a closed group
delivers to itself any message that it multicasts to the group.
A group is open if processes outside the group may send to it. (The categories open and closed also apply
with analogous meanings to mailing lists.) Closed groups of processes are useful, for example, for
cooperating servers to send messages to one another that only they should receive. Open groups are useful,
for example, for delivering events to groups of interested processes.
34. Publish-subscribe system
A publish-subscribe system is a system where publishers publish structured events to an event service and
subscribers express interest in particular events through subscriptions which can be arbitrary patterns over
the structured events. For example, a subscriber could express an interest in all events related to textbook,
such as the availability of a new edition or updates to the related web site. The task of publish subscribe
system is to match subscriptions against published events and ensure the correct delivery of event
notifications.
35. Characteristics of publish-subscribe systems
Publish-subscribe systems have two main characteristics:
Heterogeneity: When event notifications are used as a means of communication, components in a distributed
system that were not designed to interoperate can be made to work together.
Asynchronicity: Notifications are sent asynchronously by event-generating publishers to all the subscribers
that have expressed an interest in them to prevent publishers needing to synchronize with subscribers
publishers and subscribers need to be decoupled.
36. Distributed Message queues
Distributed message queues are a further important category of indirect communication systems. Whereas
groups and publish subscribe provide a one-to-many style of communication, message queues provide a
point-to-point service using the concept of a message queue as an indirection, thus achieving the desired
properties of space and time uncoupling. They are point-to-point in that the sender places the message into a
queue, and it is then removed by a single process.
37. Distributed shared memory (DSM)
DSM is an abstraction used for sharing data between computers that do not share physical memory.
Processes access DSM by reads and updates to what appears to be ordinary memory within their address
space.

38. Distributed objects

Distributed objects as a natural evolution from three strands of activity:
In distributed systems, earlier middleware was based on the client-server model and there was a desire
for more sophisticated programming abstractions.
In programming languages, earlier work in object-oriented languages such as Simula-67 and
Smalltalk led to the emergence of more mainstream and heavily used programming languages such
as Java and C++ (languages used extensively in distributed systems).
In software engineering, significant progress was made in the development of object-oriented design
methods, leading to the emergence of the Unified Modelling Language (UML) as an industrialstandard notation for specifying (potentially distributed) object-oriented software systems.

39. Enterprise Java Beans

EJB is defined as a server-side component model because it supports the development of the classic style of
application, where potentially large numbers of clients interact with a number of services realized through
components or configuration of components. The components, which are known as beans in EJB, are intended
to capture the application (or business) logic, with EJB also supporting the separation between this application
logic and its persistent storage in a back-end database. In other words, EJB provides direct support for the threetier architecture

Unit II - Part B
1. Explain the need for System Model. List out various model and explain their significance.
2. Define Inter process Communication. Explain TCP and UDP API for internet protocols.
3. What is External data representation? Explain various approaches.
4. Illustrate and explain Multicast communication.
5. Explain the need for network virtualization and Overlay networks.
6. Explain MPI Standard with neat Diagrams.
7. Explain and Implement Remote Method Invocation using Java features
8. Write note on Request-reply protocols and Remote procedure call.
9. Write note on Group communication, Publish-subscribe systems and Message queues
10. Explain about Shared memory approaches and Distributed objects
11. Explain implementation details of Enterprise Java Beans.