From EJB 3 to AJAX
Pinaki Poddar's Blog |
May 18, 2006 6:12 PM
|
Comments (5)
From EJB 3 to AJAX
If you are not vacationing in Bhutan for last whole year, you have already known everything about AJAX - the new ergonomics of how we interact with a web page.
The sheer number of booths in JavaOne 2006 indicates that how madly everyone is in love with AJAX.
My regular work on persietnce services for Java/J2EE application is far removed
from the exciting world of polychromatic, animated web pages. All I wanted to demonstrate is
-- the basic usage of EJB 3.0 programming model with Java Persistence API, and
-- how new EJB 3.0 persistent domain model simplifies J2EE apllication development.
It soon became clear while talking to my Project Manager that we
also need a web interface to showcase new features of EJB 3.0.
If one is thinking of writing web pages in 2006, one must consider AJAX. Soon learned that AJAX pages are written in JavaScript. So the third objective became:
-- how a Java based EJB 3.0 service manifests itself on a JavaScript
based web page?
In this discussion I would answer these questions with a concrete
example. This example is based on
-- new EJB 3.0 programming model
-- Kodo Persistence Provider Runtime (version 4.0) that implements Java Persistence API
-- Direct Web Remoting (DWR) - a service that bridges Java and JavaScript.
The code base and resources to build this example is available in
Weblogic 9.2 Tech Preview that is released during JavaOne.
The following diagram shows how the example has been assembled and wired.
To explain its details, I will begin with the persistent domain model. Because,
a well-designed domain model is the bedrock of any application, J2EE or otherwise.
The object model represents a scenario where Reviewers review Items.
A typical item can be a Book, Music or a Movie.
A reviewer creates zero or more reviews.
Each review refers to its reviewer and the item being reviewed.
Also an item refers to an Artist.
Artist are Reviewer are both Person.
The foremost thing about this model is all the classes in it are declared as
POJOs -- pure, old Java objects. One does not have to inherit or implement any
de jure framework classes/interface as were the case for pre-3.0
EJB specifications. In fact, EJB 3.0 is so very much different (and hopefully
correct) approach to transactional object persistence services from its
predecessors that one could have given it a new name (say JDO,
just kidding :). But I would save those techno-political discussions for another
day.
What is the first sanity check on a domain model? Self-containement. A
well-designed model should
be self-containing i.e. the set of domain objects would relate to each other
but no other classes outside the set. In other words, if we put these objects
into a package, the package must compile without any dependency to any other
package (of course, you can import java.util.* or other core Java
classes).
What is the next check? Connectedness. One should be able to reach,
directly or indirectly, any model object from any other following references.
For example, an Item does not directly refer to Reviewers that reviewed it.
But Reviewers can be reached from Item through Reviews.
The other purpose of designing this model is to demonstrate features of
O-R Mapping supported by Java Persistence Architecture specification and also
few extended capabilities of Kodo. For example, for many typical O-R mapping
concerns, there is a particular aspect of the model that examplifies it:
How is enumerated field mapped?
-- See the field type Gender in Reviewer.
What are the different ways inheritance supported?
-- See how Item-Book-Music-Movie
inheritance hierarchy mapped in SINGLE_TABLE strategy. While
Person-Reviewer-Artist is mapped with a different TABLE_PER_CLASS strategy.
How uni-directional many-to-one relation mapped?
-- See Item and Artist. Many
items can refer to the same Artist. Artist (deliberately) does not maintain any reference to Item it created.
-- How to persist a java.awt.Image that is not inherently persistence capable?
-- See the image field in Movie class. It uses externalization feature of Kodo which is an extension of JPA specification.
The POJOs are annotated with
@Entity to denote to the Persistence Provider runtime that they
are persistence capable.
The POJOs are also annotatated with other O-R Mapping details on how their fields and
relationship would be represented in the database.
@Table(name="ITEM")
public class Item extends Serializable
Some people would not like
a Java class having a O-R mapping annotation. A Java purist may say:
what is TABLE name doing in my pure Java class?
But if one
takes a more somber attitude and concedes that data is more fundamental and
longer lasting than the Java applications, then the Java based persistent domain
models become a updatable view through which the underlying database
model is manipulated. And as it is natural for the view to know its model, so
is the Java class having an annotation of the table.
But, for those not a wee bit convinced about this argument, there are provisions
of not specifying the table (and any other O-R mapping) specifications
in the Java class but in the deployment descriptor. In fact, a common rule is
deployment descriptor always override the annotation.
The O-R mapping specification actually belongs to the Java Persistence API. It
is an comprehensive standardization of collective wisdom of leading O-R mapping
experts who designed Kodo (Patrick Linskey, Abe White), Toplink (Michael Keith)
or Hibernate (Gavin King) and many others. It is expressed in XML Schema and
available at
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd.
As we dive deeper into the discussion, we will have chances to see more O-R
mapping details. But now let us move on to describe the programming model with
new EJB 3.0. The order in which the example was developed
1. Write the persistent domain model classes
2. Write a service class ReviewService.java that will act on the model objects (e.g. create a new review to an item, get all Music sang by John Lenon with a duration more than 5 minutes) using JPA. In this context, we would discuss how to use JPA.
3. Write a service class SeedDatabase.java that will populate
a database with some sample records again using JPA.
4. Populate a database with sample records.
5. Write JUnit tests on ReviewService.java
6. Test it against the sample records
7. Write JSP pages that directly calls a method on ReviewService.java
8. Package everything into a Enterprise Application Archieve (EAR) file.
9. Deploy the EAR file into a Weblogic application server.
10. Open a browser. Go to a JSP page and test it again.
The steps look pretty much the same as before. The important difference was
I could test the entire application using JUnit tests, before I deployed it in
Weblogic server. Why is that important? Because it saved me time. The typical
write-test-debug-modify-test cycle with or without the application container
saved me time big time. Also, by the time the application is deployed, it is
verified for correctness.
I am not saying that there is no testing involved once the application is deployed
in the application server. Surely there is. But in the building phase when the
semantic correctness of the model and its operations are being verified, the
new EJB 3.0 model being POJO-based offered a tremendous reduction in development
cycle time. The post-deployment testing involves a different set of concerns --
performance scaling, distributed, secure access -- that are infrastructural
in nature. The testing of application behavior in the target deployment environment
is not about semantic correctness but more about checking the
deployment descriptors are specified correctly to the application server.
As a developer, the EJB 3.0 programming model lets you concern on the semantics
of your application which is orthogonal to the infrastructural concerns of the
application server. Good news is true decoupling of these concerns acheived in
EJB 3.0 programming model being based on POJO and JPA has made your development
cycle a lot more faster and life easier.
But what about AJAX? Few sentences above, I mentioned JSP pages as web pages.
Or is that AJAX in the title a pure marketing trick for my first blog?
Hopefully not. My next blog will be how I took by baby steps in the brave new
world of AJAX to give this EJB 3.0 sample application a responsive face on the
Web.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
This sounds interesting Pinaki - I look forward to reading the rest of this. We published an article on DWR recently on d2d.
Posted by: jonmountjoy on May 21, 2006 at 1:40 PM
-
Hi Pinaki,
Nice blog about using Java Persistence and AJAX! I was looking at the code you have made available, specifically at the persistence.xml and wondering whether it's possible to use injection of the Entity Manager in a statless session bean and to use a JTA transaction based EntityManager in a container?
Thanks
Rahul
Posted by: rahulbiswas on May 23, 2006 at 6:34 PM
-
Yes, Rahul, it is possible to inject a EntityManager. In fact, if you see the version running within Weblogic Tech Preview 9.2, there are three examples using same application semantics with three themes:
1. using direct JPA working in a RESOURCE_LOCAL transaction
2. using Session Bean working in JTA transaction and EM is injected
3. using direct JPA but invoked by a JavaScript application (AJAx style) -- without the Xml part.
I have only blogged about theme 1 and 3. But will discuss theme 2 sometime in future.
Posted by: pinaki.poddar on May 23, 2006 at 8:39 PM
-
The source code download url is invalid. Can you please provide the correct url?
Posted by: mat_sunil on September 12, 2007 at 10:35 AM
-
Just tried the link
http://dev2dev.bea.com/blog/pinaki.poddar/archive/ejax_source.zip
marked as "Download Source Code" on upper right-hand of the article:
http://dev2dev.bea.com/blog/pinaki.poddar/archive/2006/05/from_ejb_30_to_2.html
But I have heard similar complaints about missing link to other downloads in this forum. I will inform the Web masters.
Posted by: pinaki.poddar on September 12, 2007 at 10:46 AM
|
