Create rich data-centric web applications using JAX-RS, JPA, and Dojo

显示全部楼层 · 2017-9-26 13:06:30

Summary:Developing a rich application for manipulating large amounts of
data used to be the exclusive domain of desktop applications. Now it can be
done in a web application, and you don't have to be a Java?Script guru to do it.
Learn how to use the Dojo toolkit to create eye-popping, data-centric web
applications and hook them up to a back end based on the JavaEE
standards such as JAX-RS and JPA. These technologies allow you to leverage
convention over configuration principles to easily wire together complex
applications in no time at all.

千问 · 2017-9-26 13:06:30

Getting started

In this article you will develop a data-centric web application using some
of the latest server-side Java technologies and the Dojo toolkit for
creating a rich user interface. These technologies significantly reduce
the amount of code you have to write, on both the server and client sides.
Familiarity with Java and JavaScript is recommended to get the most out of
this article. You will need a Java 1.6 JDK to compile and run the code;
JDK 1.6.0_20 was used in this article. You will also need a Java Web
container; Apache Tomcat 6.0.14 was used in this article. For data persistence, any
database with a JDCB 2.0 compliant driver can be used. To keep things
simple, an embedded database, Apache Derby 10.6.1, was used. This article
uses the Java API for RESTful Web Services (JAX-RS), with Jersey
1.3 for the JAX-RS implementation. You will also use the Java Persistence
API (JPA) with Hibernate 3.5.3 for the implementation. Finally, the Dojo
toolkit 1.4 was used in this article as well. See Resources
for links to these tools.

千问 · 2017-9-26 13:06:30

Data on the fly with the Java
Persistence API

Many web applications are data centric—they present persistent data and
allow the user to create or update this data. It sounds simple enough, but
even when it comes to something as basic as reading and writing data from
a database, things can get ugly. However, the Java Persistence API (JPA)
greatly reduces the amount of tedious boilerplate code that you must
write. We will take a look at a simple example of using JPA.

In this article you will develop a simple application for managing a youth
soccer league. You will start by developing a simple data model for
keeping track of the teams in your league and the players on those teams.
You will use JPA for all access to this data. You will start with the
first of two data models, a Team. Listing 1 shows this class.

千问 · 2017-9-26 13:06:30

Listing 1. The Team data model class
@Entity
public class Team {
....
....@Id
....@GeneratedValue(strategy = GenerationType.IDENTITY)
....private long id;
....
....private String name;
....
....@OneToMany
....private Collection players;
....
// getters and setters........
}

千问 · 2017-9-26 13:06:30

Listing 2. The Player data model class
@Entity
public class Player {
....
....@Id
....@GeneratedValue(strategy = GenerationType.IDENTITY)
....private long id;
....
....private String firstName;
....
....private String lastName;
....
....private int age;
....
....@ManyToOne (cascade=CascadeType.ALL)
....private Team team;
....
// getters and setters
}

千问 · 2017-9-26 13:06:30

The Player class shown in Listing 2 is similar
to the Team class in Listing 1. It has more
fields, but again in most cases you won't need to worry about annotating
these fields. JPA will do the right thing for you. The one difference
between Listing 1 and Listing 2 is how you specify the
Player class's relationship to the
Team class. In this case you use a
@ManyToOne annotation, as there are many
Players on one Team.
Notice that you also specified a cascade policy. Take a look at some of
the JPA documentation to pick the right cascade policy for your
application. In this case, with this policy you can create a new
Team and a Player at
the same time and JPA will save both, which is convenient for your
application.

Now that you have declared your two classes, you just need to tell the JPA
runtime how to connect to your database. You do this by creating a
persistence.xml file. The JPA runtime needs to find this file and use the
metadata in it. The easiest way to do this is to put it into a /META-INF
directory that is a subdirectory of your source code (it just needs to be
in the root of the directory where your compiled classes are output). Listing 3 shows the persistence.xml file.

千问 · 2017-9-26 13:06:30

Listing 3. The persistence.xml for the soccer app
....
........org.developerworks.soccer.model.Team
........org.developerworks.soccer.model.Player
........
............
............
............
............
............
............
............
........
....

千问 · 2017-9-26 13:06:30

