What's Coming In Java Enterprise Edition 6

What is Java Enterprise Edition, today, in 2007? Java EE is many specifications that are implemented by an application server such as: Servlets, Java Server Pages (JSP), JSP Standard Tag Library (JSTL), Java Server Faces (JSF), EJB Stateless & Stateful Session Beans, Java Messaging Service (JMS), Message Driven Beans (MDB), EJB Timer Service, Java Persistence Architecture (JPA), Java Connector Architecture (JCA), Java Mail, Java Naming & Directory Interface (JNDI), Java API for XML Web Services (JAX-WS), Java Transaction API (JTA), Java Authentication and Authorization Service (JAAS), and I'm sure there's more. Because all of these technologies are built-into the application server, you do not need to include 20-40 MB of JAR files in your project deployments; each with different license restrictions.

Many of these specifications have been around for a long time and improve slowly every few years. For example, EJB 3.0 from Java EE 5 has greatly improved usability based on lessons learned from Spring. Still, some argue that EJB 3.0 has not matched the full functionality of Spring beans.

Other technologies were new in Java EE 5 such as Java Persistence Architecture and Java Server Faces. Even though JPA's design was based on Hibernate, some argue that JPA has not matched Hibernate's full functionality. JSF is also missing a few things. The open source world has filled those gaps by building frameworks on top of it such as: Sun Creator Studio/Visual Web Pack, Jboss Seam, and Apache Shale.

Despite these slight imperfections, Java EE 5 was a giant leap forward and created a solid foundation to build upon. Now that the foundation is laid, the Java Community Process (JCP) committees have been able to focus on the types of things they didn't have time for in Java EE 5. Lets have a look at what they've been working on:

Note: The following information is mostly copy/pasted from various Power Point slides available from JavaOne's website. Since Java EE 6 is not final, any of the following information may change.

Enterprise Java Beans 3.1

• Local business interfaces are optional. Develop local EJB components using only a bean class.
  • Client still never uses new() to obtain a reference. There is still separation between client reference objects and bean instances which enables the container to inject value added features such as: pooling of stateless session bean instances, activation/passivation of stateful session beans, lazy initialization, transparent clustering, concurrency control.
  • Reference is of type <bean class> but client contract only exposes the EJB component's public Local business methods.
  • Local client programming model essentially the same with/without Local business interface.
• EJB components can live in the web tier. Package/deploy EJB components in a .war without an ejb-jar.
  • No ejb-jar needed.
  • Bean/interface/supporting classes placed in WEB-INF/classes
  • One component environment (java:comp/env) shared between web application and EJB components.
  • Any Java Persistence API persistence units in .war are shared by EJB components.
  • Full EJB container functionality available.
  • EJB components in .war have no special knowledge of web container.
  • Invocation semantics the same regardless of packaging.
  • Ensures packaging decisions can be changed with minimal impact on application.

• Singleton Beans. Singleton Beans enable developers to share state between EJB components in an application. Similar to web application level context (ServletContext).
  • For each singleton bean, one instance per application per server JVM. Not intended to provide cluster-wide singleton.
  • Fits easily into existing environment dependency architecture. Acquisition through @EJB or lookup.
  • Good for sharing data with entire application, not just EJB components.
  • Singleton also provides useful way to add new lifecycle callbacks for container initialization and shutdown.
• EJB Concurrency. Presently the EJB container provides single-threaded guarantee for all bean instances. Each client invocation on a stateless session bean & message driven bean are handled by different bean instances. Stateful session beans allow one invocation at a time. The container frees bean programmers from dealing with instance state synchronization issues. However, some new concurrency features were needed:
  • Developers will be able to specifiy desired behavior for when a stateful session bean request arrives while the bean is still processing an earlier request. @ConcurrencyManagement(policy=RejectConcurrentRequests) to reject, or serialize requests by default.
  • Singleton Beans required new concurrent access options to allow for balance of performance vs. code complexity. The next two points might be added for Singleton Beans only.
  • New @ReadOnly and @ReadWrite annotations for entire class and per method.
  • New @BeanManagedConcurrency class annotation which enables use of the synchronized keyword.
• Simple Asynchronous Operations. New @Asynchronous annotation that can be used on an EJB business method. Ex: @Asynchronous public void doSomething(Reservation res) {...}
  • Container returns control to client before executing business method
  • No separate API to learn
