Modern Web Component Development with Java EE6 and Arquillian

Outline

• About Me
  • Chris Bredesen  – Product Manager, Red Hat Customer Portal
• Agenda
  • Brief History
  • CDI
  • Arquillian
  • Anatomy of an EE6 application
  • Informal audience survey – Spring / Seam / EE 5/6 usage?
• J2EE 1.4
  • InitialContext ctx = …..
  • No DI; JNDI gave us a registry
  • Clients look up what’s needed (“traditional” control structure)
• Java EE 5
  • Limited (but well-defined!) component types…
  • @Stateless / Stateful
  • …that can be injected into other EE 5 components
  • @EJB
  • @Resource
  • @PersistenceContext
• Seam 1.x & 2.x
  • Leverages EE rather than sidestepping it
    • Introduced what was to become the CDI “programming model”
    • Somewhat tightly coupled with JSF 1 & a web container
    • Annotation-based component declaration
    • Events
    • Stateful/Conversational model that optionally uses EJB3
  • Rich web framework
    • MVC (both pull- and push-style)
    • Security
    • Persistence
    • Localization
    • Greatly improves JSF’s navigation rules (far less verbose and limited)
    • Bookmarkable URL’s / GET support
  • Built-in integration with Drools, RESTEasy, etc
• Java EE6
  • Robust, flexible DI via CDI
  • EJB 3.1 (no-interface views, finally!)
  • JAX-RS  – Profiles (web, EE)
• CDI Overview
  • Standarization and improvement of the Seam component model + Guice)
  • @Inject (aligned with JSR-330)
  • @Named
  • @Produces
  • @RequestScoped
• CDI Overview (cont’d)
  • Contexts
    • @ApplicationScoped
    • @SessionScoped
    • @ConversationScoped
    • @RequestScoped
    • @[Anything]Scoped – pluggable contexts!
      • @ThreadScoped – via ThreadLocal
      • @CacheScoped – via Cache impl
  • Lifecycle
    • Robust scoping requires robust lifecycle management
    • Callbacks
    • Managed instances that end when the scope does
  • Events
    • Bridgeable to JMS
  • Well-defined SPI for creating portable extensions
• CDI Overview (cont’d)
  • Seam was too many things
  • CDI is a core framework & programming model
  • Web toolkits can be built on top of CDI via portable extensions
• CDI Overview (cont’d)
  • Stereotypes help group common sets of annotations
• JSF2 adds many features that Seam had
  • Page level metadata/navigation <f:metadata>
  • EL integration with CDI
  • Better GET support
• Cross-container testing  – Arquillian  – ShrinkWrap
• Anatomy of an EE 6 Application

Tools Used

• JBoss AS 6.0 Final
• Eclipse for Java EE developers 3.6 SR2
• JBoss Tools 3.2
• m2eclipse 0.12 (make sure to install WTP support!)
• Maven 3.0.3

References & Other Reading Material

• CDI Quickstart for Maven http://seamframework.org/Documentation/CDIQuickstartForMavenUsers
• Weld reference http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/
• JSR-299 http://www.jcp.org/en/jsr/detail?id=299

It didn’t happen overnight.  Red Hat is a big consumer of Bugzilla and in the beginning of our project, we agreed that rather than adopt the existing tool-du-jour (XPlanner) in addition to Bugzilla, we’d stick with what we knew well and build a process around that.

It worked, sorta, but we quickly became hindered by Bugzilla’s lack of anything resembling a workflow. We’d file user stories as bugs but since the tool is so cumbersome to use, we’d rarely task them out properly.  Some things would slip and other things would take scrum team members by surprise.  I’m no fan of Bugzilla, but in Mozilla’s defense, they aren’t really trying to do agile.

We decided as a team to adopt Rally since we already had some seats set aside for it.  I’m happy to report that thus far (half a sprint in), we’re pretty pleased.  It steps up in all the places Bugzilla falls over:

• Dead simple creation of tasks per story
• Resource management
• Implicit grouping of tasks under a story such that hours/progress are aggregated meaningfully
• Quick in-place editing (BZ languishes in web 1.0)
• Built-in workflow & reporting designed for agile development
• Useful dashboard that displays rich information about the current sprint (tasks, defects, blockers, burndown)

We’re still deciding what to do with our large Bugzilla backlog, but it turns out there may be a plugin we can use.  If we go that route, I hope to have time to blog about it in a future posting.

At first glance, this looks completely reasonable especially if you consider that each corresponding environment declares a container-level variable whose value is one of the directory names (Development/Integration=dev, UAT/Test=test, etc.). Developers get to configure each environment and at deployment time the server simply knows how to behave based on the preset environment variable. Sounds OK, right?

