Introduction
Model-View-Controller (MVC) is a type of computer user interface that separates the representation of information from the user's interaction with it.[1][2] The model consists of application data and business rules, and the controller mediates input, converting it to the commands for the model or the view.[3] A view can be any output representation of the data, such as a chart or a diagram. Multiple views of the same data are possible (e.g. pie chart, tables etc.)[4]
Cloud Computing is the delivery of computing and storage capacity[5] as a service to a community of end-recipients. A cloud service has three distinct characteristics that differentiate it from traditional hosting. It is sold on demand, typically by the minute or the hour; it is elastic -- a user can have as much or as little of a service as they want at any given time; and the service is fully managed by the provider (the consumer needs nothing but a computer with Internet access).[6]
Google App Engine lets you run web applications on Google's infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it's ready to serve your users.[7]
1.1 Problem Description
This application focuses on creating a user interface that allows professors to post Google Announcements on the Google Calendars of students. The professor will have to create only one announcement, which will be posted to a group/class of students hence eliminating the need to send emails (which are dull and boring), that include the email addresses manually of each and every student belonging to a particular class.
1.2 Objectives and Scope
The application has some objectives that it needs to meet to work successfully:
Model-View-Controller pattern should be used as it allows the developer to flexibly change the architecture being used. For e.g. if the customer wants to shift to a different cloud service or the developer wants to add more security frameworks such as Spring etc, they are easily able to do so since the MVC architecture separates the view from the business logic. If the business logic changes, only the Controller part is to be changed.
The application should easily scale depending on the number of people using the Application. Google App Engine Cloud allows us to do just that. It allows for easy scalability and reliability. It does not matter if the application gets one request per second or a million requests per second, Google's infrastructure is easily able to scale.
Professors should be easily able to create announcements using the Web Interface and one Click post to the Google Calendars of the students.
1.3 Motivation
The project motivated me to create a better method of communication between the professors and the students so that they are able to exchange information in a much better fashion. For example, if an assignment has to be submitted, the teacher need not type a full email every time describing the nature of the assignment and the submission date. Instead, they should be able to create individual events pertaining to certain assignments which will then be posted on the Google Calendars of the students.
Chapter 2
Technology Used and Why
We will be using three core frameworks that will help us shape up the application:
Model View Controller (MVC)
Google App Engine (GAE)
Java Data Objects (JDO)
2.1 Model View Controller (MVC)
The concept of Model View and Controller was developed by SmallTalk programmers. More specifically, one SmallTalk programmer by the name of Trygve Reenskaug. There are three main components of the architecture:
Model
View
Controller
Model represents knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects. There should be a one-to-one correspondence between the model and it's parts on one hand, and the represented world as perceived by the owner of the model on the other hand.[8]
A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter. A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages. All these questions and messages have to be in the terminology of the model, the view will therefore have to know the semantics of the attributes of the model it represents.[8]
A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands or data. The controller receives such user output, translates it into the appropriate messages and passes these messages to one or more of the views.[8]
Fig. 2.1 Class Structure of Model View Controller
Model-View-Controller is a fundamental design pattern for the separation of user interface logic from business logic. It is important to note that both the view and the controller depend on the model. However, the model depends on neither the view nor the controller. This is one of the key benefits of separation.
2.1.1 Benefits of MVC
Supports multiple views. Because the view is separated from the model and there is no direct dependency from the model to the view, the user interface can display multiple views of the same data at the same time. For example, multiple pages in a Web application may use the same model objects. Another example is a Web application that allows the user to change the appearance of the pages. These pages display the same data from the shared model, but show it in a different way.
Accommodates change. User interface requirements tend to change more rapidly than the business rules. Users may prefer different colors, fonts, screen layouts, and levels of support for new devices such as cell phones or PDA's. Because the model does not depend upon the views, adding new types of views to the system generally does not affect the model. As a result, the scope of change is confined to the view.
2.1.2 Liabilities of MVC
Complexity. The MVC architecture introduces new levels of indirection and therefore increases the complexity of the solution slightly. It also increases the event-driven nature of the user-interface code, which can become more difficult to debug.
Cost of frequent updates. Decoupling the model from the view does not mean that developers of the model can ignore the nature of the views. For example, if the model undergoes frequent changes, it could flood the views with update requests. Some views, such as graphical displays, may take some time to render. As a result, the view may fall behind update requests. Therefore, it is important to keep the view in mind when coding the model. For example, the model could batch multiple updates into a single notification to the view.
2.2 Google App Engine
Google App Engine allows you to run your web applications on Google's infrastructure. It supports apps written in several programming languages. With App Engine's Java runtime environment, you can build your app using standard Java technologies, including the JVM, Java servlets, and the Java programming language-or any other language using a JVM-based interpreter or compiler, such as JavaScript or Ruby. App Engine also features two dedicated Python runtime environments, each of which includes a fast Python interpreter and the Python standard library. Finally, App Engine provides a Go runtime environment that runs natively compiled Go code. These runtime environments are built to ensure that your application runs quickly, securely, and without interference from other apps on the system.
With App Engine, you only pay for what you use. There are no set-up costs and no recurring fees. The resources your application uses, such as storage and bandwidth, are measured by the gigabyte, and billed at competitive rates. You control the maximum amounts of resources your app can consume, so it always stays within your budget.
App Engine costs nothing to get started. All applications can use up to 1 GB of storage and enough CPU and bandwidth to support an efficient app serving around 5 million page views a month, absolutely free. When you enable billing for your application, your free limits are raised, and you only pay for resources you use above the free levels.
2.2.1 The Application Environment
Google App Engine makes it easy to build an application that runs reliably, even under heavy load and with large amounts of data. App Engine includes the following features:
Dynamic web serving, with full support for common web technologies.
Persistent storage with queries, sorting and transactions.
Automatic scaling and load balancing.
APIs for authenticating users and sending email using Google Accounts
A fully featured local development environmental that simulates Google App Engine on your computer
Task queues for performing work outside of the scope of web request
Scheduled tasks for triggering events at specified times and regular intervals
Your application can run in one of three runtime environments: the Go environment, the Java environment, and the Python environment, which gives you a choice of Python 2.5 or Python 2.7. Each environment provides standard protocols and common technologies for web application development. For our application, we will be using Java.
2.2.2 Sandbox
Applications run in a secure environment that provides limited access to the underlying operating system. These limitations allow App Engine to distribute web requests for the application across multiple servers, and start and stop servers to meet traffic demands. The sandbox isolates your application in its own secure, reliable environment that is independent of the hardware, operating system and physical location of the web server. Examples of the limitations of the secure sandbox environment include:
An application can only access other computers on the Internet through the provided URL fetch and email services. Other computers can only connect to the application by making HTTP (or HTTPS) requests on the standard ports.
Applications cannot write to the file system in any of the runtime environments. An application can read files, but only files uploaded with the application code.
The app must use the App Engine datastore, memcache or other services for all data that persists between requests. The Python 2.7 environment allows bytecode to be read, written, and modified.
Application code only runs in response to a web request, a queued task, or a scheduled task, and must return response data within 60 seconds in any case. A request handler cannot spawn a sub-process or execute code after the response has been sent. [8]
2.2.3 The Java Runtime Environment
You can develop your application for the Java runtime environment using common Java web development tools and API standards. Your app interacts with the environment using the Java Servlet standard, and can use common web application technologies such as JavaServer Pages (JSPs).
The Java runtime environment uses Java 6. The App Engine Java SDK supports developing apps using either Java 5 or 6.
The environment includes the Java SE Runtime Environment (JRE) 6 platform and libraries. The restrictions of the sandbox environment are implemented in the JVM. An app can use any JVM bytecode or library feature, as long as it does not exceed the sandbox restrictions. For instance, bytecode that attempts to open a socket or write to a file will throw a runtime exception.
Your app accesses most App Engine services using Java standard APIs. For the App Engine datastore, the Java SDK includes implementations of the Java Data Objects(JDO) and Java Persistence API (JPA) interfaces. Your app can use the JavaMail API to send email messages with the App Engine Mail service. The java.net HTTP APIs access the App Engine URL fetch service. App Engine also includes low-level APIs for its services to implement additional adapters, or to use directly from the application.
Typically, Java developers use the Java programming language and APIs to implement web applications for the JVM. With the use of JVM-compatible compilers or interpreters, you can also use other languages to develop web applications, such as JavaScript, Ruby, or Scala.
2.2.4 Storing Your Data
The App Engine environment provides a range of options for storing your data:
â- App Engine Datastore provides a NoSQL schemaless object datastore, with a query engine and atomic transactions.
â- Google Cloud SQL provides a relational SQL database service for your App Engine application, based on the familiar MySQL RDBMS.
â- Google Cloud Storage provides a storage service for objects and files up to terabytes in size, accessible from Python and Java applications.
2.2.5 Quotas and Limits
Not only is creating an App Engine application easy, it's free! You can create an account and publish an application that people can use right away at no charge, and with no obligation. An application on a free account can use up to 1 GB of storage and up to 5 million page views a month. When you are ready for more, you can enable billing, set a maximum daily budget, and allocate your budget for each resource according to your needs.
You can register up to 10 applications per developer account.
Each app is allocated resources within limits, or "quotas." A quota determines how much of a given resource an app can use during a calendar day. In the near future, you will be able to adjust some of these quotas by purchasing additional resources.
Some features impose limits unrelated to quotas to protect the stability of the system. For example, when an application is called to serve a web request, it must issue a response within 60 seconds. If the application takes too long, the process is terminated and the server returns an error code to the user. The request timeout is dynamic, and may be shortened if a request handler reaches its timeout frequently to conserve resources.
2.3 OAuth for Java
OAuth is a protocol that allows a user to grant a third party limited permission to access a web application on her behalf, without sharing her credentials (username and password) with the third party. The third party can be a web application, or any other
application with the capability of invoking a web browser for the user, such as a desktop application or an app running on a smart phone. In the terms of the OAuth specification, the application seeking permission is the consumer, and the application providing the data is the service provider.
As users put more of their information online, it becomes increasingly useful for networked applications to access that data, even when the data is not stored in the application itself. If access to that data is restricted by a username and password, the data-consuming application (the consumer) needs a way to tell the service holding the data (the service provider) that it is acting on behalf of the user. One way to do this is for the user to give her username and password to the consumer-but with most services, this gives the consumer too much control over the user's account with the service provider, and risks exposing the user's password if the consumer has a security breach.
The OAuth protocol provides a way for a consumer to authenticate with a service provider and act on behalf of a user without the user having to give the consumer her username and password. For example, a travel application may have a feature to add an itinerary to a user's Google Calendar automatically. The travel application communicates with Google Calendar, and directs the user's browser to a Google Accounts authorization screen. The user signs in using her Google account, and tells Google Calendar that the travel application has permission to access her calendar data. The travel application can now access the user's calendar and add travel itineraries. It can do so until the user revokes this permission from her Google Accounts settings.
The complete interaction between the consumer and the service provider involves several steps (in what is called "three-legged authentication"):
To initiate access on behalf of a user, the consumer calls a web service endpoint to
get a request token for the app. This is a temporary token used solely for the authentication process. The call to get the request token includes a URL where the user's browser will be directed after authentication is complete.
The consumer directs the user's browser to the Google Accounts authorization URL with parameters, including the request token. The user signs in with her
credentials, then tells Google Accounts that the consumer is authorized to access the service provider on her behalf. Google Accounts redirects the user back to the consumer web application at the URL provided when the consumer got the request token.
The consumer calls a web service endpoint to exchange the request token for an access token.
The consumer can now call the service provider application's own web service endpoints using the access token until the user revokes access using the Google Accounts management interface, under "Change authorized websites."
The consumer can optionally register with the service provider in advance, providing a security certificate used to sign OAuth requests. A consumer need only register once with Google for all applications, including Google applications with OAuth-backed interfaces. Registration is optional for accessing service providers on App Engine, but recommended as it provides several important features.
2.3.1 OAuth for App Engine
App Engine apps can provide web service endpoints to consumers, using OAuth to authenticate users and consumers. Google Accounts handles all aspects of the OAuth protocol. The app uses the App Engine OAuth API to identify the user on whose behalf the consumer is acting for a request.
The user must have a Google account to sign in and authorize a consumer. If an app uses federated logins (OpenID), the user is sent directly to Google Accounts to sign in to authorize a consumer. Other OpenID identity providers are not supported for OAuth authentication.
The scope of an authorization, how much the consumer is allowed to access, is for all of a single app. App Engine only supports whole-app scopes, and does not support more granular scope requests. When Google Accounts prompts the user to authorize a consumer, the prompt explains that the consumer is requesting permission to access the full app.
You implement request handlers for OAuth-authorized web service endpoints just as you would any other request handler. To access the OAuth user information, you call the App
Engine OAuth API. Calling the OAuth API throws an exception if the caller is not authorized to access the app, or otherwise did not provide valid OAuth information. [17] Here is a simple example of accessing OAuth user information in a Java servlet:
import com.google.appengine.api.users.User;
import com.google.appengine.api.oauth.OAuthRequestException;
import com.google.appengine.api.oauth.OAuthService;
import com.google.appengine.api.oauth.OAuthServiceFactory;
import com.google.appengine.api.oauth.OAuthServiceFailureException;
// ...
User user = null;
try {
OAuthService oauth = OAuthServiceFactory.getOAuthService(); user = oauth.getCurrentUser();
} catch (OAuthRequestException e) {
// The consumer made an invalid OAuth request, used an
access token that was
// revoked, or did not provide OAuth information. // ...
}
2.3.2 Using OAuth 2.0 to Access Google APIs
Google APIs use the OAuth 2.0 protocol for authentication and authorization. Google supports several OAuth 2.0 flows that cover common web server, JavaScript, device, installed application, and server to server scenarios.
OAuth 2.0 is a relatively simple protocol and a developer can integrate with Google's OAuth 2.0 endpoints without too much effort. In a nutshell, you register your application with Google, redirect a browser to a URL, parse a token from the response, and send the token to the Google API you wish to access.
This article gives an overview of the OAuth 2.0 scenarios Google supports and provides links to more detailed content.
Given the security implications of getting the implementation correct, it is strongly encouraged to developers to use OAuth 2.0 libraries when interacting with Google's OAuth 2.0 endpoints.
2.3.3 Basic Steps
Applications follow the same basic pattern when accessing a Google API using OAuth 2.0. At a high level, using OAuth 2.0 to access a Google API consists of four steps:
1. Register Application
All applications that access a Google API must be registered through the APIs Console. The result of this registration process is a set of values that are known to both Google and your application (e.g. client_id, client_secret, JavaScript origins, redirect_uri, etc.). The set of values generated varies based on what type of application you are building. For example a JavaScript application does not require a secret, but a web server application does.
2. Obtain an Access Token from the Google Authorization Server
Before your application can access a Google API, it must obtain an access token that grants access to that API. A single access token may grant varying degrees of access to multiple APIs. The set of resources and operations permitted by an access token is controlled during the access token request via a variable parameter called 'scope'. Several scopes may be included in a request.
There are several ways to make this request, and they vary based on the type of application you are building. For example, a JavaScript application may request an access token using a browser redirect to Google, while an application installed on a device that has no browser uses web service requests.
The request requires the user to login to Google. After logging in, the user will see the permissions requested by the application and is asked if they are willing to grant your application those permissions. This process is called "user consent".
If the user grants permission to your application, your application will be sent an access token or an authorization code (which is used to obtain an access token). If the user does not grant permission to your application, the Google Authorization Server returns an error.
3. Send Access Token to an API
After an application has obtained an access token, it may send the access token in a request to a Google API. Access tokens are valid only for the set of operations and resources described in the token request. For example, if an access token is issued for the Google+ API, it will not grant access to the Google Contacts API. It may, however, be sent to the Google+ API multiple times for similar operations. Access tokens are sent to a Google API in the HTTP Authorization header, or as a query string parameter (if HTTP header operations are not available).
4. Refresh the Access Token (optional)
Access tokens have a limited lifetime and, in some cases, an application needs access to a Google API beyond the lifetime of a single access token. When this is the case, your application can obtain what is called a refresh token. A refresh token allows your application to obtain new access tokens.
2.3.4 Scenarios
Login
User login is clearly an essential part of most Google API access, but Google's authentication system can be used by your application as a stand-alone component. In other words, you can outsource user authentication and profile acquisition to Google.
The login sequence starts by redirecting the browser (popup, or full-page if needed) to a Google URL with a set of query string parameters. Google handles selecting the correct session (if the user has previously logged in with multiple identities), accepting and validating the user credentials and one-time-passwords (if the account requires it), obtaining consent to release basic profile information, as well as minting and returning an OAuth access token to your application.
The result of the user authentication sequence is an OAuth 2.0 access token, and you may then obtain user profile information (name, email address, verified email address, profile picture, etc.) by calling a the UserInfo Google API.
Fig. 2.3.4 Login Flow Scenario
2.4 Java Data Objects (JDO)
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the Java Community Process. The original JDO 1.0 is Java Specification Request 12 ( JSR 12), and the current JDO 2.0 is Java Specification Request 243 (JSR 243). Beginning with JDO 2.0, the development of the API and the Technology Compatibility Kit (TCK) takes place within the Apache JDO open-source project.
If you are an application programmer, you can use JDO technology to directly store your Java domain model instances into the persistent store (database). Alternatives to JDO include direct file I/O, serialization, JDBC, Enterprise JavaBeans (EJB), Bean-Managed Persistence (BMP) or Container-Managed Persistence (CMP) entity beans, and the Java Persistence API.
The Apache JDO project is focused on building the JDO API and the TCK for compatibility testing of JDO implementations. Commercial and open-source implementations of JDO, providing the APIs used by application developers and their customers, are available for relational databases, object databases, and file systems. [15]
2.4.1 JDO in App Engine
Java Data Objects (JDO) is a standard interface for storing objects containing data into a database. The standard defines interfaces for annotating Java objects, retrieving objects with queries, and interacting with a database using transactions. An application that uses the JDO interface can work with different kinds of databases without using any database- specific code, including relational databases, hierarchical databases, and object databases. As with other interface standards, JDO simplifies porting your application between different storage solutions. [16]
2.5 jQuery
jQuery is a cross-browser JavaScript Library designed to simplify the client-side scripting of HTML.
jQuery is free, open source software, dual-licensed under the MIT License for the GNU General Public License. jQuery's syntax is designed to make it easier to navigate a document, select DOM elements, create animations, handle events, and develop AJAX Applications. jQuery also provides capabilities for developers to create plug-ins on top of the JavaScript library. This enables developers to create abstractions for low-level interaction and animation, advanced effects and high-level, theme-able widgets. The modular approach to the jQuery library allows the creation of powerful dynamic web pages and web applications.
2.6 AJAX
AJAX stands for Asynchronous JavaScript and XML. It is a group of inter-related web development techniques used on the client-side to create asynchronous web applications. With AJAX, web applications can send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display of the behavior of the existing page. Data can be retrieved using the XMLHttpRequest Object. Despite the name, the use of XML is not required (JSON is used), and the requests need not be asynchronous.
2.7 Google Calendar API
The Google Calendar API lets you develop client applications that create new events, edit or delete existing events, and search for events. This document describes how to use RESTful calling style and client libraries for various programming languages (currently Java, Python, PHP, .NET and Ruby) to access and edit Google Calendar data.
The Google Calendar API allows a program to perform many of the operations available via Google Calendar web interface. Using this API, it is possible to search for and view public calendar events. Authenticated sessions can access private calendars, as well as create, edit, and delete both events and the calendars that contain them.
Sites or applications that wish to have a deeper integration with Google Calendar can leverage the Google Calendar API. Such an integration could be a web application that creates or displays Calendar data. It could be a desktop application that synchronizes a user's Calendar with an existing desktop application. It could even be a device that brings the Calendar experience to a new platform.
Google Calendar allows client applications to view and update calendar events in the form of Google Data API feeds. Your client application can use the Google Calendar
Data API to create new events, edit or delete existing events, and query for events that match particular criteria.
There are many possible uses for the Calendar Data API. For example, you can create a web front end for your group's calendar that uses Google Calendar as a back end. Or you can generate a public calendar for Google Calendar to display, based on your organization's event database. Or you can search relevant calendars to display a list of upcoming events on those calendars.
2.7.1 Authenticating to the Calendar Service
You can use the Java client library to work with either public or private feeds. Public feeds are read-only and do not require any authentication. Private feeds require that you authenticate to the calendar service. When you work with private feeds, you should use OAuth for authentication. If you're unable to use OAuth for any reason, you can use ClientLogin or AuthSub until you can transition to OAuth. The calendar service also allows authentication to a read-only private feed using magic cookie authentication. [17]
Fig. 2.7.1 Authentication for Google App Engine
2.7.2 Creating Calendar Event
The Calendar Data API allows you to create two types of events: single-occurrence events and recurring events, which are set up to repeat on a predetermined schedule.
2.7.2.1 Creating single-occurrence events
To insert a single-occurrence event into a Calendar feed, you might use the following code:
URL postUrl =
new URL("https://www.google.com/calendar/feeds/[email protected]/private/full");
CalendarEventEntry myEntry = new CalendarEventEntry();
myEntry.setTitle(new PlainTextConstruct("Tennis with Beth")); myEntry.setContent(new PlainTextConstruct("Meet for a quick lesson."));
DateTime startTime = DateTime.parseDateTime("2006-04-17T15:00:00- 08:00");
DateTime endTime = DateTime.parseDateTime("2006-04-17T17:00:00-08:00"); When eventTimes = new When();
eventTimes.setStartTime(startTime); eventTimes.setEndTime(endTime); myEntry.addTime(eventTimes);
// Send the request and receive the response:
CalendarEventEntry insertedEntry = myService.insert(postUrl, myEntry);
After setting the URL, we construct a CalendarEventEntry object; CalendarEventEntry is derived from the abstract base class BaseEntry, which is also the parent class for the Entry class, which represents an <atom:entry> element.
The CalendarEventEntry class represents the Google Calendar implementation of the Google Data API Event kind; for more information, see the Kinds document. For services other than Calendar, you might assign the returned entry to an Entry object rather than a CalendarEventEntry object.
The entry title is a TextConstruct, a class that holds text in various forms (plain text, HTML, or XHTML). The entry content is represented by a Content object, a class that can hold either plain text or other forms of content, including XML and binary data. (But the setContent method can also accept a TextConstruct.)
We're using the same CalendarService object that we created in the previous example. In this case, the method to call is insert, which sends an item to the specified insertion URL. The service returns the newly created entry, which may contain additional server- generated elements, such as an edit URL for the entry.
HTTP status codes indicating failure are thrown as exceptions. [13]
2.7.2.2 Creating quick add events
To create an event using Google Calendar's quick add feature, set the entry's content to the quick add string you'd like to use. Then call setQuickAdd on the new entry, as follows:
CalendarEventEntry myEntry = new CalendarEventEntry(); myEntry.setContent(new PlainTextConstruct("Tennis with John April 11 3pm-3:30pm"));
myEntry.setQuickAdd(true);
// Send the request and receive the response:
CalendarEventEntry insertedEntry = myService.insert(postUrl, myEntry);
The Calendar Data API lets users perform most of the operations a normal Google Calendar user can on the Google Calendar website. Google Calendar allows client applications to view and update calendar events in the form of Google data API, GData, feeds. The Calendar Data API lets users incorporate Calendar functionality into their own application or website. Users can edit calendars, create and delete events, query for events that match particular criteria, send invitations, and more.
There are many possible uses for the Calendar data API. For example, users can create a web front end for a group calendar that uses Google Calendar as a back end. Or a public calendar can be generated for Google Calendar to display, based on a company event database. Or users can search relevant calendars to display a list of upcoming events on those calendars. [13]
3. Conclusion:
Hence, we can see that the application is inclined towards shifting the educational management system to a more web oriented system that will help both professors and students to achieve their tasks in a more organized fashion.
4. Future Work:
The application can be further extended to be a full-fledged institute management system where an Administrator will handle all the events. More events such as submission of assignments, discussion forums can be added to the application