• EJB Timer Service. Timers are persistent meaning they survive server shutdown/restart. They are also transactional. Presently it is difficult to configue calendar based events such as “The second day of every month at noon", or “every half-hour on Saturdays and Sundays". There is also no way to guarantee that only one timer instance is created per cluster. EJB 3.1 will fix these issues:
  • Cron-"like" syntax (TBD) to express calendar based events
  • Automatic timer creation. Creates a timer as a result of deploying an application. This is useful for registering a one time or recurring application specific action indepenent of a business method invocation. For example: Generate bank statements the 1st of every month. For each timer expiration, callback happens in one server instance, not every server instance in cluster.
• Stateful Web Service Endpoints. EJB 3.0 presently supports stateless web service endpoints. Stateful interaction is useful to web service clients so stateful session beans will also support being exposed as a web service endpoint.

For more information on EJB 3.1, watch the technical session online from JavaOne 2007.

Java Persistence Architecture 2.0

Entity Beans were removed from the EJB spec in Java EE 5, and the Java Persistence Architecture 1.0 was created to replace them. The design was based on Hibernate, and some application servers even use Hibernate as the implementation of JPA. JPA was missing a few things though, and also led to non-portable code (to other JPA implementations) if you used vendor specific functionality. JPA 2.0 aims to solve these issues.

• Expanded O/R mapping functionality.
  • Improved support for embeddable classes
  • Collections of Strings and other basic types
  • Add support for unidirectional one-to-many relationships using foreign key mappings. Currently the relationship must be bidirectional.
  • Add support for table per concrete class strategy which is currently optional in the specification.
• Ordered lists. When you add a new entity to a collection, it will automatically sort based on how ordering was configured. I think it might also support updating an index field in the database for all records after a newly inserted record in the middle of the list?
• More flexible use of access types. Defines whether provider uses fields or properties.
  • Spec currently states that only a single access type applies to an entity hierarchy.
  • Unclear what this really means.
  • Implementations may (non-portable) support more, but not defined how.
• Expanded Query Capabilities
  • Criteria Queries: API to allow “node-wise" query construction vs the usual String query construction. This is a more objet oriented way of creating dynamic queries.
  • There is a considerable set of criteria APIs and expression APIs already in existence for the JPA committee learn from: Hibernate, OJB, Cayenne, TopLink, etc...
• Standardized Hints and Properties. Hints and properties are used in configuration of the entity manager factory, entity manager/persistence context, and queries. Presently the names and values are not standarized and create non portable code (between JPA implementations). There are a handful of hints and properties used regularly that could be standardized:
  • JDBC driver, user, password, connection pool
  • Caching, cache size
  • Timeouts
  • Logging
  • DDL handling
  • etc...
• Better contracts for handling detached objects. Detached entities often have unfetched state and/or relationships. What happens on access to unfetched state is currently undefined.
• Define better plugability contracts between JPA and stateful session beans for passivation/activation. This will benefit the new stateful web services in EJB 3.1, and conversational scoped WebBeans.
• Bean Validation (JSR 303). The goal is to define metadata model and API for validation for general use in Java SE and Java EE platforms. The JPA committee would like to leverage this if the rate of progress in JSR 303 is fast enough.
• And more...

For more information on JPA 2.0 watch the technical session at JavaOne 2007.

Servlets 3.0

Whether you realize it or not, servlets are still popular for web application development. Lots of web frameworks are built on top of servlets. Enhancements to the servlets API will benefit all web frameworks.

• Make web.xml optional via annotations
• Use better defaults
• Asynchronous Support (Comet)
  • Non-blocking input/output
  • Delayed request handling
  • Delayed response close
• Security – Login/logout and self registration. They didn't say much about how servlets will be enhanced to make this easier.
• Alignment with other libraries in the platform:
  • Enable Java Server Faces 2.0
  • Enable REST API
• Miscellaneous
  • File upload
  • Container wide definition of init params
  • ServletContextListener ordering
  • Better welcome file support
  • And more... they want to address as many outstanding requests for enhancement to the servlet API as possible

For more information on Servlets 3.0, watch the technical session online from JavaOne 2007.

WebBeans

Web Beans aims to enable EJB 3 session and entity beans to be used as JSF managed beans (known as actions in other frameworks) eliminating the dual layers of web actions and EJB's common in web apps. Instead, EJB's will BE the actions.
Floyd Marinescu - InfoQ

This JSR is based on strong existing contributors : Jboss seam, Google Guice, and Apache Shale.

