JEE 6: Extensibility, Profiles and Pruning

Posted by Charles Humble on Jan 15, 2008

Sections

Development,

Enterprise Architecture

Topics

Enterprise Application Blocks ,

Java

Tags

Java EE

Whilst the public details are still a little sketchy, the general direction of Java EE 6 is becoming apparent and reflects the changing role of the Java EE standard. Originally envisaged as a complete stack for enterprise computing, open source projects such as Struts, Hibernate and Seam have seen increasingly wide enterprise adoption to fill in gaps in the current version of Java EE. In some cases these open source projects have in turn influenced the next revision of the specification. As such, the role of Java EE is becoming less about providing a complete solution and more about providing a robust set of infrastructure code that vendors and open source developers can build on top of. JSR 316, the umbrella JSR for the next revision of Java EE, looks to put this new relationship on a more formal basis by making extensibility a core aim of the expert group. In addition, the specification acknowledges that Java EE has become large and complex and proposes both the pruning of specific elements of the specification and the introduction of profiles to provide focused subsets of EE functionality targeted at particular groups of developers. It will also build on the simplification work begun in the previous version, including the use of annotations to further reduce the dependency on the external configuration files.

The approach taken to pruning will be identical to that taken for Java SE 6 and is described in a blog entry here. It is performed as a multistep process where a candidate is declared in one release but may be relegated to an optional component in the next release, depending on community reaction. The JSR proposal suggests a couple of initial pruning candidates - JAX-RPC [JSR 101, Java APIs for XML-Based RPC] which is effectively replaced by JAX-WS [JSR 224, Java API for XML-Based Web Services], and EJB CMP now replaced by the Java Persistence API [originally defined as part of JSR 220, Enterprise JavaBeans 3.0]. During an interview with Artima, the EE 6 specification leads Roberto Chinnici and Bill Shannon suggested that the JAXR API [JSR 93, Java API for XML Registries 1.0], an API for accessing web service registries which hasn't seen wide adoption, may be added to the pruning candidate list.

Whilst pruning has been largely uncontroversial, Sun's use of profiles has sparked some debate. SpringSource's CEO Rod Johnson is certainly in favour of them:
"At last, users will have the power to shop around for what they want, rather than what a specification committee thought they wanted, two years before the users start building the application," Johnson said. "It's high time that a Soviet style command economy was replaced by some healthy competition."

But OSGi evangelist Peter Kriens is less than impressed:
"To address the problem that one size does not fit all, Sun proposes to create a few more sizes, called profiles. Surely that should fit all? Well, profiles have been tried in J2ME [Java 2 Micro Edition] and they failed in my opinion."

The first new profile planned for EE 6 is the Web Profile aimed at web application developers. As well as introducing this new profile, the specification will define rules for creating additional profiles for other market segments, for example for telecommunications or financial applications.

The technical details for extensibility are less clear although the JSR sets out some ambitious goals: "...we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers," the JSR 316 specification states. "By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform."

One example of this approach is JSR 196: Java Authentication Service Provider Interface for Containers, one of a trio of APIs originally planned for J2EE 1.4. It offers a standard service provider interface to allow authentication mechanism providers to be integrated with containers. Providers using the interface will be employed to establish the authentication identities for container access decisions, including those used by the container in invocations of components in other containers. The specification reached final release in October 2007 and is available for download.

Also originally planned for 1.4, Java EE 6 should finally see the formal release of a timer API suitable for use in managed environments, and a container-manageable programming model for the concurrent execution of work using a thread pool managed by the container. These two APIs, jointly developed by IBM and BEA and already supported in both BEA's WebLogic and IBM's WebSphere, are described here (PDF document).

There are two new APIs planned for inclusion in EE 6. The first is WebBeans, heavily influenced by JBoss' Seam and Google's Guice, which aims to simplify the programming model for web based applications in Java EE by unifying the web and transactional tier component models. In addition the WebBeans specification provides a conversation model and persistence context, providing finer grained state management and allowing a series of web transactions (a conversation) to be treated as a unit of work. Jacob Orshalick has provided a detailed write-up of the finer points of the Seam conversation model here and how timeouts are handled here. The WebBeans model is given extensive preview coverage by Gavin King through a manifesto and a four part (one, two, three, four) write-up.

