Working of Google App Engine
Working of Google App Engine
Rele
The 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.
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.
App Engine provides a variety of services that enable you to perform common operations when managing your application. The following APIs are provided to access these services:
URL Fetch Applications can access resources on the Internet, such as web services or other data, using App Engine's URL fetch service. The URL fetch service retrieves web resources using the same high-speed Google infrastructure that retrieves web pages for many other Google products.
Mail Applications can send email messages using App Engine's mail service. The mail service uses Google infrastructure to send email messages.
Memcache The Memcache service provides your application with a high performance in-memory key-value cache that is accessible by multiple instances of your application. Memcache is useful for data that does not need the persistence and transactional features of the datastore, such as temporary data or data copied from the datastore to the cache for high speed access. Image Manipulation The Image service lets your application manipulate images. With this API, you can resize, crop, rotate and flip images in JPEG and PNG formats.
Development Workflow
The App Engine software development kits (SDKs) for Java, Python,
and Go each include a web server application that emulates all of the App Engine services on your local computer. Each SDK includes all of the APIs and libraries available on App Engine. The web server also simulates the secure sandbox environment, including checks for attempts to access system resources disallowed in the App Engine runtime environment. Each SDK also includes a tool to upload your application to App Engine. Once you have created your application's code, static files and configuration files, you run the tool to upload the data. The tool prompts you for your Google account email address and password. When you build a new major release of an application that is already running on App Engine, you can upload the new release as a new version. The old version will continue to serve users until you switch to the new version. You can test the new version on App Engine while the old version is still running.
Java SDK
You develop and upload Java applications for Google App Engine using the App Engine Java software development kit (SDK). The SDK includes software for a web server that you can run on your own computer to test your Java applications. The server simulates all of the App Engine services, including a local version of
the datastore, Google Accounts, and the ability to fetch URLs and send email from your computer using the App Engine APIs.
applications in the demos/ directory. The final version of the guest book application you will create in this tutorial is included under the directory guestbook/. Start the guest book demo in the development server by running the following command at a command prompt: appengine-java-sdk\bin\dev_appserver.cmd appenginejava-sdk\demos\guestbook\war The development server starts, and listens for requests on port 8080. Visit the following URL in your browser: http://localhost:8080/
Creating a Project
App Engine Java applications use the Java Servlet
standard for interacting with the web server environment. An application's files, including compiled classes, JARs, static files and configuration files, are arranged in a directory structure using the WAR standard layout for Java web applications.
all project files. A subdirectory named src/ contains the Java source code, and a subdirectory named war/ contains the complete application arranged in the WAR format. Our build process compiles the Java source files and puts the compiled classes in the appropriate location in war/.
Guestbook/ src/ ...Java source code... META-INF/ ...other configuration... war/ ...JSPs, images, data files... WEB-INF/ ...app configuration... lib/ ...JARs for libraries... classes/ ...compiled classes...
API to interact with the web server. An HTTP servlet is an application class that can process and respond to web requests. Our guest book project begins with one servlet class, a simple servlet that displays a message create the directories for the path src/guestbook/, then create the servlet class file described below.
package guestbook; import java.io.IOException; import javax.servlet.http.*; public class GuestbookServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { resp.setContentType("text/plain"); resp.getWriter().println("Hello, world"); } }
which servlet class to call using a configuration file known as the "web application deployment descriptor." This file is named web.xml, and resides in the war/WEB-INF/ directory in the WAR. WEBINF/ and web.xml are part of the servlet specification. In the directory war/WEB-INF/, a file named web.xml has the following contents:
<!DOCTYPE web-app PUBLIC "-//Oracle Corporation//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5"> <servlet> <servlet-name>guestbook</servlet-name> <servlet-class>guestbook.GuestbookServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>guestbook</servlet-name> <url-pattern>/guestbook</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.html</welcome-file> </welcome-file-list> </web-app>
figure out how to deploy and run the application. This file is named appengine-web.xml, and resides in WEB-INF/ alongside web.xml. It includes the registered ID of your application (Eclipse creates this with an empty ID for you to fill in later), the version number of your application, and lists of files that ought to be treated as static files (such as images and CSS) and resource files (such as JSPs and other application data).
In the directory war/WEB-INF/, a file named appengine-web.xml has the following contents:
you can use to test your application. The server simulates the App Engine environment and services, including sandbox restrictions, the datastore, and the services.
http://localhost:8080/guestbook
application.
Edit the appengine-web.xml file, then change the value of the <application> element to be your registered application ID. You should probably elect to use the free appspot.com domain name, and so the full URL for the application will behttp://your_app_id.appspot.com/
using the Administration Console. Once you have registered an application ID for your application, you upload it to App Engine using either the Eclipse plugin, or a command-line tool in the SDK.
Prompt
You can upload your application code and files using a
command included in the SDK named appcfg.cmd (Windows) AppCfg is a multi-purpose tool for interacting with your app on App Engine. The command takes the name of an action, the path to your app's war/ directory, and other options. To upload the app, using Windows: ..\appengine-java-sdk\bin\appcfg.cmd update
Engine. If you set up a free appspot.com domain name, the URL for your website begins with your application ID: http://your_app_id.appspot.com/