Distributed Systems Project 2 Assigned: Tuesday, May 31, 2011 Due: Monday, June 13, 11:59:59 PM

Size: px

Start display at page:

Download "Distributed Systems Project 2 Assigned: Tuesday, May 31, 2011 Due: Monday, June 13, 11:59:59 PM"

Sabina Gilbert
6 years ago
Views:

1 Distributed Systems Project 2 Assigned: Tuesday, May 31, 2011 Due: Monday, June 13, 11:59:59 PM Objectives: First, the student is introduced to TCP sockets, protocol layering, state maintenance, and finite state machines. Second, the student is asked to build a web application that executes a protocol that maintains state for multiple users. Third, the student is introduced to Web Services. Web Services provide a callable interface for applications running on distributed systems. The objective is to give students hands-on experience with both SOAP based web services and REST based web services. The objective of the fourth task is to show another way to maintain state with a RESTFul approach. And finally, as in all projects this semester, this project requires you to answer a series of reflective questions concerning the solutions you have built. Your answers should clearly and accurately address the non-functional characteristics of your solution, demonstrating a nuanced comprehension of course content and explaining the technical aspects in relation to potential real-world applications. You will be asked to reflect and comment on several important characteristics of distributed systems. For this project, the non-functional characteristics that must be considered include message formatting (REST and SOAP), protocol layering and modeling, performance, reliability and interoperability. The reflection questions will be sent to you later this week. For each project task, software documentation is required. The software that you write (HTML files, Java files and so on) must contain comments that describe what each significant piece of code is intended to accomplish. Points will be deducted if code is not well documented. The graders will be asked to follow the rubric found on the course schedule. 1

On the course schedule are three Java classes that make up a small client server system. You should study each of these classes and get them running.

2 Task 1 Protocol layering and state maintenance are central issues in the study of distributed systems. In project 2, your first task is to experiment with the Knock Knock Joke protocol using Transmission Control Protocol (TCP) sockets and a finite state machine that maintains state. On the course schedule are three Java classes that make up a small client server system. You should study each of these classes and get them running. The client project will be named KnockKnockSocketClientProject and the server will be named KnockKnockSocketServerProject. The KnockKnockProtocol.java file will reside in the server project and is best viewed as a finite state machine. Your task will be to modify the KnockKnockProtocol.java file so that it tracks a simple restaurant protocol rather than a knock knock joke protocol. You should begin by running the knock knock example and studying the knock knock protocol code. You should then draw a finite state machine that models the protocol. Make the necessary changes to the KnockKnockProtocol class so that it implements a simple restaurant protocol. Draw the restaurant protocol with a finite state machine before making modifications to the knock knock protocol class. Here is an example execution of the restaurant protocol: 1) Run RestaurantServer.java Running 2) Run RestaurantClient.java Server: Would you like a menu! What? Client: What? Server: You're supposed to say Yes or No! Try again. Would you like a menu? Yes Client: Yes Server: The menu is steak ($12.43) or pasta ($8.87). Which do you prefer? Donuts Client: Donuts This is from the server once communication is established. This is from the user typing. The client echoes the input. 2

3 Server: You're supposed to say steak or pasta. Which do you prefer? Steak Client: Steak Server: Cake ($1.45) or Ice Cream ($2.0) for desert? Snow cone Client: Snow cone Server: Please choose cake or ice cream Cake Client: Cake Server: Here is your desert and your check. Please pay $13.88 and come again! <return entered by client> Client: Server: Would you like a menu! Yes Client: Yes Server: The menu is steak ($12.43) or pasta ($8.87). Which do you prefer? pasta Client: pasta Server: Cake ($1.45) or Ice Cream ($2.0) for desert? Ice cream Client: Ice cream Server: Here is your desert and your check. Please pay $10.87 and come again! <return> Client: Server: Would you like a menu! No Client: No Server: Bye. 3

4 Each new visitor to the restaurant will have a total price beginning with $0.0. Note that, under this implementation, only one visitor may visit the restaurant at a time. Be sure to include detailed comments in your protocol handling code that convinces the reader that you understand how the finite machine works. Note that no changes need to be made to the client and server only the protocol handler. This exemplifies the important system design principle of separation of concerns. Submit working client and server projects as described below. Task 2 Build a web application project named RestaurantWebAppProject using NetBeans. This web application will contain the files RestaurantServlet.java, RestaurantProtocol.java. The servlet will be accessed by a browser using the URL: port>/restaurantwebappproject/restaurantservlet The RestaurantProtocol.java file will be the exact same file as the one that you built in Task 1. On the initial visit, the servlet will create a new RestaurantProtocol object and add it to an HTTPSession object. See the course slides for an HTTPSession example. The first response will automatically return a session cookie to the browser. You should ensure that this is the case by viewing cookies in your browser. You do not need to create the cookies in your code. Glassfish will generate cookies for you when it sees that you are using HTTPSessions. Experiment and try creating new sessions by clearing old cookies. The HTTPSession object will associate a particular RestaurantProtocol object with a particular cookie. Our restaurant may now have simultaneous visitors each with their own protocol state. The servlet will first respond with the prompt "Would you like a menu?" followed by a text box. The prompt "Would you like a menu?", being sent to the browser, must be retrieved by the servlet from the RestaurantProtocol object associated with this session. When the user responds to the initial Would you like a menu? request, the same servlet is executed again. The RestaurantProtocol object associated with this user session is accessed from the HTTPSession object. This approach allows us to have several visitors at the same time. There will be a separate RestaurantProtocol object for each user. Each of these will track the state of the protocol. 4

