UNIT III

Inter Process Communication: Introduction, The API for the internet protocols, External Data
Representation and Marshalling, Client-Server Communication, Group Communication, Case Study:
IPC in UNIX.
Distributed Objects and Remote Invocation: Introduction, Communication between Distributed
Objects, Remote Procedure Call, Events and Notifications, Case study-Java RMI.

What is Inter Process Communication?

In general, Inter Process Communication is a type of mechanism usually provided by the operating system (or OS). The main
aim or goal of this mechanism is to provide communications in between several processes. In short, the intercommunication
allows a process letting another process know that some event has occurred.

Definition

"Inter-process communication is used for exchanging useful information between numerous threads in one or more
processes (or programs)."

To understand inter process communication, you can consider the following given diagram that illustrates the importance of
inter-process communication:

We will now discuss some different approaches to inter-process communication which are as follows:
These are a few different approaches for Inter- Process Communication:

1. Pipes
2. Shared Memory
3. Message Queue
4. Direct Communication
5. Indirect communication
6. Message Passing
7. FIFO

To understand them in more detail, we will discuss each of them individually.

Pipe:-

The pipe is a type of data channel that is unidirectional in nature. It means that the data in this type of data channel can be
moved in only a single direction at a time. Still, one can use two-channel of this type, so that he can able to send and receive
data in two processes. Typically, it uses the standard methods for input and output. These pipes are used in all types of
POSIX systems and in different versions of window operating systems as well.

Shared Memory:-

It can be referred to as a type of memory that can be used or accessed by multiple processes simultaneously. It is primarily
used so that the processes can communicate with each other. Therefore the shared memory is used by almost all POSIX and
Windows operating systems as well.

Message Queue:-

In general, several different messages are allowed to read and write the data to the message queue. In the message queue,
the messages are stored or stay in the queue unless their recipients retrieve them. In short, we can also say that the message
queue is very helpful in inter-process communication and used by all operating systems.

To understand the concept of Message queue and Shared memory in more detail, let's take a look at its diagram given
below:

Message Passing:-

It is a type of mechanism that allows processes to synchronize and communicate with each other. However, by using the
message passing, the processes can communicate with each other without restoring the hared variables.

Usually, the inter-process communication mechanism provides two operations that are as follows:

o send (message)
 o received (message)

Direct Communication:-

In this type of communication process, usually, a link is created or established between two communicating processes.
However, in every pair of communicating processes, only one link can exist.

Indirect Communication

Indirect communication can only exist or be established when processes share a common mailbox, and each pair of these
processes shares multiple communication links. These shared links can be unidirectional or bi-directional.

FIFO:-

It is a type of general communication between two unrelated processes. It can also be considered as full-duplex, which
means that one process can communicate with another process and vice versa.

some common characteristics of inter process communication (IPC)

1. Communication Channels: IPC relies on various communication channels to facilitate data exchange between processes.
These channels can be shared memory, pipes, sockets, message queues, or even remote procedure calls (RPC).

2. Synchronization: IPC allows processes to synchronize their actions and coordinate their activities. This ensures that
processes can work together effectively and avoid conflicts when accessing shared resources.

3. Message Passing: One of the key mechanisms in IPC is message passing, where processes send and receive messages to
communicate with each other. Messages can contain data, instructions, or requests, and they are typically sent through
predefined communication channels.

4. Addressing: To establish communication between processes, each process involved in IPC needs to have a unique
identifier or address. This allows processes to send messages to specific destinations and receive messages from specific
sources.

5. Blocking vs. Non-blocking: IPC can be implemented in different ways, including blocking and non-blocking mechanisms. In
a blocking IPC, the sender process is blocked until the receiver process acknowledges the message. In contrast, non-blocking
IPC allows the sender to continue its execution without waiting for a response.

6. Error Handling: IPC mechanisms often provide error handling capabilities to deal with exceptional situations. This includes
handling message failures, timeouts, or other error conditions that may occur during the communication process.

7. Scalability: IPC should be designed to handle a large number of processes efficiently. Scalability is crucial to ensure that
the system can handle increased workloads and maintain performance even with a growing number of processes.
8. Security: IPC mechanisms should also consider security aspects, such as protecting the confidentiality and integrity of the
exchanged data. Encryption, authentication, and access control mechanisms can be implemented to ensure secure
communication between processes.

Application program interface

(Application Programming Interface)?

