SE442 – Principles of
Distributed Software Systems Design
Project #1 - RMI Chat
Application
20121
Overview
This project implements a simple chat application using RMI. The objective is to reverse engineer a design document given the current state of the application. It will also serve as a learning activity for RMI development we will be doing later on in the course.
Background
Your boss has just dropped a twelve year old Java RMI chat application on your desk. Simply put, it is a chat server which supports a catalog of "topics" that chat clients can post to in real time. All clients who are watching a topic receive the messages that are sent to that topic. Clients express an interest in chat messages for a topic by subscribing to a topic.
The product has been running in the field for some time without any support since the last engineer to work on the project retired three years ago. Your job is to stabilize the application by creating a design document to replace the original design artifacts that have mysteriously disappeared, or were never written in the first place. Marketing is also requesting performance benchmarking numbers that reflect the product’s throughput, response time and ability to handle load under varying conditions. Despite your pleas of replacing it with more modern technology options, your boss is insistent on keeping the product alive due to the large installed base. (Of course none of this would ever happen in the real world).
The Application
Download the chat application zip file.
There are three components (Common, Client & Server) which can be used to create three Eclipse projects in the same manner as shown in the RMI plugin tutorial.
Notes:
1. The focus of the re-engineering effort is on the chat server. There are two client implementations – a GUI (applet) and a test program (simple standalone). There is not a need to get the GUI operational unless you really want to. All testing can be done by starting with the standalone client.
2. The server uses two Java services that you may by-pass to start with:
a. JNDI – a naming service that registers the server name for client access (you can hardcode the server location in your client)
b. Dynamic class loading for stubs. To start with just place the stubs where your client can find them as we have been doing in the tutorials.
3. You are free to modify the product code as needed to get it running in your environment.
4. The key areas to focus on during performance testing include measuring how the chat design handles messaging functionality over varying operating conditions – number of clients, size of messages, etc.. This would include how messages are received and processed by the server and also how notifications are sent out to clients when topic updates become available. Consider the following:
a. Note the use of queues by the server. How does the use of message queues affect responsiveness from the client’s perspective? How would the number of queues affect performance?
b. Note the use of “worker threads” to distribute messages to all the clients that are registered to a topic. A “pool” of worker threads are running concurrently in the server with the goal of optimizing throughput. The number of worker threads is a startup parameter for the server. What conditions affect the number of worker threads in the server? Think of different design options for allocating threads. Are threads associated with clients? With topics? At the server level (client and topic independent)?
Design Document
Contents
Deliverables (see
class schedule for due date)
Examples:
Print Server UML Deployment/Component Diagram
( RMI plug-in tutorial)