NO! It isn’t OK. It is horrible and you should never do it. Packaging configuration in with code leaves the System Administrator powerless to administer the system. See the problem? No? Here are more reasons:

• Configuration changes require a redeployment of the application (possibly even repackaging)
• Developers may not (indeed, should not) be privy to certain config information (passwords, let’s say) for production environments
• Test environments of the same “level” can’t have differing configuration unless you jump through hoops like branching source code
• Turning a dev/test/stage box into a production one (or vice versa) with one small change is just scary
• A developer can change production and nobody will notice until the code gets to production!
• A developer can change production and nobody will notice until the code gets to production!
• A DEVELOPER CAN CHANGE PRODUCTION AND NOBODY WILL NOTICE UNTIL THE CODE GETS TO PRODUCTION!

Get it?

The way to manage configuration is to provide a nicely-commented prototype config file (that can’t/won’t be read) with your application and leave the runtime configuration in a file outside the deployed application path. There are many ways to make such files available to your program regardless of whether you’re using a container or not. You can:

• Add a conf directory to the runtime classpath
• Put the config files in a known directory such as common/classes on Tomcat
• Jar them up and name them according to environment, if you just absolutely must not let the admins touch them.

Any of these tactics work. As long as you aren’t marrying code and configuration, you can’t miss.

So far I’m pretty pleased. The out-of-the box suite of applications is more than adequite for the average user, and it’s Linux, so the power user will never be left wanting. The only stumbling I’ve done is on multimedia codecs. So far I have yet to get anything resembling Internet-type audio/video to play, but I’m not sure I’ve done everything right. Flash 9 beta is installed so all my favorite rich-clienty sites work well (Google Finance, YouTube, etc). No MP3 or AVI joy yet though.

I’ll wrap this up and hope it posts, with the thought that I’ll do a more in-depth review soon.

I think we can all agree that choice is good, but is the sheer number of non-trivial frameworks really unifying the java community, or are we breeding segments of the population who know only a subset of what’s out there?

When you’re an ASP guy, you pretty much have you work cut out for you. Same goes for the new kid on the block Ruby [on Rails]. But Java, in its maturity, has brought so many innovations to market that one could make an entire project out of evaluating frameworks for use in any given project!

The days of Struts & JDBC are pretty much over, kids. Do you use Spring at the web tier? How ’bout JSF or Tapestry or WebWork? Do you decorate with SiteMesh, or assemble with Tiles? Maybe you are into JSP includes or writing a lot of custom tags. Do you manage your middle tier with Spring, or opt for the latest appserver’s EJB3 implementation? It might seem like everyone is using Hibernate for persistence, but it aint the only kid on the block. TopLink Essentials is bundled with GlassFish and other EE5 offerings will be supporting JPA as well. This is just the tip of the iceberg.

How do you decide?

And here’s the problem: If Johnson’s salary is (unfairly) higher than mine, and secret, I can’t complain to my manager about it because I can’t admit that I know about it. When a company sets up a situation where people can see the unfairness but can’t address it directly, or even discuss it openly, they’re rigging the system for maximum frustration.

The author cites another potential problem, one I have experienced first hand:

I have worked at two different companies where salaries were secret and guess what: They weren’t. Most people knew what most others were getting. In one company I consulted for, the IT department had even found the Excel spreadsheets HR kept the salaries in. They knew what everyone was getting.

This blurb speaks to the larger issue of information asymmetry, the term given to a situation in which those who possess information can choose to use it against those who do not. Leaked information becomes contraband and fosters even more frustration. And as Young MC says, “From frustration first inclination / Is to become a monk and leave the situation”. But every dark tunnel has a lighter hope, so maybe transparency is the way forward.

What do you think? Would you prefer working in an open environment like this?

Layout Gala

I had to give this treasure its own line because it embodies everything that is good and right in the field of web design. Pure, compatible, solid layouts that don’t rely on hacks. They’re all there, kids. Two-column, three-column, liquid, static — many even support any-order columns. Squirt.

But no more. The EJB expert group, now composed of some of the very creators of modern persistence framework, has bequeathed upon us something wonderful. The lightweight POJO programming model we have come to love is apparent everywhere in the EJB 3.0 specifiction (JSR-220), which was unanimously accepted by the JCP earlier this year. EJB 3.0 is just one goodie in the larger Java EE 5 (JSR-244) bag – but this post is going to be long enough as it is.

When I returned from Las Vegas with my newfound interest in EJB, my first task at hand was to create a little test application that demonstrated the scenario that is most applicable to my work: EJB3 services remoted over RMI consumed with POJO web applications that already use Spring. This use case stems from the need that we have realized the need to segment a growing middle-tier application from the monolithic beast it is destined to become into smaller, more manageable services. The client programs (mostly web applications) already access the business interfaces using Spring.