To make you clear with the diagram of what is API, let’s take a real-life example of an API, you can think of an API
as a waiter in a restaurant who listens to your order request, goes to the chef, takes the food items ordered and
gets back to you with the order. Also, if you want to look for the working of an API with the example, here’s
one. You’re searching for a course(let’s say DSA-Self Paced) on the XYZ website, you send a request(product
search requested) through an API, and the database searches for the course and checks if it’s available, the API is
responsible here to send your request to the database (in search of the course) and responds with the output(best
DSA courses).
What is an API?
API full form is an Application Programming Interface that is a collection of communication protocols and
subroutines used by various programs to communicate between them. A programmer can make use of various API
tools to make their program easier and simpler. Also, an API facilitates programmers with an efficient way to
develop their software programs. Thus api meaning is when an API helps two programs or applications to
communicate with each other by providing them with the necessary tools and functions. It takes the request from
the user and sends it to the service provider and then again sends the result generated from the service provider
to the desired user.
A developer extensively uses APIs in his software to implement various features by using an API call without
writing complex codes for the same. We can create an API for an operating system, database system, hardware
system, JavaScript file, or similar object-oriented files. Also, an API is similar to a GUI(Graphical User Interface)
with one major difference. Unlike GUIs, an application program interface helps software developers to access
web tools while a GUI helps to make a program easier to understand for users.
 The API for the Internet protocols

The Internet protocols rely on various APIs (Application Programming Interfaces) to facilitate
communication between networked devices and services. Here are some key APIs used in Internet protocols:

Socket API: The Socket API provides a standardized interface for networking operations at the transport
layer. It enables applications to create, configure, and manage network sockets for communication over
TCP/IP or UDP/IP protocols. Programming languages like C, C++, Java, Python, and many others provide
socket libraries for implementing network communication.

HTTP API: The Hypertext Transfer Protocol (HTTP) API defines a set of methods and status codes for
transferring hypertext documents over the Internet. Web servers and clients use the HTTP API to exchange
requests and responses, allowing users to access and interact with web resources such as web pages, images,
videos, and APIs. Libraries like libcurl in C/C++ or requests in Python provide HTTP client functionality.

RESTful API: Representational State Transfer (REST) is an architectural style for designing networked
applications, often used in conjunction with HTTP. RESTful APIs expose resources as URLs, and clients
interact with these resources using standard HTTP methods (GET, POST, PUT, DELETE). RESTful APIs
are commonly used in web services, cloud computing, and mobile app development.

WebSocket API: The WebSocket API enables bidirectional, full-duplex communication between a client and
a server over a single TCP connection. Unlike traditional HTTP, which follows a request-response model,
WebSocket allows for real-time, low-latency communication, making it suitable for applications such as
chat, online gaming, and real-time data streaming.

DNS API: The Domain Name System (DNS) API provides a mechanism for translating domain names into
IP addresses and vice versa. Applications can use DNS APIs to perform domain name resolution, query
DNS records, and manage DNS configurations programmatically. DNS libraries and utilities are available in
various programming languages for interacting with DNS servers.

SMTP API: The Simple Mail Transfer Protocol (SMTP) API defines a set of commands and responses for
sending and receiving email messages over the Internet. SMTP APIs allow applications to send emails
programmatically by connecting to an SMTP server, authenticating, and transmitting email data according to
the SMTP protocol.
FTP API: The File Transfer Protocol (FTP) API facilitates file transfer operations between a client and a
server over a network connection. FTP APIs support commands for listing directories, uploading files,
downloading files, and managing file permissions on remote FTP servers. Libraries like ftplib in Python
provide FTP client functionality.

UDP datagram communication

User Datagram Protocol (UDP)

User Datagram Protocol (UDP) is a Transport Layer protocol. UDP is a part of the Internet Protocol suite, referred to
as UDP/IP suite. Unlike TCP, it is an unreliable and connectionless protocol. So, there is no need to establish a
connection before data transfer. The UDP helps to establish low-latency and loss-tolerating connections over the
network. The UDP enables process-to-process communication.
What is User Datagram Protocol?
Though Transmission Control Protocol (TCP) is the dominant transport layer protocol used with most of the Internet
services; provides assured delivery, reliability, and much more but all these services cost us additional overhead and
latency. Here, UDP comes into the picture. For real-time services like computer gaming, voice or video
communication, and live conferences; we need UDP. Since high performance is needed, UDP permits packets to be
dropped instead of processing delayed packets. There is no error checking in UDP, so it also saves bandwidth.