• EJB 3.x technology components may be WebBeans. WebBeans addresses the problem of integrating EJB technology components into the web tier.
• The core of WebBeans is being architected to have no hard dependency upon Java Server Faces or EJB 3 technology. The following can be made into a WebBean: stateful and stateless session bean (even web service endpoints), JPA entity beans, any Java class file.
• Uses annotations for configuration
• Decouple implementations of server and client by allowing easy overriding of server implementation. At runtime, the WebBeans container chooses the implementation with the highest priority from those in the classpath. The predefined priorities are (from lowest to highest) : BUILT_IN, FRAMEWORK, APPLICATION, DEPLOYMENT, MOCK.
• EJB 3.0's interceptor model can be extended to any WebBean.
• Extensible set of scopes: No scope, request, session, conversation, application (singleton), custom.
• Conversation scope:
  • Primarily used with servlets
  • Bigger than a request
  • Smaller than a session
  • Spans multiple requests
  • Useful for implementing wizards
  • Support for multiple instances of the same wizard running in different browser windows
  • Manage persistence context – Optimistic locking and lazy fetching

For more information on WebBeans see JSR-299.

Java Server Faces 2.0

A lot was learned from Sun Creator/Visual Web Pack, Jboss Seam, Apache Shale, ICEFaces, Facelets, JSFTemplating, etc. about what was missing in JSF. Changes to the servlets API, the new WebBeans JSR, changes in JSF 2.0, and the component developement comunity will make JSF the web platform to develop on in Java. It is built into all Java EE application servers which means you can just use it. You don't need to add a bunch of JAR files to your project.

• Real world, production view description technology, including templating: include something influenced by Facelets, JSFTemplating or Tiles in the specification.
• Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used.
• Provide a mechanism to minimize the "Lost Update" and "Duplicate Button Press" problems.
• Strategic additions to the Standard HTML RenderKit: Calendar, Tree, Tab View, Captcha, Login Panel, File Upload components.
• Enable components that publish events via RSS/Atom.
• Allow for "zero configuration" web applications. No faces-config.xml, no web.xml. If necessary, annotations will be used to supplement the configuration data.
• Expand the request processing lifecycle to be aware of Ajax. This may include describing a small developer-contract footprint JavaScript library as part of the JavaServer Faces specification. (They also mention a number of other features that make AJAX seamless)
• Improve component development process. Make it easier for developers to write components.
• And much more...

For more information on JSF 2.0 see Ed Burns' blog for information and links.

JAX-RS: Java API for RESTful Web Services

REpresentational State Transfer (REST for short) is a way of creating and consuming web services identified by a URI. It uses HTTP methods such as GET/PUT/POST/DELETE to work with a resource identified by a URI.

• Many web companies now offer REST APIs for their services. Where both WS-* and REST APIs are offered, REST APIs are more widely used. The slides say this is because REST APIs are often easier to consume with scripting languages, and browser based experimentation is also easy.
• The current platform APIs for building REST web services are rather low level. JAX-RS simplifies development.
  • High level
  • Declarative
  • Clear mapping to REST concepts
  • Takes care of the boilerplate code
  • Flexible typing – runtime takes care of common conversions
  • Pluggable support for types, containers and resolvers through SPIs
  • Flexible deployment options

For more information on JAX-RS watch the technical session at JavaOne 2007.

I am wildly excited about Java EE 6. I have a rather large clustered system in mind waiting to be written that can make use of almost all of these new features. Every change in Java EE 6 is important to me, but the one that stands out the most is the EJB Timer Service. Adding support for calendar based events and a single timer per cluster is invaluable! I have an other idea for the EJB Timer: provide convenience methods where I could pass in a range of dates and have it return something that tells me which events will be firing at what time for each of those dates. This would allow me to render a graphical calendar that displays scheduled activity for a given month.

There is one other JSR worth mentioning even though it is not part of Java Enterprise Edition 6. JSR-277 Java Module System:

The JSR 277 (Java Module System) specification seeks to address many issues associated with Java Archive (JAR) files, including the lack of version control, the difficulties in distributing multiple JAR files for deployment, the classpath hell, the JAR file hell, and the extension hell that have been well known to many developers on the Java platform for years. The specification defines an architecture with first-class modularity, packaging, and deployment support in the Java platform, including a distribution format, a versioning scheme, a repository infrastructure, and runtime support.