Java Development 2.0: Using Amazon simpledb to implement cloud storage, part 2nd

Java Development 2.0: Using Amazon simpledb to implement cloud storage, part 2nd: Implementing Simple Object persistence with SIMPLEJPA

It is easy to model domain objects for almost all types of applications using a relational framework such as Grails, but what about using SimpleDB? In part 2nd of Andrew Glover's introduction to SimpleDB's series, he introduced you to how to use SIMPLEJPA, rather than the Amazon SDK, to implement object persistence in SimpleDB cloud storage. In addition to enabling you to use simple Java™ objects for domain modeling (through JPA), SIMPLEJPA can also automatically convert basic data types to Amazon-compatible strings. You really can't find a simpler way to cloud storage than this.

In the first part of the introduction to the SimpleDB article, I introduced you to modeling the running application of a CRUD network using Amazon's own APIs. In addition to the obvious uniqueness of the way that Amazon uses strings to describe data types, except for most Java developers, you may find yourself having some doubts about the Amazon API. After all, the APIs that use relational databases are now very standard and mature-and, more importantly, they are already familiar with these technologies.

In addition, there are many relational frameworks that implement the Java persistence API. It is therefore easy and common for various RDBMS to perform domain object modeling for various types of Java applications. Once you have mastered a method, it is natural that you will have some resistance to learning new domain object modeling methods-and the good news is that when you use SimpleDB, you don't need to learn something new.

In the 2nd part of the SimpleDB article, I'll show you how to refactor the 1th part of the race application to conform to the JPA specification. We will then migrate applications to SIMPLEJPA and explore ways to make this innovative open source platform tuned to support NoSQL domain modeling and cloud-based storage, which is just as simple.

Why use SimpleDB?

Amazon's SimpleDB is a simple and highly scalable and reliable cloud-based data storage approach. Because it is essentially a/nosql,simpledb, it is both flexible and fast. As part of the Amazon Web Service family, SimpleDB uses HTTP as the underlying communication mechanism, so it can support multiple languages, including the Java language, Ruby, C #, and Perl. SimpleDB prices are also cheap: depending on the way the SimpleDB is authorized, you only need to pay for the resources you use, which is very different from the traditional way of anticipating use and space purchase authorization. As part of the emerging NoSQL, or non relational, data storage, SimpleDB is corresponding to Google's Bigtable or CouchDB, which are described in these series of articles.

Hibernate and JPA: Background overview

Many Java developers now use Hibernate (and Spring) to implement data persistence. In addition to being the first successful Open-source project, Hibernate also revolutionized the ORM domain. Before Hibernate, Java developers had to deal with complex EJB entity beans, and before that, we had to implement ORM ourselves or use products from vendors such as IBM®. Hibernate removes all the complexity and overhead of the EJB and instead uses the POJO based modeling platform that many of us now use.

The Java Persistence API (JPA) is the result of the Hibernate innovative use of POJO for data modeling methods. Now, EJB 3.0 implements the JPA Jpa,google App Engine as well. Even if you use Hibernate Entitymanager, then Hibernate itself is a JPA implementation,

Now that Java developers are increasingly familiar with using POJO to model data-centric applications, it can be said that a data store like SimpleDB should be able to provide us with a similar option. After all, it's a bit like the database, isn't it?

Data modeling with objects

To use SIMPLEJPA, we need to modify our racer and Runner objects to conform to the JPA specification. Thankfully, the JPA basics are simple: annotate the usual POJO, while the Entitymanager implementation is responsible for the other processing-no XML required.

The two main annotations used by JPA are @Entity and @Id, which specify a POJO as the persisted class, and identify its identity key, respectively. In order to convert our running application to JPA, we will also use comments from two other administrative relationships: @OneToMany and @ManyToOne.

In the 1th part of this article, I've introduced you to how to persist players and match objects. However, I didn't use objects to represent these entities-I just used Amazon's original APIs to store the properties of these two objects. If I want to model the relationship between a game and a competitor, then I can write the code shown in Listing 1:

Listing 1. A simple Race object

public　class　Race　{
　 private　String　name;
　 private　String　location;
　 private　double　distance;
　 private　List<Runner>　runners;

　 //setters　and　getters　left　out...
}

In Listing 1, I set up 4 properties for the Race object, and the last one is a contestant Collection. Next, I can create a simple Runner object (shown in Listing 2) that contains the name of each contestant (now I will try to keep it simple) and the SSN associated with the Race instance he or she participates in.

Listing 2. A simple Runner related to Race

public　class　Runner　{
　 private　String　name;
　 private　String　ssn;
　 private　Race　race;

　 //setters　and　getters　left　out...
}

As you can see from listings 1 and 2, I've logically established a many-to-many relationship between the contestants and the game. In reality, it may be more accurate to have a many-to-many relationship (a player usually participates in more than one game), but this is done for the sake of simplicity. Also, I now ignore constructors, setters, and getter. I will introduce to you later.