UDP Header
UDP header is an 8-byte fixed and simple header, while for TCP it may vary from 20 bytes to 60 bytes. The first 8
Bytes contain all necessary header information and the remaining part consists of data. UDP port number fields are
each 16 bits long, therefore the range for port numbers is defined from 0 to 65535; port number 0 is reserved. Port
numbers help to distinguish different user requests or processes.

UDP Header
1. Source Port: Source Port is a 2 Byte long field used to identify the port number of the source.
2. Destina tion Port: It is a 2 Byte long field, used to identify the port of the destined packet.
3. Length: Length is the length of UDP including the header and the data. It is a 16-bits field.
4. Checksum: Checksum is 2 Bytes long field. It is the 16-bit one’s complement of the one’s complement sum of
the UDP header, the pseudo-header of information from the IP header, and the data, padded with zero octets at
the end (if necessary) to make a multiple of two octets.
Notes – Unlike TCP, the Checksum calculation is not mandatory in UDP. No Error control or flow control is provided
by UDP. Hence UDP depends on IP and ICMP for error reporting. Also UDP provides port numbers so that is can
differentiate between users requests.
Applications of UDP
 Used for simple request-response communication when the size of data is less and hence there is lesser
concern about flow and error control.
 It is a suitable protocol for multicasting as UDP supports packet switching.
 UDP is used for some routing update protocols like RIP(Routing Information Protocol).
 Normally used for real-time applications which can not tolerate uneven delays between sections of a
received message.
 UDP is widely used in online gaming, where low latency and high-speed communication is essential for a
good gaming experience. Game servers often send small, frequent packets of data to clients, and UDP is well
suited for this type of communication as it is fast and lightweight.
 Streaming media applications, such as IPTV, online radio, and video conferencing, use UDP to transmit real-
time audio and video data. The loss of some packets can be tolerated in these applications, as the data is
continuously flowing and does not require retransmission.
 VoIP (Voice over Internet Protocol) services, such as Skype and WhatsApp, use UDP for real-time voice
communication. The delay in voice communication can be noticeable if packets are delayed due to congestion
control, so UDP is used to ensure fast and efficient data transmission.
 DNS (Domain Name System) also uses UDP for its query/response messages. DNS queries are typically small
and require a quick response time, making UDP a suitable protocol for this application.
 DHCP (Dynamic Host Configuration Protocol) uses UDP to dynamically assign IP addresses to devices on a
network. DHCP messages are typically small, and the delay caused by packet loss or retransmission is generally
not critical for this application.
Advantages of UDP
 Speed: UDP is faster than TCP because it does not have the overhead of establishing a connection and
ensuring reliable data delivery.
 Lower latency: Since there is no connection establishment, there is lower latency and faster response time.
 Simplicity: UDP has a simpler protocol design than TCP, making it easier to implement and manage.
 Broadcast support: UDP supports broadcasting to multiple recipients, making it useful for applications such
as video streaming and online gaming.
 Smaller packet size: UDP uses smaller packet sizes than TCP, which can reduce network congestion and
improve overall network performance.
 User Datagram Protocol (UDP) is more efficient in terms of both latency and bandwidth.
Disadvantages of UDP
 No reliability: UDP does not guarantee delivery of packets or order of delivery, which can lead to missing or
duplicate data.
 No congestion control: UDP does not have congestion control, which means that it can send packets at a rate
that can cause network congestion.
 No flow control: UDP does not have flow control, which means that it can overwhelm the receiver with
packets that it cannot handle.
 Vulnerable to attacks: UDP is vulnerable to denial-of-service attacks, where an attacker can flood a network
with UDP packets, overwhelming the network and causing it to crash.
 Limited use cases: UDP is not suitable for applications that require reliable data delivery, such as email or file
transfers, and is better suited for applications that can tolerate some data loss, such as video streaming or online
gaming.
 External data representation and marshalling

External Data Representation:

