Teach you how to use Google App Engine

The Java world is like a rich ecosystem of roles that involve developers, business, and (most importantly) applications, many of which have matured over the last decade. The global Java community has invested huge sums of money, time and mental work on the Java platform that have created a huge treasure trove of successful open source business tools, frameworks, and solutions.

The various inputs to the Java platform have made a subtle difference in the way Java is developed. Two important trends are rapidly changing the characteristics of Java development:

• Leverage open source tools and frameworks to build applications from top to bottom
  
  
• Renting (or borrowing) a variety of application infrastructures to manage the software lifecycle, including running the application itself

Any aspect of Java Development 2.0 that I mean is not new or revolutionary, it's just that the technology has matured to a faster, cheaper way to assemble better applications than ever before in the history of Java technology-one of the major business requirements that the world wants to achieve.

This article opens a new series that will delve into Java Development 2.0. You'll learn about building and deploying WEB applications using Amazon EC2, using Google's app Engine, leveraging CouchDB (a database called the Web), and the tools and technologies to assemble, test, and deploy applications at the lowest cost so far in the short term.

First stop: Google App Engine for Java. I'll introduce this platform through a common "Hello world" approach, and then show how to use Groovy, Java Data Objects (JDO) and Eclipse plug-in for Google App Engine to create a valid W EB application. But before we do that, let's take a quick look at the business value of Java Development 2.0.

Low speed and fast cost

Fast and inexpensive are rarely associated with Java development before. In fact, they often make people think of less serious software development-the development of small businesses with limited resources. The truth of the matter, however, is that it is a cost center for many companies (large and small), which drives businesses to maximize value while reducing it costs.

This is the stage where Java Development 2.0 plays a role. By leveraging open source tools, frameworks, and even solutions, organizations can quickly assemble applications because they don't have to write large amounts of code themselves. When I first started using Java technology for development more than 10 years ago, there were very limited tools and frameworks for developers to choose from. And these limited tools are not free. You must purchase an IDE, a database, an object-relational mapping (ORM) framework (worst of all, you might have to purchase a driver to communicate with the database), and of course you need to purchase the machine on which the application is deployed. So what now? All (and more) of what I have just listed are free and have great quality.

In addition, by borrowing infrastructure (such as the infrastructure provided by Amazon EC2 or Google App Engine), you can deploy your application at a very low cost (you previously needed to purchase the required infrastructure).

Build, Buy, or borrow: It's a new question.

Many organizations prepare a hardware inventory for running applications, such as databases, application servers, change management systems, and defect tracking tools. But in this era, the list can be thrown away, instead of using the same packages in the form of running services on other people's infrastructures.

The entire application stack that the team uses to manage the development process can be borrowed-that is, it is rented at a small cost-so that the company does not need to purchase the hardware needed to run the application. For example, you don't need to buy a machine to run a change management system (such as Subversion or Git, both are open source free products), and your team can use shared change management services like GitHub. The business that rents GitHub introduces hardware asset costs, so you need to charge a small fee to other organizations that use GIT (typically monthly per user). The principle of renting software from other providers as a service can be applied to defect tracking, test case management, and requirements management (for example, through Hosted JIRA or Pivotal Tracker).

The same principle can be applied to the underlying hardware assets (usually customized) that run other software platforms. Businesses can abandon the underlying hardware for a particular WEB application, preferring to run the application on hardware provided by Amazon, Google, or other competitors in the field. These enterprises offer the ability to rent hardware to varying degrees, which is enough to host the application. Also, these companies can manage scalability, backup, and even security. Think about it: Amazon and Google have solved these (and more) issues a long time ago, and now they're more adept at dealing with and innovating the aspects of running a software platform efficiently (it's true, face it).

For example, by using Google's App Engine, an IT company can reduce the overall cost of purchasing an infrastructure to run the required applications. And you can deploy these applications more quickly because you've considered and presented a variety of cross-cutting issues related to application deployment and management (and probably in a perfect way).

Fast and cheap no longer mean inferior. Instead, Java Development 2.0 is a strategic approach, with a reliable quality-focused process already envisaged.

Reduce your burden with Google App Engine

Google App Engine is a true platform to build and deploy Java (and Python) Web applications on Google's expensive infrastructure. No license fee is required (unless, of course, you choose to have a license for the software library you use on your infrastructure), you do not need to pay upfront costs for bandwidth or storage space. The APP Engine infrastructure is completely free at first, until you reach a storage space that uses a threshold of -500MB, quoting Google, "to provide enough CPU and bandwidth for about 5 million of page views per month." It can be said that once you reach the point where Google is starting to charge, your WEB application has clearly generated a huge amount of traffic (and benefits).