I’m going to skip the gory details of setting up the server, creating a project and all the like. There are plenty of explanations of this elsewhere. Besides, this post is going to be long enough as it is.

First we need a business interface. How about something really complex:

[java]
public interface SimpleService {
int stringLength(String string);
}
[/java]

Nothing fancy there. Now let’s implement it with some logic:

[java]
public class SimpleServiceBean implements SimpleService {
public int stringLength(String string) {
return string == null ? 0 : string.length();
}
}
[/java]

Still totally straightforward. Now let’s turn our bean into an EJB. This is the really complicated part. Watch for the annotations:

[java]
@Stateless
@Remote(SimpleService.class)
public class SimpleServiceBean implements SimpleService {
public int stringLength(String string) {
return string == null ? 0 : string.length();
}
}
[/java]

Did you get all that? The @Stateless annotation tells us that this is a Stateless Session bean, and the @Remote annotation specifies the remote interface. Everything else is handled by the container. Although the footwork is managed by the container in a somewhat vendor-specific way, the annotations are standard Java EE, and so you’re not tied to an implementation. When you catch your breath, let’s move on.

Since Java EE 5 has embraced configuration by exception, we don’t even need any depoyment descriptors. These two files can be compiled, JAR’d up and deployed to a server of your choosing — I used JBoss 4.0.4.

In order to have a client, we need to provide, at a minimum, the remote interfaces and any other classes or exceptions it references. For testing, I just tossed the same JAR on the classpath since I know it contains everything I need. Additionally, we need the Spring JARs (this test used 2.0RC1) and the JBoss client JAR’s.

The only real programming we have to do here is to create a Spring container that wires up to the server’s JNDI directory. To do this, we’ll use Spring’s JndiObjectFactoryBean. This part actually confused me because try as I did, I could never accomplish this feat using the more aptly-named SimpleRemoteStatelessSessionProxyFactoryBean. The difference, apparently, is that since EJB3 places no specific requirements on the business, home or remote interfaces, there is less to do, and thus the client simply grabs the object and narrows it down as prescribed. Here is my Spring configuration (minus the XML header and DTD info):

[xml]

org.jnp.interfaces.NamingContextFactory org.jboss.naming:org.jnp.interfaces jnp://localhost:1099
[/xml]

The JNDI properties provided are JBoss specific, as is the provider URL. These are included with the JBoss client JAR in the form of a jndi.properties file. They are exactly the same as what would be used to construct a traditional InitialContext if this were a non-spring J2SE client.

JBoss mounts Remote interfaces (by default) using /remote, and Local interfaces using /local. As you can see here, we’ve chosen the remote. One could just as easily expose SimpleServiceBean as a Local EJB by using the @Local annotation and providing the same business interface as an arguement. The Spring container changes only in URL and jndiName values.

Once the bean factory is configured, you can load it and request the remote SimpleServiceBean proxy by name (simpleService), casting it to SimpleService as you would normally do with a Spring-managed object. It works flawlessly.

Gavin & crew demonstrated quickly but effectively the lovely synergy that has been brought to EJB3 and JSF by their newest creation, Seam. Seam can hardly be called a web framework — you wouldn’t recognize it as such what with its lack of, well, just about everything that you’ve come to expect from a web framework.

Seam throws away boilerplate code a-la Rails, but does so in a way that leverages a lot of the untapped power of EJB3 and JSF. Seam is all about Don’t Repeat Yourself (DRY). As such, we throw away form beans (a-la Spring MVC) and a whole lot of XML (in favor of annotations).

The most surprising theme that emerges from all of this is the rampant use of Stateful Session beans. You read that right – I said Stateful. Seam begs the question, “why on earth would I represent state in a database (slow is an understatement) or in HTTPSession (with no dirty checking) when I can use this lovely gift called Stateful beans?” He makes a damn good point. By representing web conversations as SFSB’s (which are POJO’s in EJB3, in case you’re wondering) you eliminate many of the headaches associated with web apps. Multiple tabs open in your browser? Piece of cake – each browser tab/session/window has a unique conversation (they’re stateful, remember?). Double submit? Ha! Don’t even try! Want to have a clean client redirect after performing some action, but still pass messages across? No problemo – you’ve got a lightweight stateful conversation behind you.

By logically grouping your flows into SFSB’s, you can leverage more sophisticated failover because the container dirty-checks each instance and replicates automatically. Try that with HTTPSession.

So, I will be doing a sandbox app soon with Seam, and I’ll post more as I know it. Till then, read all you can.