Data structures are used to represent the information held in running applications. The information
consists of a sequence of bytes in messages that are moving between components in a distributed
system. So, conversion is required from the data structure to a sequence of bytes before the
transmission of data. On the arrival of the message, data should also be able to be converted back into
its original data structure.
Different types of data are handled in computers, and these types are not the same in every position
where data must be transmitted. Individual primitive data items can have a variety of data values, and
not all computers store primitive values like integers in the same order. Different architectures also
represent floating-point numbers differently. Integers are ordered in two ways, big-endian order, in
which the Most Significant Byte (MSB) is placed first, and little-endian order, in which the Most
Significant Byte (MSB) is placed last or the Least Significant Byte (LSB) is placed first. Furthermore, one
more issue is the set of codes used to represent characters. Most applications on UNIX systems use ASCII
character coding, which uses one byte per character, whereas the Unicode standard uses two bytes per
character and allows for the representation of texts in many different languages.
There should be a means to convert all of this data to a standard format so that it can be sent
successfully between computers. If the two computers are known to be of the same type, the external
format conversion can be skipped otherwise before transmission, the values are converted to an agreed-
upon external format, which is then converted to the local format on receiving. For that, values are sent
in the sender’s format, along with a description of the format, and the recipient converts them if
necessary. It’s worth noting, though, that bytes are never changed during transmission. Any data type
that can be supplied as a parameter or returned, as a result, must be able to be converted and the
individual primitive data values expressed in an accepted format to support Remote Procedure Call (RPC)
or Remote Method Invocation (RMI) mechanisms. So, an external data representation is a standard for
representing data structures and primitive values that have been agreed upon.
External data representation and marshalling are important concepts in computer science and data
communication. They involve the conversion of data from one format to another for the purpose of
storage, transmission, or interoperability between different systems.

External data representation refers to the way data is structured and encoded so that it can be stored or
transmitted in a consistent and standardized manner. Different systems may use different internal
representations for data, but when exchanging data between systems, a common external
representation is needed to ensure compatibility.

Marshalling, also known as serialization or packing, is the process of converting data from its internal
representation to an external representation, and vice versa. This is typically done when data needs to
be transmitted over a network or stored in a file. Marshalling involves encoding the data into a format
that can be easily transmitted or stored, and then decoding it back into its original format at the
receiving end.

The external representation of data can vary depending on the requirements of the system or protocol
being used. Common formats for external data representation include JSON (JavaScript Object Notation),
XML (eXtensible Markup Language), and binary formats like Protocol Buffers or MessagePack.
Marshalling is particularly important when data needs to be exchanged between systems with different
architectures, programming languages, or endianness. By using a standardized external data
representation and marshalling techniques, systems can ensure that data can be accurately interpreted
and processed by different components.

In summary, external data representation and marshalling are crucial for ensuring interoperability and
compatibility between different systems. They involve converting data from its internal representation
to a standardized external format, allowing it to be transmitted, stored, or processed by different
systems.
Unmarshalling: The converse of this process is unmarshalling, which involves reformatting the transferred
data upon arrival to recreate the original data structures at the destination.

Approaches:

There are three ways to successfully communicate between various sorts of data between computers.
1. Common Object Request Broker Architecture (CORBA):
CORBA is a specification defined by the Object Management Group (OMG) that is currently the most
widely used middleware in most distributed systems. It allows systems with diverse architectures,
operating systems, programming languages, and computer hardware to work together. It allows
software applications and their objects to communicate with one another. It is a standard for creating
and using distributed objects. It is made up of five major components. Components and their function
are given below:
 Object Request Broker (ORB): It provides a communication infrastructure for the objects to
communicate across a network.
 Interface Definition Language (IDL): It is a specification language used to provide an interface in a
software component. To exemplify, it allows communication between software components written in
C++ and Java.
 Dynamic Invocation Interface (DII): Using DII, client applications are permitted to use server
objects without even knowing their types at compile time. Here client obtains an instance of a CORBA
object and then invocation requests can be made dynamically on the corresponding object.
 Interface Repository (IR): As the name implies, interfaces can be added to the interface repository.
The purpose of IR is that a client should be able to find an object which is not known at compile-time
and information about its interface then request is made to be sent to ORB.
 Object Adapter (OA): It is used to access ORB services like object reference generation.

Data Representation in CORBA:

