CompSci 237 - Spring 2019: Distributed Systems Middleware

Prof. Nalini Venkatasubramanian

Announcements: Please check this page frequently for important announcements regarding coursework- IMPORTANT

Project demos on June 12, 13 and 14. Schedule is here. 

Course Events and Schedules

Instructor Information

Nalini Venkatasubramanian (nalini@ics.uci.edu)
Office: Bren Hall 2086 
Office Hours: TBA

Yusuf Sarwar (msarwaru@ics.uci.edu)
Office: Bren Hall 2072 
Office Hours: Thursday 12:30pm - 1:30pm

Reader: Hang Thi Thu Nguyen
Email:hangn5@uci.edu
Office: 
Office hours: by appointment only

Course Description:

CompSci 237 - Distributed Systems Middleware 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.

Prerequisites:

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:  Monday/Wednesday 3:30 – 4:50pm  in SSL 270

Grading Policy:

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

Guidelines for paper summaries:

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 per paper (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.

Project proposals:

1. Each project team should consist of exactly 3 members: NO EXCEPTIONS (unless un-even number of students)!

1. Email group (student names, emails, UCINetIDs) to the grader to receive a group number. Group numbers will be posted after all names are received.
2. See the following for examples. Proposal 2013 and Project Demonstration 2013

Guidelines for survey papers:

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

Guidelines for project report:

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 https://eee.uci.edu/ (instead of sending emails)

Guidelines for project slides:

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 https://eee.uci.edu/ (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.