Software Engineering for Internet Applications - Student Community

What to do during lecturesWe try to keep our mouths shut during class meeting times (two 80-minute sessions per week). Students in 6.171 are learning to presenttheir work to other engineers and to offer on-the-fly constructivecriticism in response to an engineering presentation by others. Ifwe're talking, they're not learning these skills. At various times in thesemester, notably at the beginning of the course, the students won'thave anything to present. We might fill a meeting time with a 25-minute lecture on RDBMS fundamentals followed by a collaborativeproject in which students break up into teams to solve a datamodeling problem.At a minimum the meeting room must have one Web browserconnected to a video projector. Ideally the room will additionally haveextra Web browsers and keyboards distributed around the room, onefor every 3-6 students, and blackboards or whiteboards forcollaborative work by small teams.Here is a sample schedule, the goal of which is to drive the studentprojects to public launch as quickly as possible:• Week -3: students informed that they are accepted into theclass, thus giving them time to prepare their computingenvironments. Inform students that they ought to makesure their environment works by building at least oneWeb page that returns data queried from the RDBMS.They may simply wish to do Basics problems 1 through6.• Week 1, Meeting 1: schedule, grading standards, and otherbureaucracy relegated to handouts and a URL reference;we establish a precedent that class time is devoted toengineering. After a 5-minute "welcome to the course" inwhich we explain what we want them to learn, we give a 15-minute lecture on why online learning communities areimportant and what are the required elements for asustainable online community. To get the studentsaccustomed to the idea that they are going to be speakingup in class we pick a few examples of online communitiesfrom the public Internet and ask students to criticize thefeatures and user interface. We follow this with a 20-minuteintroduction of the RDBMS. Remind students that theymust turn in the Basics problems in one week or bedropped from the class.In this case we've used the Unix telnet command with an optionalargument specifying the port number for the target host--everythingtyped by the programmer is here indicated in bold. We typed the"GET ..." line ourselves and then hit Enter twice on the keyboard.Yahoo's first header back is "HTTP/1.0 200 OK". The HTTP statuscode of 200 means that the file was found ("OK").Don't get too lost in the detailsof the HTTP example. Thepoint is that when theconnection is over, it is over. Ifthe user follows a hyperlinkfrom the Yahoo front page toSee the HTTP standard athttp://www.w3.org/Protocols/for more information on HTTP."Photography", for example, that's a brand new HTTP request. IfYahoo is using multiple servers to operate its site, the secondrequest might go to an entirely different machine. This sounds fine forbrowsing Yahoo. But suppose you're shopping at an ecommerce sitesuch as Amazon. If you put something in your shopping cart on oneHTTP request you still want it to be there 10 clicks later. Or supposeyou've logged into photo.net on Click 23 and on Click 45 areresponding to a discussion forum posting. You don't want thephoto.net server to have forgotten your identity and demand yourusername and password again.This presents you, the engineer, with a challenge: Creating a statefuluser experience on top of a fundamentally stateless protocol.Where can you store state from request to request? Perhaps in a logfile on the Web server. The server would write down "Joe Smithwants three copies of Bus Nine to Paradise by Leo Buscaglia". Onany subsequent request by Joe Smith, the server-side script cansimply check the log and display the contents of the shopping cart. Aproblem with this idea, however, is that HTTP is anonymous. A Webserver doesn't know that it is Joe Smith connecting. The server onlyknows the IP address of the computer making the request.Sometimes this translates into a host name. If it is joe-smithsdesktop.stanford.edu,perhaps you can identify subsequent requestsfrom this IP address as coming from the same person. But what if it iscache-rr02.proxy.aol.com, one of the HTTP proxy servers connectingAmerica Online's 28 million users to the public Internet? The sameuser's next request will very likely come from a different IP address,i.e., another physical computer within AOL's racks and racks of proxymachines. The next request from cache-rr02.proxy.aol.com will verylikely come from a different person, i.e., another physical human33613