In CORBA (Common Object Request Broker Architecture), data representation plays a vital role in
enabling communication and interaction between distributed objects. CORBA uses a platform-
independent data representation called the Common Data Representation (CDR).
The CDR defines a standard format for encoding data, allowing objects to be transmitted and received
across different programming languages and platforms. It ensures interoperability by providing a
consistent way to represent data regardless of the underlying system architecture.
In CORBA, data types are mapped to their corresponding CDR representations. Basic data types like
integers, floats, and strings have predefined CDR encodings. Complex data types, such as structures and
arrays, are also represented using CDR.
When a client makes a request to a remote object in CORBA, the arguments and return values are
marshalled into CDR format before being transmitted over the network. At the receiving end, the CDR-
encoded data is unmarshalled and converted back into the appropriate data types.
CDR supports both binary and textual encodings. Binary CDR provides a compact representation that is
efficient for network transmission, while textual CDR is more human-readable and useful for debugging
and inspection purposes.
Overall, data representation in CORBA, through the Common Data Representation (CDR), ensures that
objects can communicate seamlessly across different programming languages and platforms by providing
a standardized format for encoding and decoding data.
Common Data Representation (CDR) is used to describe structured or primitive data types that are
supplied as arguments or results during remote invocations on CORBA distributed objects. It allows
clients and servers’ built-in computer languages to communicate with one another. To exemplify, it
converts little-endian to big-endian.
There are 15 primitive types: short (16-bit), long (32-bit), unsigned short, unsigned long, float (32-bit),
double (64-bit), char, boolean (TRUE, FALSE), octet (8-bit), and any (which can represent any basic or
constructed type), as well as a variety of composite types.
CORBA CDR Constructed Types:
Let’s have a look at Types with their representation:
 sequence: It refers to length (unsigned long) to be followed by elements in order
 string: It refers to length (unsigned long) followed by characters in order (can also have wide
characters)
 array: The elements of the array follow order and length is fixed so not specified.
 struct: in the order of declaration of components
 enumerated: It is unsigned long and here, the values are specified by the order declared.
 union: type tag followed by the selected member
Example:
struct Person {
string name;
string place;
long year;
};
Marshalling CORBA:
From the specification of the categories of data items to be transmitted in a message, Marshalling
CORBA operations can be produced automatically. CORBA IDL describes the types of data structures and
fundamental data items and provides a language/notation for specifying the types of arguments and
results of RMI methods.
2. Java’s Object Serialization:
Java Remote Method Invocation (RMI) allows you to pass both objects and primitive data values ​ ​ as
arguments and method calls. In Java, the term serialization refers to the activity of putting an object (an
instance of a class) or a set of related objects into a serial format suitable for saving to disk or sending in
a message.
Java provides a mechanism called object serialization. This allows an object to be represented as a
sequence of bytes containing information about the object’s data and the type of object and the type of
data stored in the object. After the serialized object is written to the file, it can be read from the file and
 deserialized. You can recreate an object in memory with type information and bytes that represent the
object and its data.

Moreover, objects can be serialized on one platform and deserialized on completely different platforms
as the whole process is JVM independent.
For example, the Java class equivalent to the Person struct defined in CORBA IDL might be:

 Java
import java.io.*;
public class Person implements Serializable {

public String name;

public String place;
public int phonenumber;
public void letter() {
System.out.println("Issue a letter to " + name + " " + place);
}
}

3. Extensible Markup Language (XML):

Clients communicate with web services using XML, which is also used to define the interfaces and other
aspects of web services. However, XML is utilized in a variety of different applications, including
archiving and retrieval systems; while an XML archive is larger than a binary archive, it has the advantage
of being readable on any machine. Other XML applications include the design of user interfaces and the
encoding of operating system configuration files.
In contrast to HTML, which employs a fixed set of tags, XML is extensible in the sense that users can
construct their tags. If an XML document is meant to be utilized by several applications, the tag names
must be unique.
Clients, for example, typically interface with web servers via SOAP messages. SOAP is an XML standard
with tags that web services and their customers can utilize. Because it is expected that the client and
server sharing a message have prior knowledge of the order and types of information it contains, some
external data representations (such as CORBA CDR) do not need to be self-describing. On the other hand,
XML was designed to be utilized by a variety of applications for a variety of reasons. This has been made
possible by the inclusion of tags and the usage of namespaces to specify the meaning of the tags.
Furthermore, the usage of tags allows applications to pick only the portions of a document that they
need to process.
Example:
XML definition of the Person struct:
<person id="9865">
<name>John</name>
<place>England</place>
<year>1876</year>
<!-- comment -->
</person>

Client-server communication

Client-server concept underpins distributed systems over a couple of decades. There are
two counterparts in the concept: a client and a server. In practice there are often multiple
clients and single server. Clients start communication by sending requests to the server, the
server handles them and usually returns responses back.

Request-reply communication

Sure! There are different types of client-server communication protocols that are commonly
used. Here are a few examples:

1. HTTP (Hypertext Transfer Protocol): This is the foundation of communication on the

World Wide Web. It allows clients (like web browsers) to request and receive web pages,
images, videos, and other resources from servers.

