CompSci 237 - Spring 2017: Distributed Systems Middleware

Prof. Nalini Venkatasubramanian


Announcements: Please check this page frequently for important announcements regarding course work - IMPORTANT!

Office Hours --Prof. Venkatasubramanian will be available in her office (Bren Hall 2086) on TBA to discuss class projects etc.

  1. Please submit your paper summaries and project materials via the course dropbox in (instead of sending emails)
  2. For each paper summary set, you will summarize two papers in Reading Materials section. Each paper should be summarized in one or two pages. Please submit only a single .pdf file!
  3. Notice



    2 Form 3-person project groups by Thurs, Week 2 (Send names of 3 project members and tentative project area/title to the grader via email (kebenson -(at)- with the subject "CS237 Project Groups".)
    3 Project Proposals (1 page) are due end of Week 3
    4 1st summary set (Middleware and Distributed Systems Fundamentals, Virtual Time and Global States in Distributed Systems) is due end of Week 4 (Guidelines for paper summaries)
    5 2nd summary set (Distributed OS) is due end of Week 5
    7 Survey paper is due 5/18 (EXTENDED DEADLINE) (see Guidelines below for details)
    8 Midterm, May 25th (Thursday): material will include everything up to last Thursday's class (DCE and CORBA included). It is closed book so review all slides and notes to prepare. If we spent time covering an algorithm in class, be prepared to perform it to answer a problem!
    3rd summary set (Messaging Technologies, Fault Tolerance) is due end of Week 8 (EXTENDED DEADLINE)


Instructor Information

Nalini Venkatasubramanian (
Office: Bren Hall 2086
Office Hour: TBA


Reader:  Kyle Benson
Email: kebenson -(at)-
Office: Bren Hall 2099
Office hours: by appointment only

Course Description:

CompSci 237 - Distributed Systems discusses concepts, techniques and issues in developing distributed systems middleware that provides high performance in large scale distributed and networked environments. The course will cover existing middleware standards and solutions such as DCE, CORBA, DCOM,.NET,EJB,J2EE, XML, Web Services, cloud computing platforms and discuss their purposes, relative advantages and shortcomings. Issues in designing  middleware environments for special purpose needs (fault-tolerance, QoS, security etc.) will also be discussed.


Motivation and Goals:

Advances in networking, communication, storage and computing technologies coupled with emerging novel application areas is enabling the widespread use of large scale distributed computing systems. These systems exhibit constant evolution as new applications place specialized requirements from the computing and communication infrastructure. Many applications provide QoS (Quality of Service) parameters that define the extent to which performance specifications such as responsiveness, reliability, resource utilization, security and cost-effectiveness may be violated. These requirements are often implemented via resource management mechanisms in the middleware. Distributed middleware enables the modular connection of software components to manage the resources of an open distributed system; it can be used to constrain the global behavior of the distributed system to ensure safety while providing cost-effective utilization of resources. This course will cover issues in developing distributed systems middleware that provides distributed application requirements while ensuring effective system utilization.



Undergraduate level course in operating systems and networks. A prior course of distributed systems is desirable. Working knowledge of Java is required.



Class Schedule:

Lecture:  Tuesdays/Thursdays 12:30 – 1:50pm  in MSTB 118


Grading Policy:

  1. Homeworks (30%): 3 homeworks (paper summaries), each worth 10% each.
  2. Midterm (35%)
  3. Class Project (35%): Includes project proposal,final project demonstration and report.


  1. Each submission must summarize 2 papers selected from the topics given above in the course timeline. They should be 1-1.5 pages of text (suggested size 10-11 pt., single spaced, 1-inch margins).
  2. Please ensure you include your name and UCINetID (e.g. petera) on your SINGLE PDF FILE submitted to EEE DropBox. See the EEE DropBox for deadlines.
  3. Summaries should provide the following information about the paper in your own words:
    1. The main contributions of paper (the key problem(s), proposed techniques and approaches).
    2. Critique of approach, its advantages and its limitations.
    3. Implications to technology practice i.e. implementation feasibility in a distributed computing environment.


  1. Each project team should consist of exactly 3 members: NO EXCEPTIONS (unless un-even number of students)!
  2. Email group (student names, emails, UCINetIDs) to the grader to receive a group number. Group numbers will be posted after all names are received.
  3. See the following for examples:


Example Proposal

Proposal 2013

Example Project Demonstration

Project Demonstration 2013


  1. Each project group should submit a single PDF document to EEE DropBox. It should be about 5 pages of text (suggested size 10-11 pt., single spaced, 1-inch margins) and include AT LEAST 5 REFERENCES.
  2. Introduce the topic in question and why it is relevant.
  3. Come up with some strategy for how to categorize the research papers in this area and introduce this strategy
  4. Each category should come in a section (or subsection or subsubsection) to keep things organized
  5. Don't just list the papers as belonging to a section, but discuss how they all fit together. Try to list them in order of appearance: what did each newer paper contribute that wasn't done in the ones before?
  6. Consider and discuss future research directions that have not been addressed by the latest literature.
  7. Here are some example survey papers (you don't need to write yours just like these as it will be a lot shorter): SDN Hypervisors survey A survey of distributed deadlock detection algorithms


  1. Should be structured in this format
  2. 5-7 pages of text (suggested size 10-11 pt., single spaced, 1-inch margins)
    1. Should contain at least 10 references
    2. Desirable: scope out the problem area and classify approaches
  1. Should be submitted via the course dropbox in (instead of sending emails)


  1. Each project slides should not be more than 4-5 slides and it should have at least 1 slide for each of the following:
    1. Motivation & Goals
    2. Related Work
    3. System/Prototype/Simulation Design Specifics
    4. Testing & Evaluation Plan
  2. The name of the ppt file should be your project group id.
  1. Should be submitted via the course dropbox in (instead of sending emails)


Protocol for project demos:

  1. We will release 15-minute time slots for 10-minute demos that you can sign up for in a separate email.
  2. Before your scheduled time, submit your slides and project report to EEE DropBox.
  3. Please arrive at the room (location TBA later) at least 10-15 minutes before your scheduled time to set up. We will provide foam boards that you will pin your printed slides on.
  4. When we start your demo, hand us a printed copy of your project report.
  5. Aside from these materials, your demo will consist of ~5 minutes of you demonstrating your system in action. This can take the form of showing us your application, a working front end for your system, a live demo of your devices in action, or perhaps something as simple as an easy-to-read logging print-out of your system's functionality (e.g. show your load balancer deciding which servers serve a newly-generated request).
  6. We will then ask you several questions about how you designed and implemented your project. This includes showing us the code you wrote and how you partitioned the work among your group members, all of whom must be present during the demo. Your answers are expected to demonstrate that you fully understand the concept you chose and that you put significant effort into not only the design and implementation but also the research phase in which you considered other possibilities and settled on a final one for legitimate (as opposed to arbitrary) reasons.