Michael Cochez

Assistant Professor at Vrije Universiteit Amsterdam

Cloud computing: Paas

Goal

The goal of this exercise is to get acquainted with how application deployment can be done on cloud infrastructure. In this exercise we will use tools made available by the platform providers. Most providers create tools for deployment to their systems. Further we will try to measure the performance of the deployed applications.

Prerequisites

The first thing you need in order to complete this exercise is good nerves and the will to try out things (This is the real world). <!– Further, you will need some knowledge about git for moving code to the server (what you used for previous exercises should be sufficient, you might need to look into adding remotes, though). Then, b

–> Because of the platforms which will be used, you need to understand what Java Servlets are and what a WAR package is and looks like. For measuring performance we will be using JMeter, most information needed for this exercise can be found from Building a Web Test Plan. You could also check Google App Engine for Java from https://cloud.google.com/appengine/docs/java/.

Task

The goal is to deploy the localGDP server which was created in last week’s exercise to cloud service providers. The platform we use in this exercise is offered by Google which provides the Google App Engine (GAE). You only need to get the RESTfull interface working. Getting the SOAP interface working is possible, but is quite complicated on GAE. It is advised to use the Eclipse programming environment because providers have a plug-in, which simplifies the task.

Cleaning up last weeks code (by Friday)

Complete the code you created last week and refactor so that methods and packages have a normal name. Commit the refactored code to last weeks repo. <!– It seems easier to start afresh.

Now change to this week’s repository and remove the parts related to the SOAP localGDP server. Change to the new repo by

  1. cloning the repository
  2. adding a new remote
  3. pushing the branch to the new remote
  4. removing the old remote –>

Google App Engine

Start by installing the Google App engine plug-in into Eclipse. You will also need a Google account to create applications. Go to https://appengine.google.com/ to create a new application. Use as an application name (replace X with your group number) ties456-2014-groupX Keep the access public for your application.

Using Vaadin on GAE

The teacher managed to get the Google map working on GAE. Instruction will appear on a separate page. This is only relevant if you used Vaadin for the web interface.

Getting resource classes to work on GAE

As you might have read, GAE requires the entry point of you application to be a Servlet, while all you have for now are classes annotated with JAX-RS annotations! You cannot run the Grizzly server on GAE as you did on your local system. The solution to this is to use org.glassfish.jersey.servlet.ServletContainer (which implements Servlet) to act as a proxy for your service classes.

Concrete, you should be able to get your application running as follows:

  1. Create a GAE Web Application Project in Eclipse or use the Vaadin project if you used Vaadin for the map.
  2. Add the dependencies needed for Jersey (download). Place these and all other used libraries in /war/WEB-INF/lib/.
  3. Add your resource classes to the project.
  4. Edit the web.xml file (in /war/WEB-INF), adding the following mapping:
    <servlet>
        <servlet-name>JerseyServlet</servlet-name>
        <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
        <init-param>
        <param-name>jersey.config.server.provider.packages</param-name>
        <!-- Replace this package name with the one for your classes -->
        <param-value>fi.jyu.ties456.miselico</param-value>
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>JerseyServlet</servlet-name>
        <url-pattern>/your/path/as/you/set/it/up/*</url-pattern>
    </servlet-mapping>

After deploying, you should able to access your application from (replace X by your group number.) http://ties456-2014-groupX.appspot.com/your/path/as/you/set/it/up/lng/lat or something.

Also put the code for your map in the same project and deploy it to GAE, make it accessible from http://ties456-2014-groupX.appspot.com/. Note that you might need to register for an API key when using google maps from another host as localhost.

JMeter

With JMeter you can emulate many requests to your service and hence create a high load on your server. Try to come up with a reasonable way to measure the performance. Use this technique to measure the performance of your server running locally vs. the one on GAE. Also look at how the number of instances running on GAE reacts and how different settings for your cache affect the performance. Note that, for some strange reason, the GDP web service works now about one second slower as it used to. Document how you measured the performance, add the measurements and describe how the results compare.

It is recommended to perform these measurements in the Linux class.

Returning the task###

The finished project(s) must be uploaded to the git repository which will be made by the teacher. The repository should contain a short readme.md file which should be formatted using markdown. Also add the documentation about performance measuring and the URL to get the local GDP value for latitude 62.2320 and longitude 25.7367 to the readme file.

Hints

  1. When deploying on GAE, you can see the log by going to your applications dashboard (click on your application name from https://appengine.google.com/) and then go to Logs using the link on the left hand side of the page.
  2. If you notice an error in your log with type java.lang.IncompatibleClassChangeError, you might need to disable Use Datanucleus JDO/JPA to access the datastore from Project->Properties->Google->App Engine / Datastore . The reason for this error is that the data store code is using classes which are the same as some of the classes in the Jersey libraries except that the versions are different.
  3. Despite what you might read in multiple places, Jersey 2 should now work on AppEngine (see this resolved bug).