5 Error messages will be displayed on the browser as they are generated by the protocol handler. You should experiment with more than one browser using the application at the same time. You will need either two browsers (IE and Firefox for example) or you may wish to visit the web application from a separate machine. In the latter case, you need to be connected to the internet and replace the string 'localhost' with the IP address of the web server. Task 3 The traditional web has had a huge impact on society. It is interoperable, allowing diverse systems to interact. It may be secured with protocols such as SSL. It supports concurrency and has been able to scale. With the advent of Web Service not to be confused with Web Applications, it has shown itself to be extensible. In Task 2 we worked with a web application using HTTP over TCP over IP. In this task we will work with SOAP over HTTP over TCP over IP. Again, we will allow our users to visit our restaurant. In preparation, here is a short tutorial on how we might build a simple web service using Netbeans 6.X.X and Glassfish. The resulting web service uses SOAP and WSDL. 1) File/New Project/Java Web/Web Application/PrjName/Location/ Glassfish V2/Finish 2) Right Click Project Node/New/Web Service/WSName/PkgName/Finish 3) Design/Add Operation/Provide method name, parameter names and types 4) Source/Complete details of method. 5) Right click Project Node/Deploy 6) Expand Web Services node/right Click Service name/test Web Service 7) Use the browser to test and examine input and output messages. 8) View WSDL and copy the WSDL URL to the clipboard. At this point, we can write a web service client. The client might be a stand alone application or a servlet. Here we will write a simple stand alone application. 1) File/New Project/Java/Java Application/PrjName/location/Finish 2) Right click project/new Web Service Client/WSDL URL/paste from clipboard 3) Note the Web Service Reference node in project tree. 5

6 4) Expand Web Service Reference down to desired method. 5) Drag and drop into appropriate source location. On the course schedule, there is a video by Arun Gupta showing this process. His application uses a database and Java's Persistence API. But most of the steps are the same. You might note that in Gupta's video he stops just short of writing a client. He simply tests the service with a tester web application. But since the WSDL is available, he could write a client in the language and platform of his choice. Create a new project named RestaurantWebServiceProject. Within this project create a web service named RestaurantWebService. Write a web service method with the signature: public synchronized String visit(string fromclient, String userid) We may have many simultaneous users visiting. The visit method is marked as synchronized so that only one thread may execute the code at a time. The first parameter will represent the text input from the visitor. A typical input would be "Steak". The second parameter represents the visitor s identification. This will be passed on each call on the visit method. This allows the visit method to track each visitor's progress through the restaurant protocol. In the web application (Task 2), we used cookies to do the same thing. You may assume that each call contains a unique identifier describing the caller. Perhaps this is a screen name or a log in ID. The response from the visit method is a string that represents the protocol handler's response. A typical response would be Cake ($1.45) or Ice Cream ($2.0) for desert?. Behind the scenes, the web service framework will place Cake ($1.45) or Ice Cream ($2.0) for desert? into an XML document (with tags from the SOAP standard) and this document will be placed after the headers in an HTTP response message. This HTTP response message will be written to a TCP socket. The reader is invited to describe a call to the visit method in the same manner as done here with the visit method s response. The visit method makes use of the java.util.treemap class. A TreeMap object holds a set of name value pairs. The name is the userid and the value is the protocol handler associated with the userid. In this way, the service can track simultaneous users. Write a console application in Java that allows users to visit the web service that you developed. This class will have a main routine and will be called RestaurantWebServiceClient. It will live in a project called RestaurantWebServiceClientProject. The console application (not the web service) will be executed with the command 6

7 "java RestaurantWebServiceClient userid". The execution will proceed in the same way as the original socket based solution. In order to establish a command line parameter using Netbeans, right click the project node and select properties. Select run and enter the command line arguments. This is how you can get the userid into your program. Test your solution by running more than one console at a time. Of course, each console application needs to run with its own userid. Task 4 In class, we discussed REpresentational State Transfer (REST). In this task you will rewrite the web application of Task 2 so that it uses a REST architectural style. The interaction will be the same as in Task 2. However, in REST, the application state is maintained by hypermedia. You will not make use of the code that implements the finite state machine. Instead, each state of the finite state machine will be implemented as a resource. When data from a resource (state) is extracted it will include the URI of the next appropriate state. This is the first time that this task has been assigned so it is somewhat experimental. Here are some instructions in building a REST based service: 1) New Project/Java Web/Web Application/Project name 2) Right click Project/New/Other/Web Service/RESTful Web Service from Patterns 3) Choose Simple Root Resource/Enter a package name/path and Class Name 4) In the Rest Resource Configuration wizard, choose Create Default Jersey REST servlet adapter in web.xml (due to a known bug in NB 7). 5) Change MIME TYPE to text/plain and choose defaults. 6) Edit the gettext method so that it reads 7

8 public String gettext() { return "Hello REST"; } 7) Perform a clean and build and deploy. Right click the project node and select Test Restful Web Service. Summary: Copy all your NetBeans task folders for this project and your screenshots into a folder named with your andrew id. Zip that folder, and submit it to Blackboard. The projects will be named as follows: Task 1 RestaurantSocketClientProject Holding one client source file RestaurantSocketServerProject Task 2 Holding the server code and the protocol handler RestaurantWebAppProject Task 3 Holding one servlet and the protocol handler RestaurantWebServiceProject Holding the service and the protocol handler RestaurantWebServiceClientProject Task 4 Holding only one console client RestaurantWebAppWithRESTProject 8

Session 12. RESTful Services. Lecture Objectives

Session 12. RESTful Services. Lecture Objectives Session 12 RESTful Services 1 Lecture Objectives Understand the fundamental concepts of Web services Become familiar with JAX-RS annotations Be able to build a simple Web service 2 10/21/2018 1 Reading