Performance-Study of Message Passing in an Event Service: Java RMI Vs. TCP Sockets

Laxminarayan Muktinutalapati


Performance
-
Study of Message Passing in an Event Service:

Java RMI Vs. TCP Sockets


Software Requirements Specification


1.0 Introduction:

This is a software requirements specification (SRS) of a system for performance study
on
message passing techniques in an event service. This section provides an overview of the
entire requirements document.


1.1

Purpose


The purpose of this SRS is to identify and define the requirements to aid in
development of the proposed system. The intende
d audience for this document
comprises the developer, in this case also the author of this document, and the
supervisory committee.


1.2

Scope


The objective of this performance study is to compare the efficiency of message
passing in an event service while us
ing both Java RMI and sockets. The effect of
varying loads
–
involving varying numbers of listeners, and rates of event firing,
etc., on the system shall be studied.


1.3

Overview


The following sections of the SRS give the overall description and specific
requi
rements of the system with reference to construction of the event service,
and the underlying assumptions and constraints.


2.0 Overall Description


This section of the SRS describes the general factors that affect the system and its
requirements. It provi
des a background for the specific requirements, which shall be
discussed in detail in the following section.


2.1 Product Perspective


This performance study simulates a distributed event service based on the
producer
-
consumer paradigm, which has been deve
loped independently in Java
for the project. The broad functionality of the service is outlined in figure
-
1
below.

Producer

Consumer

Event

Notification

Servi
ce

push(event)

push(event)

subscribe(event)

unsubscribe(event)

Figure 1: Event service


2.1.1 Design Overview


The event service consists of three main components
-

producers,
consumers, and the event notification service (hereby

referred to as the
notification service
).















In this system, the producers and consumers are typically unaware of one
another's location on the network. They connect to the notification service
that provides a channel for communication.


The p
ush
-
model of event reception is supported. Producers generate
events that are sent to the notification service. Consumers in turn, register
their interest in certain kinds of events with the notification service. As
and when it receives a particular kind o
f event, the notification service
notifies all the corresponding subscribers accordingly.


2.1.2 Message Passing Mechanisms


The interaction between the notification service and producers, and
consumers will be using both Java RMI and TCP sockets as the u
nderlying
mechanism for message passing.


2.1.3 Network Topology


The proposed system shall operate on a complete network topology, where
every node has a connection to every other node on the network. In effect,
every instance of the notification service
shall be connected to every other
notification service.


2.2 Product Functions


The three major components of the system perform various functions of which the
essential ones that deserve mentioning (see
Figure 1

in Section 2.1.1) are those
described below
.


The producers execute the following functions:



push(event): The producer makes an event available and informs the
notification service of the same


The consumers execute the following functions:



subscribe(event): Consumers express their interest in a sp
ecific event by
registering with the notification service. They expect to be notified
whenever the event of interest occurs



unsubscribe(event): When a consumer is no longer interested in a
particular event, it can stop receiving notifications regarding tha
t event’s
occurrence by sending an unsubscribe request to the notification service


The notification service executes the following functions:



push(event): When informed of a producer generating an event, the
notification service checks for any subscribers

to that event and notifies
them of the new occurrence


2.3 User Characteristics


This project requires users to have an understanding of object oriented
programming in Java, distributed event services and remote communication
between objects on a network.


2.4 Constraints


The system is being developed using Java and so it is pretty much platform
independent provided the Java 1.3 runtime is available. Any more constraints
identified in future shall be mentioned in this section.


2.5 Assumptions and depende
ncies




The system is assumed to be operating on a complete network topology.



Our model of the event service assumes that there is a predefined set of
events that the producers generate, and which the consumers are familiar
with.



Given the available resour
ces the performance tests will be conducted
such that factors like network latency and operating system scheduling
have negligible or no affect on the results.


2.6 Apportioning of requirements


This section shall be updated on identification of requiremen
ts that could help
extend the proposed system as and when such a need is felt.


3.0 Specific requirements


3.1 External interface requirements


3.1.1 User interfaces




The user shall provide a unique
id

for each instance of the notification
service. These
i
d
s shall typically be integers spaced conveniently apart



The number of producers and consumers that are required to run on the
same server as the notification service are to be specified by the user



The user shall also supply any port number if necessary


3.1.2 Hardware interfaces




For communication using RMI and sockets, the default ports would be
used unless otherwise specified


3.1.3 Software interfaces




All the software interfaces among the different components of the
system are provided using the Java
programming language


3.1.4 Communication interfaces




Message passing among producers, consumers, and notification
services shall be implemented using both Java RMI and sockets


3.2 Classes/Objects


The basic class diagram for the system is as shown in fig
ure
-
2. A description of
the major classes and their other major functions follows:


3.2.1 EventSvcImpl
–

It provides an implementation of the event
notification service. It maintains a list of the consumers keyed on the name
of the events of their interest

to be able to notify them.

Time logging for consumer notification is also done here.


3.2.2 Producer
–

It provides an implementation of the producers.
Randomly fires an event and informs the notification service of the same.


3.2.3 Consumer
–

It provides
an implementation of the consumer.
Periodically, it requests the notification service to subscribe or unsubscribe
to notification regarding a particular event.


3.2.4 Event
–

It is the generic event class that all events inherit from.

3.2.5 GenEvtListener
–

It is the generic event listener class.


3.3 Performance requirements





The different runs of the experiment shall tentatively involve three
different CIS servers



The load on each of the servers due to extraneous factors should
approximately be the same
at the time of running the experiments



Each run of the experiment shall be of set duration



The number of producers and consumers instantiated shall vary for
different runs to determine performance under varying conditions


3.4 Design constraints





To ensur
e that the experimental environment is the same for all runs,
the rate at which events are fired by the producers is restricted to a
preset number of events/min



Furthermore, at any point in time, each event shall have the same
number of subscribers



The eve
nts are all predefined and all consumers have prior knowledge
of all the events that could possibly be fired in the system


The above measures would reasonably ensure that load on the system is fairly
distributed.


3.5 Software system attributes


Due to la
ck of implementation of object serialization over sockets in versions
prior to Java 1.1, those versions shall not be considered in our system.