Looking back at Listing 1 and 2, all of the code is generic JPA code.
Actually all you ever use are JPA annotations and some of its
constants. There is nothing specific to your database or the JPA
implementation you used. As you can see from Listing 3, the
persistence.xml file is where those specific things are found. Several
excellent JPA implementations are available, including OpenJPA and
TopLink (see Resources). You have used the
venerable Hibernate, so you have several Hibernate-specific properties
that you have specified. These are mostly straightforward things like the
JDBC driver and URL, and some useful things like telling Hibernate to log
the SQL that it is executing (something you would definitely not want to
do a in a production situation, but it is great for debugging during
development).

You will also notice from Listing 3 that you are using the Apache Derby
database. In fact, you are using an embedded version of the database. So,
you do not have to separately start up your database or worry about
configuring it. Further, you have specified in the connection URL that the
database should be created automatically, and you have told Hibernate to
automatically create the schema (this is the
hibernate.hbm2ddl.auto property). So if you
just run your application, the database and the tables can all be created
for you. This is great for development, but of course you may want
different settings for a production system. Now that you have all of your
data model code created and you have enabled access through JPA, we'll
take a look at exposing this data so that a web application can take
advantage of it.

千问 · 2017-9-26 13:06:30

RESTful access to data with
JAX-RS

If you were creating this application five years ago, you would now start
creating some Java Server Pages (JSPs) or Java Server Faces (JSFs) or some
other similar templating technology. Instead of creating the UI for this
application on the server, you are going to use Dojo to create it on the
client. All you need to do is provide a way for your client-side code to
access this data using Ajax. You can still use a templating solution for
something like this, but it is much simpler to use the Java API for
RESTful Web Services (JAX-RS). Let's start by creating a class for reading
all of the Teams in the database and for
creating new Teams. Listing 4
shows such a class.

Listing 4. Data access class for Teams
@Path("/teams")
public class TeamDao {
....
....private EntityManager mgr =

DaoHelper.getInstance().getEntityManager();
....
....@GET
....@Produces("application/json")....
....public Collection getAll(){
........TypedQuery query =

mgr.createQuery("SELECT t FROM Team t", Team.class);
........return query.getResultList();
....}
....
....@POST
....@Consumes("application/x-www-form-urlencoded")
....@Produces("application/json")
....public Team createTeam(@FormParam("teamName") String teamName){
........Team team = new Team();
........team.setName(teamName);
........EntityTransaction txn = mgr.getTransaction();
........txn.begin();
........mgr.persist(team);
........txn.commit();
........return team;
....}
}

千问 · 2017-9-26 13:06:30

Listing 4 shows a class data access object class, hence the name
TeamDao. We will get to the annotations on
this class shortly, but let me first explain the data access. The class has
a reference to the JPA class EntityManager.
This is a central class in JPA and provides access to the underlying
database. For your first method that retrieves all of the teams in the
league, use the EntityManager to create a
query. The query uses JPA's query language, which is very similar to SQL.
This query simply gets all of the Teams. For
the second method, you simply create a new Team
using the name of the team that is passed in, create a transaction, save
the new team, and commit the transaction using the
EntityManager. All of this code is vanilla JPA
code, as all of these classes and interfaces are part of the base API.

Now that you understand the JPA part of Listing 4, let's talk about the
JAX-RS aspects of it. The first thing you will notice is that you use the
@Path annotation to expose this to HTTP-based
clients. The /teams string specifies the
relative path to this class. The full URL path is going to be
/SoccerOrg/resources/teams. The
/SoccerOrg will specify the path to your web
application (of course, you can configure this to be something different,
or remove this completely). The /resources part
will be used to specify a JAX-RS end point. The
/teams corresponds to the @Path annotation and
specifies which of the JAX-RS classes to use.

Next, the first method, getAll, has a
@GET annotation on it. This specifies that this
method should be invoked if an HTTP GET request
is received. Next, the method has a @Produces
annotation. This declares the MIME type of the response. In this case, you
want to produce JSON, since that is the easiest thing to use with a
JavaScript-based client.

This is all you have to do to use JAX-RS to expose this class to web
clients. However, you might be asking yourself: If this method returns a
java.util.Collection of
Team objects, how will this be sent to web
clients? The @Produces annotation
declares that you want it to be sent as JSON, but how will the JAX-RS
serialize this into JSON? It turns out that all you need to enable this is
to add one more annotation to the Team class as
shown in Listing 5.