Java EE Past, Present, & Cloud 7
One prominent topic of the recent JavaOne 2011 was the next major Java
EE 7 release. As stated in the keynotes, the work on it is well
underway. It will contain the 28 specifications we already know from the
forerunner plus a number of new specs. Nobody can tell you about the
exact number at them moment because EE 7 will only accept the new
specifications if they finish "in time". Which means, the planned
release date for EE 7 (Q3 2012 Final Release) is a superior goal which
sets scope and pace. Candidates for inclusion include Jcache 1.0 (JSR
107), Concurrency Utilities 1.0 (JSR-236), State Management 1.0, Batch
Processing 1.0 and JSON 1.0. This ambitious goal is only one thing that
makes me wonder. But let's start at the beginning.
Looking at the bullet-point topics that are already there for the 9 "work-in-progress" specifications should bring a bit more light into how to achieve the "cloud goal".
JPA 2.1 (JSR 338)
The first spec to include new features is the JPA 2.1. The new features can be described with the following short list:
- Multi-Tenancy (Table discriminator)
- Stored Procedures
- Custom types and transformation methods - Query by Example
- Dynamic PU Definition
- Schema Generation (Additional mapping metadata to provide better standardization)
JMS 2.0 (JSR 343)
This could be considered as the most mature spec in general. It had a long 9 years to go since it's last maintenance release (April 2002).
- Modest scope
- Ease of development
- Pluggable JMS provider
- Extensions to support “Cloud”
EJB 3.2 (JSR 345) The goal of Enterprise JavaBeans 3.2 is to consolidate these advances and to continue to simplify the EJB architecture as well as to provide support for the Java EE platform-wide goal of further enabling cloud computing. The scope of EJB 3.2 is intended to be relatively constrained in focusing on these goals.
- Incremental factorization (Interceptors)
- Further use of annotations to simplify the EJB programming model
- Proposed Optional: BMP/CMP
- Proposed Optional: Web Services invocation using RPC
CDI 1.1 (JSR 346) Since the final release of the CDI 1.0 specification a number of issues have been identified by the community and a update to the specification will allow these to be addressed. A list of proposed updates is provided here, however the EG will consider other issues raised as the JSR progresses.
- Embedded mode
- Lifecycle Events
- Declarative package scanning
- Global ordering of interceptors and decorators
- Injection Static Variables
Servlet 3.1 (JSR 340)
In developing the servlet specification 3.1 the EG will take into consideration any requirements from the platform to optimize the Platform as a Service (PasS) model for web applications. Beside this, the following areas should be addressed.
- Cloud support
- NIO.2 async I/O
- Leverage Java EE concurrency
- Security improvements
- Web Sockets support
JSF 2.2 (JSR 344) The new JSF JSR will be a significant feature update that builds on the advances from the previous JavaServer Faces versions.
- HTML 5 support (Forms, Headings, Metadata)
- New components
- Portlet Integration
JAX-RS 2.0 (JSR 339)
JAX-RS addresses most requested community features. To name a few: - Client API
- The primary API utilized for validation will be the Bean Validation API
Expression Language 3.0 (JSR 341) The Expression Language (EL), has been part of JSP specification since JSP 2.0. In Java EE 7 this will become a separate JSR.
- Standalone JSR
- Easier to use outside container
- Criteria-based Collection selection
- New operators
- CDI events for expression eval
Bean Validation 1.1 (JSR 349) Being a version 1.0, Bean Validation stayed on the conservative side feature wise. The community has expressed interest in additional features to enhance the work done in the first version of the specification.
- Integration with other JSRs (JAXRS, JAXB, JPA, CDI, EJB, JSF)
- Method-level validation
- Constraint composition
Cloud? Is that Rain?
Looking at the proposals it's clear that some of them have room for cloud enabling. Some don't care at all. Searching for the cloud stuff is very little successful until now. Let's look at the umbrella JSR 342. The official pages are public and can be found on http://java.net/projects/javaee-spec/. Very interesting is the Java EE 7 Platform and Support for the PaaS Model document (PDF), which describes the overall architecture for PaaS support in Java EE 7. And by comment is largely agreed to by the expert group. It summarizes needed roles (PaaS Product Vendor, PaaS Provider, PaaS Account Manager, PaaS Customer, Application Submitter, Application Administrator, End-user) and gives a couple of example scenarios in which they act in a PaaS environment. Further on you find some definition and terms:
"Since in the model described here a PaaS Customer corresponds to an isolation domain, we will use the term “Tenant” to avoid misunderstandings with other uses of the word “customer” in the business context."
"We will use term Application Developer to denote an application developer in the common sense. In the traditional Java EE terminology, this role is split between Application Component Provider and Application Assembler."
Additionally you find the mandatory statement about "protecting" investments:
It is a goal of Java EE 7 to add to the platform support for the PaaS model as well as a limited form of the SaaS model while preserving as much as possible the established Java EE programming model and the considerable investments made by customers, vendors, and system integrators into the Java EE ecosystem.Looking at the qcon London slides by Jerome Dochez you quickly notice, that there is a lot more stuff to take care of, than what the expert group covers with the public documentation:
(Source: The Java EE 7 Platform and Support for the PaaS Model)
- Better Packaging for the Cloud (Modular Applications)
- Deployment Model
- SLA Monitoring
And I am sure, you could come up with even more. The GlassFish / Java EE Strategy & Roadmap (PDF) presented by Adam Leftik & John Clingan at Oracle Openword paints a more detailed picture of the future by looking at:
- Dynamic Service Provisioning
- Iaas Management
- Elasticity using Auto-scaling
- Hypervisor Abstraction
Until now this seems like the most complete and concrete approach to Java EE in the cloud. Seeing the GlassFish team doing a presentation with the latest GF 4.0 release candidate you can imagine how far work is completed. (Even if I assume that there is still plenty of work to do :))
No Rain but it will be cloudy for some time
A lot is evolving at the moment. This is what was expected with changing direction in a mature specification. Looking at the new Oracle cloud offering and the continuing cutting-edge work the GlassFish team is doing I believe, that the ambitious goal could be meet because we have enough business value behind that. What I fear is, that single specifications could deny the inclusion of "needed" cloud stuff in favor of bug fixes or community requests. This is the first time the umbrella specification is emerging into a complete different direction, than the containing children. On the other side, as we know from the past, the umbrella itself is a comparable small specification which specifies on a very general level of detail. This could open up opportunities for vendors in general. Let me add another point here: I strongly believe that Java EE 7 will be biggest challenge for the spec lead since ages. Following the overall "cloud" theme without distracting or prioritizing the single contained specifications will be a very political job in general. Even if Linda DeMichiel is a Java EE veteran I believe that a lot of work is waiting here.
Summer 2013 vs Q3 2012 Final Release - missed opportunities
The real big issue I have with the timeline is the fact, that we don't have a chance to get a real modular approach for application packaging. Whatever will be designed in terms of packaging (and related stuff like versioning, SLA, and more) for the cloud will not be able to take advantage of the new project Jingsaw features coming with Java SE 8. I personally consider this a major requirement for cloud enabled Java EE PaaS infrastructures. If the new cloud metadata will be build upon the Java EE 6 packaging specification it is a missed opportunity to adopt latest and greatest in Java modularization. I am very curious to see, how the EG will work around this issue without having to rework everything with Java EE 8 again.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)