Whilst reaction to the WebBeans JSR has been broadly positive, IBM did express some dissent on the ballot for JSR 316:
"We are becoming concerned with the direction that JSR 299 seems likely to take in going beyond its stated charter of integrating JSF and EJB components and believe that continued efforts in this direction could warrant its removal from Java EE 6. We do not believe that our customers would find it easy to adopt a Java EE 6 platform that adds yet another component model definition."

JSR 311: a Java API for RESTful Web Services is the second of the new APIs and has been generating an even more mixed response. A previous article on InfoQ provides good coverage of the community reaction. Brian Leonard's blog and associated links provides more detail on the proposal and Bill Burke has provided some feedback.

Java EE 6 will see revisions to a number of core APIs. Major updates are planned for:

1. Java Persistence API: Version 2.0 of the JPA will extend the capabilities of the API including
   • Expanding the object/relational mapping functionality including greater flexibility in combining existing mapping options, support for collections of embedded objects, ordered lists, combinations of access types, additional metadata to support DDL generation, and so on.
   • Expanding the query capabilities of the Java Persistence query language.
   • Standardizing of additional contracts for entity detachment and merge, and persistence context management.
   • Standardizing of sets of "hints" for query configuration and entity manager configuration.
   • Expanding pluggability contracts for Java EE environments.
2. Servlets: Despite its continued popularity, the Servlet API hasn't seen a major revision since J2EE 1.4. Version 3.0 of the Servlet API aims to
   • Improve web framework pluggability.
   • Improve ease of use through annotations and generics including making web.xml optional via annotations.
   • Add asynchronous support (Comet) to provide non-blocking input/output, delayed request handling, and delayed response close.
   • Make improvements to security capabilities including login/logout support, and servlet self-registration.
3. JavaServer Faces 2.0: The second major release of the specification aims to
   • Improve ease of use by removing the dependency on configuration files and the introduction of automatic generation of JSP tag handlers.
   • Add support for declarative renderers.
   • Improve AJAX support by changing the request processing life cycle and allowing partial updates of views.
   • Make it easier for developers to write custom components.

Finally, there will be some more minor updates to:

1. Enterprise JavaBeans with the aim of further simplifying the EJB component model. EJB 3.1 will see the introduction of optional local business interfaces, making it possible to develop local EJB components using only a bean class. It will also allow package/deploy of EJB components in a .war file without an ejb-jar.
2. Java EE Connector Architecture, focusing on ease of development and general improvements to the specification.
3. JAX-WS: Details are yet to be announced.

A number of APIs didn't make the final cut for Java EE 6. Two notable ones are JSR 168, the Java Portlet specification, which has been embraced by several major portal players, and JSR 208, Java Business Integration (JBI), a specification for service mediation that has been endorsed by everyone except BEA and IBM.

The EE 6 specification has quite an aggressive timeframe, with the final release targeted for Q4 2008.

1. Back to top

   2 questions

   by serge boulay

   1.) I thought JPA 2.0 would provide a criteria api?
   2.) I thought JSF 2.0 would have a new templating mechanism like Facelets and line precise error reporting (both are a must imo)?

   Reply

2. Back to top

   Re: 2 questions

   by Jason Lee

   1) Can't really say. Not my area. :)
   2) JSF 2 will have a Facelets-style templating. I'm not aware that we've talked specifically about line-precise error reporting, and I'm not sure if we'd formalize that in the spec, but, at the very least, implementations should be free to provide that. Time will tell what is finally codified in the final spec, but we'll certainly see Facelets, after a fashion.
   
   By the way, we hope to have an early release available before JavaOne this year.

   Reply

3. Back to top

   Re: 2 questions

   by Steven Devijver

   
   1.) I thought JPA 2.0 would provide a criteria api?
   

   
   
   JPA 2.0 should not only have a criteria API, it should also have a configuration API like Hibernate. Anything less than this is a waste of everybody's time.

   Reply

4. Back to top

   Re: 2 questions

   by serge boulay

   line precise error reporting in the spec
   
   "Vastly improve the developer experience with regard to error messages that happen during iterative development, and even during deployment of the application. For example the EG will consider options including, allowing the developer to tell the runtime what stage of development the web application is in, and take action accordingly: Development, Test, Deployment. Line precise error reporting. Pluggable Exception Handling."

   Reply

• Older >