2. HTTPS (HTTP Secure): This is a secure version of HTTP that adds encryption to protect
the data exchanged between clients and servers. It's commonly used for sensitive transactions
like online banking or shopping.
 3. FTP (File Transfer Protocol): This protocol is used for transferring files between a client
and a server. It allows users to upload, download, and manage files on a remote server.

4. SMTP (Simple Mail Transfer Protocol): SMTP is used for sending and receiving email.
When you send an email, your email client acts as the client and communicates with an email
server using SMTP to deliver the message.

5. DNS (Domain Name System): DNS is not a traditional client-server protocol, but it plays a
crucial role in internet communication. It translates domain names (like snapchat.com) into IP
addresses that computers can understand. This translation is done by DNS servers.

These are just a few examples, and there are many other protocols used for specific purposes
in client-server communication. Each protocol has its own rules and specifications for how
clients and servers should interact and exchange data.

Group communication

Group Communication in distributed Systems

Communication between two processes in a distributed system is required to exchange various data, such
as code or a file, between the processes. When one source process tries to communicate with multiple
processes at once, it is called Group Communication. A group is a collection of interconnected processes
with abstraction. This abstraction is to hide the message passing so that the communication looks like a
normal procedure call. Group communication also helps the processes from different hosts to work
together and perform operations in a synchronized manner, therefore increasing the overall performance
of the system.

Types of Group Communication in a Distributed System:

 Broadcast Communication : When the host process tries to communicate with every process in a
distributed system at same time. Broadcast communication comes in handy when a common stream of
information is to be delivered to each and every process in most efficient manner possible. Since it does
not require any processing whatsoever, communication is very fast in comparison to other modes of
communication. However, it does not support a large number of processes and cannot treat a specific
process individually.
 A broadcast Communication: P1 process communicating with every process in the system
 Multicast Communication : When the host process tries to communicate with a designated group
of processes in a distributed system at the same time. This technique is mainly used to find a way to
address problem of a high workload on host system and redundant information from process in system.
Multitasking can significantly decrease time taken for message handling.

A multicast Communication: P1 process communicating with only a group of the process in the system
 Unicast Communication : When the host process tries to communicate with a single process in a
distributed system at the same time. Although, same information may be passed to multiple processes.
This works best for two processes communicating as only it has to treat a specific process only. However,
it leads to overheads as it has to find exact process and then exchange information/data.

A unicast Communication: P1 process communicating with only P3 process

Communication between Distributed
Objects
 Remote Procedure Call
• client: "stub" instead of "proxy" (same function, different names)
– local call, marshal arguments, communicate the request • server:
– dispatcher
– "stub": unmarshal arguments, communicate the results back
Events and Notifications

•Idea behind the use of events

– One object can react to a change occurring in another object
• Events
– Notifications of events: objects that represent events
• asynchronous and determined by receivers what events are
interested
– event types
• each type has attributes (information in it)
• subscription filtering: focus on certain values in the attributes (e.g.
"buy" events, but only "buy car" events) • Publish-subscribe paradigm
– publish events to send – subscribe events to receive

• Main characteristics in distributed event-based systems

– Heterogeneous: a way to standardize communication inheterogeneous
systems
• not designed to communicate directly
 – Asynchronous: notifications are sent asynchronously
• no need for a publisher to wait for each subscriber--subscribers come and
go

Dealing room system: allow dealers using computers

to see the latest information about
the market prices of the stocks they
deal in

Distributed Event Notification

• Distributed event notification

– decouple publishers from subscribers via an event service (manager)
• Architecture: roles of participating objects
– object of interest (usually changes in states are interesting)
– event
– notification
– subscriber
 – observer object (proxy) [reduce work on the object of interest]
• forwarding
• filtering of events types and content/attributes
• patterns of events (occurrence of multiple events, not just one)
• mailboxes (notifications in batch es, subscriber might not be ready) – publisher (object
of interest or observer object)
• generates event notifications

Example: Distributed Event

Notification

• Three cases
– Inside object without an observer: send notifications directly to the subscribers
– Inside object with an observer: send notification via the observer to the subscribers
– Outside object (with an observer)
1. An observer queries the object of interest in order to discover when events
occur
2. The observer sends notifications to the subscribers

• Jini

Case Study: Java RMI

Java Remote interfaces Shape and ShapeList and Java class ShapeListServant implements
interface ShapeList
Java class ShapeListServer with main and Java client of
ShapreList