It's easy to start and run App Engine. Google even provides an Eclipse plugin that can handle almost anything for you. And the plugin contains the basic components of the Hello World servlet application, which can help you get started with this platform. In its latest DeveloperWorks article ("Google App Engine for Java: part 1th: Running! , Rick Hightower introduces you to the entire process of deploying the Hello World Application, which contains screenshots. If you haven't read Rick's article yet, you can follow the steps below:

1. Create a Google App Engine account (for free) by clicking  getting Started in the  http://code.google.com/appengine/    Under the  sign up  link.
   
   
2. download Google App Engine plug-in for from  http://code.google.com/appengine/downloads.html  Eclipse and install it. &NBSP
   
   
3. Create a new project in Eclipse by clicking the  new Web Application project  button, and in the dialog box that appears, do not tick the use Google Web Too Lkit option. Name the project and the appropriate package that you are interested in.
   
   
4. Select the item in the hierarchy and click the  deploy App Engine project  button.
   
   
5. Enter the voucher (what you used when you created the APP Engine account in step 1).
   
   
6. Associates the local project with the application ID that was generated when the app Engine account was originally created. (You can have a maximum of 10 IDs). &NBSP
   
   
7. Click the  Deploy  button. You'll see a lot of text flash in the Eclipse console (plug-ins do a lot of work in the background, including enhancing the classes needed to take advantage of Google's great data storage services). When the screen is stable (and everything works properly), you should see a "Deployment completed successfully" message. &NBSP
   
   
8. access the APP Engine Account page on Google and find the  Versions  link on the Google Dashboard. You will see your deployed version and the corresponding URL. Click the URL and click the link to the generated servlet, and you'll see a monotonous but comforting "Hello, world" plain text.

Write less code with Groovlets

You have successfully deployed your first Google app Engine application and have not written a single line of code. In fact, if you plan to take advantage of App Engine, you'll always have to write some code-but remember, you can reuse a lot of the code that you already have to make it easier to do your work. These reusable code may be some of the services Google provides (such as its data store or Google Account Services) or an open source library that is ported to Google infrastructure. Reusing other people's code means that you often just write less code-and less code means fewer flaws.

One of my favorite open source libraries (and platforms) is Groovy, which can always generate fewer lines of code to create effective applications (see Resources). The Groovy team recently released a version of the platform that can use APP Engine, allowing you to use groovlets instead of Servlets to create a valid application in the short term. Groovlets is a simple Groovy script that behaves like a servlets. Since you've implemented a servlet that can output "Hello, world," I'll show how simple it is to do the same with Groovlet (you'll see how much code Groovy can reduce).

Using the Eclipse plugin to deploy Groovlet on App Engine requires just a few simple steps:

2. Download the latest groovy template from Http://groovy.codehaus.org/Download (version 1.6.3 at the time of this writing).
   
   
4. Locate the Groovy-all-1.6.3.jar and place it in the War/web-inf/lib directory of your App Engine project. By the way, in this directory, you can place any library required by the application (I'll give some caveats later).
   
   
6. Add the contents of Listing 1 (map groovlets to the specified request) to the Web. xml file in the War/web-inf directory:
   
   Listing 1. Update the Web. xml file to support Groovlets
   

   <servlet> <servlet-name>GroovyServlet</servlet-name> <servlet-class>groovy.servlet.GroovyServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>GroovyServlet</servlet-name> <url-pattern>*.groovy</url-pattern> </servlet-mapping>

   
   
   
8. Add the Groovy directory to the Web-inf directory; This is where the groovlets is saved. In the groovy directory, create a new file named Helloworld.groovy. In this new file, enterprintln "Hello, Groovy baby!" 
   
   
10. Update the version of the application (assuming 1-1) and redeploy it. Find the appropriate URL from the Google Dashboard and open/helloworld.groovy in your browser and see groovy outputting a hip message on Google's infrastructure.

It's very simple, isn't it? All you need to do is add a groovy JAR, update the Web. xml file, create a new Groovy directory, write a groovlet, and deploy it. Do you also notice how Groovlet works with the default servlet plug-in with just one line of code? Which one do you want to write and maintain: a large class or a very small class with the same behavior?

Groovy + Java = Quickly build an effective application

Now, I'll show you how to quickly create a valid application using Groovy and Google's app Engine. I'll use a simple HTTP page, a groovlet, and a Java class that enhances JDO to persist events (in this case, triathlon). I'll keep it simple here, but you'll see that this application can evolve to include other features, and in subsequent articles in this series you will implement these features (with different infrastructure and technologies, of course).

Fast JDO

Google APP Engine provides the ability to use JDO to persist data, and JDO is a Java persistence standard (see Resources). For most Java developers, persistent data often means saving information to a relational database, but for Google, the underlying storage mechanism is its Big Table, which is not relational. That said, this doesn't matter: the details of how Google persists specific attributes are largely hidden. As you can say, you can use plain Java objects (or Groovy objects, for this article) to build an application that can store information like any other application. This is Google's approach and you must use JDO. (Hibernate is undoubtedly the most popular ORM framework for Java, but it does not apply to APP Engine).

JDO is very simple. You will create pojo-old-fashioned Java objects (which can be associated with other Java objects), and you declare them to be durable through class-level @PersistenceCapable annotations. @PersistentSpecifies the properties of the object to persist by using a comment. For example, I want to store the triathlon event (for now, I'll focus on the event instead of the various results associated with triathlon)-that is, the event has a name (the name of the triathlon), there may be a description (the type of triathlon), and a date. So far, my JDO looks like Listing 2:

Listing 2. A simple triathlon event JDO

Import Java.util.Date; Import javax.jdo.annotations.PersistenceCapable; Import javax.jdo.annotations.Persistent; Import Javax.jdo.annotations.IdentityType; @PersistenceCapable (identitytype = identitytype.application) public class Triathlon { @Persistent private date date; @Persistent private String name; @Persistent Private String description; }

Regardless of which underlying mechanism is used (that is, relational or Google's Big Table), data persistence always involves the concept of key: a way to ensure that data is unique in different ways to avoid data crashes. For example, for triathlon, its key can be the name of the triathlon. If two triathlon have the same name, then the name and date can be combined as keys. Regardless of the way you use the Google App Engine and JDO to represent keys, you must @PrimaryKey specify a key in the JDO object through annotations. You can also select some policies for how keys are generated-generated by you or Google. I'll use Google Build and keep it simple: My triathlon object's key is represented as a normal Java Long object, and I'll let Google determine the actual value by specifying a value policy. Listing 3 adds a primary key:

Listing 3. Add a primary key for triathlon JDO

Import Java.util.Date; Import Javax.jdo.annotations.IdGeneratorStrategy; Import javax.jdo.annotations.PersistenceCapable; Import javax.jdo.annotations.Persistent; Import Javax.jdo.annotations.PrimaryKey; Import Javax.jdo.annotations.IdentityType; Import Org.apache.commons.lang.builder.EqualsBuilder; Import Org.apache.commons.lang.builder.HashCodeBuilder; Import Org.apache.commons.lang.builder.ReflectionToStringBuilder; @PersistenceCapable (identitytype = identitytype.application) public class Triathlon { @PrimaryKey @Persistent (valuestrategy = idgeneratorstrategy.identity) Private Long ID; @Persistent private date date; @Persistent private String name; @Persistent Private String description; Public Triathlon (date date, string name, string description) { Super (); This.date = date; THIS.name = name; this.description = description; } ... setters and getters left out Public String toString () { Return reflectiontostringbuilder.tostring (this); } public int hashcode () { Return Hashcodebuilder.reflectionhashcode (this); } public boolean equals (Object obj) { Return Equalsbuilder.reflectionequals (this, obj); } }

As shown in Listing 3, my triathlon JDO has a key that is managed by Google infrastructure and adds some standard methods ( toString , hashCode and equals ) to help with debugging, logging in, and the proper functionality. I didn't write them myself, instead, I used the Apache Commons-lang library (see Resources). I've also added a constructor that makes it easier to create fully initialized objects than to call a number of setter methods.

I intentionally maintained the simplicity of JDO, but as you can see, there is not much content (that is, to keep it simple, I remove all relationships and ignore getter and setter methods). You only need to model the domain and then use some annotations to decorate the model, and then the rest of the work is done by Google.

After you have defined the object as persistent, the last step remains. To interact with the underlying data store, PersistenceManager This is a JDO standard class that, as its name implies, saves, updates, retrieves, and deletes objects (very similar to Hibernate objects) in an underlying data store Session . This class is created by a factory ( PersistenceManagerFactory ), which is very complex; therefore, Google recommends creating a separate object to manage a single instance of the factory (which returns a suitable one when you need it PersistenceManager ). Accordingly, I can define a simple stand-alone object to return PersistenceManager an instance, as shown in Listing 4:

Listing 4. Returns PersistenceManager a simple stand-alone object for an instance

Import Javax.jdo.JDOHelper; Import Javax.jdo.PersistenceManager; Import Javax.jdo.PersistenceManagerFactory; public class Persistencemgr { Private static final Persistencemanagerfactory instance = Jdohelper.getpersistencemanagerfactory ("transactions-optional"); Private Persistencemgr () {} public static PersistenceManager manufacture () { return Instance.getpersistencemanager (); } }

Can see that my is PersistenceMgr very simple. manufacturemethod PersistenceManagerFactory to return an instance from a single instance PersistenceManager . You'll also notice that no Google-specific code or any other code that exploits JDO is present in Listing 4-all references to standard JDO classes and interfaces.

The newly added two Java objects are in the SRC directory of my project, and I added the Commons-lang library to the War/web-inf/lib directory.

With a well-defined simple triathlon JDO POJO and convenient PersistenceMgr objects, I've got a good starting point. All I need is the ability to capture triathlon information.

Capturing data through the Web interface

Most WEB applications follow the same pattern: capturing information through HTML forms and committing them to server-side resources for processing. Of course, many other technologies are mixed in this process, but the pattern remains the same regardless of the underlying technology or infrastructure. So is Google App Engine-I've coded server-side resources to handle saved triathlon data. The rest of the job is capturing information-forms-and connecting the server side to the form. As Model-view-controller (MVC) says, I need a controller (usually a servlet); I'll use Groovlet instead, because I want to write less code.

My HTML form is very simple: all I need to do is create an HTML page, use some simple cascading Style Sheets (CSS) code to create the form, 1, look closer to WEB 2.0 than the HTML page that appeared in 1998 ：

Figure 1. A simple HTML form

As you can see from Figure 1, the form snaps to a name, description, and a date. However, the date is not simple-it is actually three attributes of a date.

Fast Groovlet

Groovlets makes it very easy to write controllers: they require less code and automatically provide the required objects. In Groovlet, you request response implicitly access HTML requests and responses, respectively, through and to objects. In my groovlet, I can request.getParameter("name") get all the properties of the submitted HTML form by calling, as shown in Listing 5:

Listing 5. Groovlets the actual operation

def triname = Request.getparameter ("Tri_name") def TRIDESC = Request.getparameter ("Tri_description") Def month = Request.getparameter ("Tri_month") Def day = Request.getparameter ("Tri_day") Def year = Request.getparameter ("Tri_year")

The previously written JDO used a Java Date object; In Listing 5, however, I handled Date three different properties. So I need an DateFormat object to convert the combination of, three, into month day year a plain Java Date , as shown in Listing 6:

Listing 6. Data formatting

def formatter = new SimpleDateFormat ("mm/dd/yyyy") def tridate = Formatter.parse ("${month}/${day}/${year}")

Finally, after getting all the parameters from the submitted HTML form, I can use the code in Listing 7 to PersistenceMgr persist them to Google's infrastructure through my JDO and the objects in Listing 4:

Listing 7. Ease of persistence with JDO

DEF triathlon = new Triathlon (tridate, Triname, Tridesc) def mgr = Persistencemgr.manufacture () try { Mgr.makepersistent (triathlon) } finally { Mgr.close () }

It's so simple! Of course, as more pages are added to my simple application (such as capturing the results of a particular triathlon), I may need to forward or redirect to another form, which captures additional information that is very similar to the wizard. Anyway, with a few short snippets, I quickly assembled a simple WEB application that could persist data to Google's infrastructure through JDO (using plain Java coding) and a groovlet (of course, using Groovy encoding). Deploying your application is simple, just specify a version in the Appengine-web.xml file and click the Deploy button.

However, this WEB application that captures only one form of the triathlon event does not attempt to implement all of the functionality, so I just deploy the application to an irregular, ubiquitous environment. I don't need to trigger a WEB container or even specify where to deploy the application. (Is it on California, on my hard drive, or on the moon?) The beauty of this is that it is not important-google is responsible for dealing with this problem. Note that all problems are resolved. And, to be sure, Google already knows how to expand globally, so that users in India have the same experience as Argentine users when viewing an application.

In summary, you do need to keep something in mind. Google's infrastructure supports Java technology, but it doesn't mean everything; If you recall a scenario that J2ME came out years ago, the limitations of App Engine might be similar in nature. In other words, not all core Java libraries and related open source libraries are supported. As mentioned earlier, Hibernate is not supported (mainly because you cannot have a relational database when using APP Engine). I also encountered some challenges when using some of the open source libraries with built-in base64 encoding (Google requires that you use its URL Fetch service). APP Engine is a platform-you have to develop it in its direction, and for now, this is a one-way process.

Conclusion

One of the founders of object-oriented programming, Alan Kay, once said, "the best way to predict the future is to achieve it." I agree with Alan Kay in this statement. No matter how others predict the future of Java technology, I think the future is already in front of you.

As you know in this article, Google App Engine is a platform for the future-let's say you try it in its sandbox. (Note that I only introduced some of the features in the sandbox; App Engine has a lot of features). If you want more flexibility (that is, you want to have a relational database and you must use Hibernate), but you also want to borrow other people's extensible infrastructure, you can use an alternative solution. Amazon's EC2 is actually a virtual server on an on-demand hybrid infrastructure.

Teach you how to use Google App Engine