Taking Enterprise Java to a New Level

Java EE 6: A Better Development Experience Awaits!

Enterprise Java standards have come a long way since 1998, when the first release of Enterprise JavaBeans (EJB) emerged. In 1999 the Java 2 Enterprise Edition (J2EE) platform was created, grouping EJB together with a suite of enterprise technologies and launching what was to become a comprehensive and practical set of vendor and developer standards for enterprise applications. The Java Enterprise Edition (Java EE) 6 specification, released in December of 2009, is the latest installment of that dynasty and has already started to make its mark on the Java community.

Who needs standards? In an era of substantial IT budgets (often measured in millions of dollars), most people see the value of standards. Companies win because their software investments are more protected than if they were to invest in proprietary technologies. If their relationship with a particular vendor turns sour, or their trust in its future is in question, or even if they just feel they can get more value elsewhere, they can change the underlying product that implements the standards to which their applications are written. They can also more easily find and hire developers to work on those products, since a standard set of well-defined technologies provides a common foundation and vocabulary for training, communicating, and assessing developer skills. But it's not just the corporations that benefit from the existence of standards. Developers are also better off because their knowledge and experience is transferable across jobs and across implementations. They are not left stranded in a "dead-end job", accumulating knowledge of little use outside of their immediate work environment.

Even vendors appreciate the value of standards, since by implementing standards they know that they have a greater chance of selling their software to a company that is risk averse. Product offerings will be more widely applicable and more readily consumed.

Too Slow and Too Fast

Technology changes at a pace unlike almost any other industry, prompting some to claim that a two to three year Java EE release cycle is just too long. They complain that too many new programming innovations occur between releases and that it takes too long to incorporate these into the platform. On the other hand, corporate IT folks complain that releases are too close together. A company with a software system containing three million lines of code cannot easily upgrade it to use a new technology. The momentum of massive software makes it simply impossible to make large changes in short periods of time. For these companies, changing the standards too quickly renders their systems obsolete sooner and makes it more difficult to find people to work on them.

Most people recognize the balancing act that must be followed. For a standard to be successful it must be adopted not only by the consultants, who are eagerly riding the bleeding edge of as many new technologies as they can fit into an application, but by corporations with large systems. New technology innovations should be given some time in the testing grounds of practice before being incorporated into the specification.

Adopting new practices before they have reached widespread adoption or been proven to be of value would place the platform at risk and be doing a disservice to both the platform implementors and the users.

Breaking it Down

The Java EE 6 platform offers some new and exciting features to attract new developers, as well as some significant enhancements to some of the known stalwart specifications. We haven't got the space to describe all of the changes in this article so we will focus primarily on the novel aspects of Java EE 6 and the new specifications that have been added. But before we break into the details let's take a high level look at the Java EE 6 platform and the various specifications that make it up. Table 1 gives a brief description of each sub-specification and the changes that were made to it in Java EE 6.

With six new specifications added and thirteen updated it is clear that Java EE 6 is not your mother's enterprise Java platform. Java EE has indisputably undergone a fairly dramatic evolution in terms of how developers can program applications.

Targeting the Web

One of the major thrusts of the release was to make web application development easier than ever. To this end, three major areas of improvement were pursued: creating a special profile tailored to web applications, features for more convenient web component development, and simpler archive packaging to round off the experience.

A separate Java EE profile for web applications is really just an instance of a more general profiling concept. The idea is that a given class of application may typically only make use of a subset of Java EE technologies, and that by defining a profile around that set it will be easier to produce and consume the software relevant to that application type. Vendors can implement and sell just the parts that are included in that profile, yet still be able to market it as a fully compliant profile.

Developers can purchase only the software they need for their applications without having to pay for or develop with the entire Java EE stack. It represents a reduction of both the development and production runtime footprints.

Given the prominence that web applications has in the industry right now a Web Profile was the obvious first profile candidate. The Web Profile was defined to contain enough for most web applications to do what they need, while leaving out the technologies that the majority of web applications don't use. The following specifications make up the Web Profile. The version of each of these is the same as the one listed in Table 1.

• EJB Lite

• Servlet

• JavaServer Pages (JSP)

• Expression Language (EL)

• Java Transaction API (JTA)

• JSP Debugging

• Java Standard Tag Library (JSTL)

• JavaServer Faces (JSF)

• Common Annotations

• Java Persistence API (JPA)

• Bean Validation

• Managed Beans

• Interceptors

• Dependency Injection for Java

• Contexts and Dependency Injection

You may have noticed that the list does not specify EJB, but rather EJB Lite, a subset of EJB that includes only the more current POJO style components. The older components, based on an EJBHome and EJBObject client view, as well as some other portions of the specification that are seldom used for web applications, are not part of EJB Lite.

Many features have been added into the web and presentation components, as well as the new specifications (to be discussed later) that can be used in web components, but it suffices to say that creating presentation objects is much more convenient and flexible now than in previous releases. Support for annotations, asynchronous returns, AJAX, standardized facelets, validation, advanced injection, and more, puts more power into the hands of web developers and requires less effort.

Lastly, packaging a web archive was rendered less complicated for applications that have more than just web artifacts and persistent entities. Using transactional business components to encode the domain logic has long been accepted as a best practice, and up until now EJBs needed to be in a separate JAR file. An application that used both EJBs and web components needed to create an EAR file to house both the WAR and the JAR files. The packaging requirements have been loosened in EE 6 to allow EJB components to be packaged in WAR files, making an EJB JAR file completely unnecessary and an EAR file similarly unwarranted. The WAR file is the new application archive, and web applications that rely only on the Web Profile can be packaged completely within a single WAR file, from servlets and JSPs to EJBs and JPA persistence units. Figure 1 shows how a trivial application needed to be packaged in Java EE 5 and how it can be packaged in Java EE 6.




Mike Keith
Mike Keith

What do you think?

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


Latest opinions