The Profile Story

Introducing the Java EE Web Profile - Part 2

     

A First Taste


The Java EE 6 Web Profile is actually so streamlined that it is possible to walk though the entire stack in the space of a few written pages. Without further ado, let's do that right now. It will give you a first-hand flavor of how the stack actually looks. Figure 2 shows a simple login page written in JSF 2. Listing 1 shows the Facelet based JSF 2 code for the page. As you might be able to gather from the <ui:composition> tag, a template stored in template.xhtml is applied to the page and contains the header and footer. Listing 2 shows the template, it's pretty simple.

Notice that the template <ui:insert> tag names match up with the <ui:define> tag names in the login page such that the content of the <ui:define> tags are placed into the template. Facelet templates are one of the more powerful things added in JSF 2. Just like templates, Facelets also allows you to define components through simple markup. Going back to the login page, notice that the page uses a component defined by the <login:loginPanel> tag. The component itself is actually a Facelet page that looks like Listing 3.

While the interface of the <login:loginPanel> component is defined in the <composite:interface> section, the implementation is defined in <composite:implementation>. The <composite:attribute> tags define the parameters to the component and the cc.attrs variable is used to reference these parameters in the component implementation. The login component references two backing beans – "credentials" and "login". While the username and password is bound to the "credentials" bean, the "login" bean actually handles the login event. Both beans are CDI managed beans. The "credentials" bean looks like Listing 4.

The credentials bean is @Named so it can be referenced from a Facelet page and is in the request scope. @NotNull and @Size are bean validation constraints. JSF automatically evaluates them when the login event is triggered and fails the submission with the specific message if needed. JPA 2 similarly automatically evaluates bean validation constraints on entities. The login bean has a little bit more going on (Listing 5).

The login event handler is named and session scoped. This is because we would need the login information throughout the session. The request scoped "credentials" bean is injected into the "login" bean so that the login entered can be checked. A back-end service, UserService, is also injected into the "login" bean. The user service is used in the login method to retrieve the user corresponding to the login. If the login succeeds, the user is forwarded to the accounts page. Note that the user is stored in an instance variable so that we can retrieve it throughout the session via the "login" bean or check for the current login state (as we do in template. xhtml). The user back-end service is an EJB stateless session bean:

 

Because the service is an EJB, it is automatically transactional, completely thread-safe and most likely pooled, so you have to do nothing to effectively use resources like database connections or JPA entity managers. Listing 5 shows how the injected user DAO looks.

 

The DAO is a plain CDI managed bean with no name and default scope (in fact, it has no annotations on it except for the @PersistenceContext annotation). An entity manager is injected into it and used as needed (it is perfectly OK since the DAO is protected by the EJB layer). The code above also shows you the newly added JPA 2 criteria query facility. As you can guess, User is a JPA entity. Listing 7 shows how it looks.

As you can see, the entity is mapped to a table named USERS. Like the credentials bean, it also has bean validation constraints. Lastly, thanks to CDI, Java EE 6 embedded containers and tools like JBoss Arquillian can unit test any layer of your application. Here is some code to show you how an Arquillian JUnit test for the user service might look:

As you can see, the actual EJB can be injected right into the unit test using Arquillian. Because of the embedded container, everything is seamless and self-contained. No external application server needs to be running and there is no deployment process to go through!

 

Believe it or not, we just toured through the entire Java EE 6 Web Profile stack including JSF 2, CDI, EJB 3.1, JPA 2 and bean validation! Obviously, this is a very small tip of a very, very large iceberg and each API at each layer has a lot more features to explore.

Web Profile Implementations

There are a number of Java EE 6 web profile implementations currently available or actively underway including GlassFish, JBoss AS and Resin. Here are some details on each:

• GlassFish: GlassFish has both a Web Profile and Full Profile offering. Because GlassFish is the reference implementation, it strictly adheres to the Java EE 6 Web Profile and does not add any additional APIs. However, because GlassFish is based on OSGi, you can use the GlassFish console update center to dynamically add any other Java EE API you need – often without a restart!

• Resin: Resin is the only major open source application server solely focused on the Web Profile. Although most people think of Resin as a fast, reliable Servlet container, Resin has been more than just a Servlet container for a long time. For example, Resin has had database connection pooling, clustering, load-balancing and Hessian based remoting for years. In fact, Resin embraced EJB 3 with Resin 3. The problem was that because of backwards compatibility requirements in EJB 3, it was still necessary to fully implement EJB 2 and RMI/CORBA remoting. Due to the absence of profiles, Resin would have also been forced to support bloated APIs like JAX-RPC, JAXR, SAAJ, JACC, JAAS, JASPIC and the like. With CDI and the Web Profile, the Resin team has been an enthusiastic supporter of Java EE 6 and Resin 4 now passes the Java EE 6 Web Profile TCK. Besides the Java EE 6 Web Profile APIs, Resin 4 includes JMS as well as almost the entire EJB API except for EJB 2 and RMI/CORBA support. Resin also allows you to use all EJB service annotations in plain CDI managed beans and includes a Resin optimized JUnit test framework. Resin supports JAX-WS, JAX-RS and Java-Mail as additional plug-ins.

• JBoss AS: JBoss will offer both a Web Profile and full profile implementation. The Web Profile implementation is currently available.

• Others: Geronimo is very close to finishing the Java EE 6 Web Profile and will also offer a full profile server. Web Logic 11g R2 will support both the full and Web Profile

- it's planned for calendar year 2011. SIwpas is a Tomcat based open source Java EE 6 Web Profile offering leveraging Apache projects from a Turkish company MechSoft.

– they have not pursued certification yet. TomEE is another Tomcat based open source Java EE 6 Web Profile leveraging Apache projects, from the Apache OpenEJB folks – they have not pursued certification yet either. TomEE adds Java-Mail, JCA, JMS, JAX-WS and JAX-RS to the Web Profile.

There are bound to be other offerings on the table as time progresses for the Java EE 6 Web Profile, including possibly one from OW2.

Summary

The Java EE 6 Web Profile truly streamlines the platform and enables the creation of a simple, lightweight, compelling, cohesive set of next-generation application servers for painless web application development. There are a number of Web Profile choices available today with more on the way. If you have not done so yet, you really should give the Java EE 6 Web Profile a spin!

Pages

Reza Rahman
Reza Rahman

What do you think?

JAX Magazine - 2014 - 05 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions