Every new release of the Java EE platform makes it incrementally better by adding new features or simplifying its interfaces which was also the main theme of the latest Java EE ver. 7 release.
Let’s review some of the aspects of the new release and touch on the subject of the platform’s potential growth vectors.
Reduce the boilerplate code. Is the mission finally accomplished?
One of the repeated topics in each and every Java EE release since version 5 has been “reducing the boilerplate code”. And it looks like that with the help of meta programming facilities offered by annotations and Contexts and Dependency Injection (CDI) capability introduced in JEE6, this goal has been practically achieved. The latest beneficiary of this exercise is JMS that in EE7 underwent a major overhaul. The incidental complexity of JEE programming has been reduced to the point beyond which it would require something conceptually similar to emoticons to make it even simpler. As the old adage goes: “Make things as simple as possible, but not simpler.” So there is probably not too much to expect (or demand) in this department in future releases …
Caching
Java in-memory caching API (JCache) did not make it to the final release of Java EE7 and is likely to be included in the JEE8 release. Not a big deal for those Java developers who know that they can always plug in ready-to-use in-memory cache solutions for Java objects such as the open-source Ehcache product (which is a version of the JCache specification as implemented by Terracotta).
More support for web technologies
JEE7 now offers support for a wider range of web technologies, such as HTML5, WebSockets, and JSON all of which will consolidate its position as a feature rich modern web server platform. This is a big thing, no doubt.
Currently, JEE already has the servlets, JSPs, JSFs, and facelets with the overall trend toward increased sophistication of Web tier programming which is directly correlated with its growing complexity.
To reduce complexity of Web tier development and potentially draw additional interest in the platform, a move in the opposite direction – toward simplified Web programming models in JEE – may be a viable alternative. Scripting support from web-aware components like Groovlets or the like may fit the bill. Another area to explore could be simplified access to business logic via an AJAX-based bridge between JavaScript (or any other browser scripting language that may become popular in future, like Dart and Java modules. Currently, there are quite a few Java Web Remoting frameworks such as DWR, Apache Tuscany project (to some extent), and Google Web Toolkit, that can be used as a starting point for the analysis of such systems.
Embracing techniques and ideas from open source projects
Java EE has started to more willingly embrace proven techniques and ideas conceived and developed outside of the realm of Java EE specs. Under this trend, JEE can effectively (and efficiently) leverage the know-how used in developing systems that are already enjoying a wide adoption in the Java community. An example of this would be the Contexts and Dependency Injection (CDI) capability built on top of the ideas and concepts underlying the popular Spring and Guice dependency injection systems as well as the Seam context management framework.
Now, without much ado, JEE7 fast-tracked the Batch Processing spec based on the Spring Batch framework (batch jobs are tasks that can be executed without user interaction, such as ETL scripts, etc.).
Support for NoSQL Databases
NoSQL databases are on the curve of gradual adoption in the Enterprise world and this is one of the areas where JEE can take a big piece of the action.
One of the models to emulate is SpringSource’s Spring Data umbrella project that offers Spring-powered data connectors to NoSQL databases, map-reduce frameworks, and cloud-based data stores.
EIS vendors, who wish to expose functionality of their products to the JEE platform in a “standard JEE” way, are always welcome to create JCA-compliant resource adapters for their products thus lending credibility (in the eyes of some conservative executives) to their NoSQL solutions.
This activity needs to go along with an effort to standardize a “NoSQL language” (if one is ever accepted by the very diverse NoSQL database community). Unstructured Query Language (UnQL) project is a step in this direction.
Support for NoJMS (Not Only JMS) systems and the Message Broker role
Similar to the “support for NoSQL” idea, JEE may take a crack at integrating with other messaging systems. Even though Java message-oriented middleware API exposed through JMS has been an integral part of the JEE platform since its early days and is already implemented by a wide range of open-source and commercial products, the JEE platform can potentially benefit from the added support for non-JMS a/synchronous messaging communication protocols such as the Advanced Message Queuing Protocol (AMQP).
Also, with some extra work, the EJB container can be re-engineered to handle tasks of a (JMS and NoJMS) message broker similar to what Apache ActiveMQ does. Overall, it makes sense since parts of the messaging infrastructure (e.g. message-driven beans facility) are already in place and various application servers implement some or all message broker functions in one form or another.
This initiative would promote true interoperability with other a/synchronous messaging platforms and systems moving JEE into new play fields. That, in addition to the existing solid support for SOAP and REST web services in the form of JAX-WS and JAX-RS APIs, would consolidate the position of JEE as a versatile system integration platform.
Light-Weight ESB
Out-of-the-box, the JEE platform already supports a variety of enterprise integration technologies which are just crying out for being combined into an Enterprise Service Bus (ESB) like system. Frameworks like Spring Integration, Mule ESB, Apache ServiceMix and the like have already shown the value proposition of a light-weight ESB. Some vendors are already thinking along those lines – for example, in WebSphere version 6.0, IBM introduced the Service Integration Bus which currently has only JMS orientation.
It may well be that a built-in ESB functionality could become a gem on the JEE’s crown, re-positioning the JEE platform as a system for building Service-Oriented Integration solutions.
Becoming Fault-Tolerant
The JEE platform offers a primitive form of multi-tenancy by supporting the deployment of multiple user applications (packaged as WAR and/or EAR archives). These “applications” are loaded though a hierarchy of class loaders into the same heap of the target VM which is visible to the underlying OS as a single executable process.
This “shared-all” community architecture is very brittle: a single rogue thread in one of the applications can hog CPU cycles allocated to the JVM system process or crash the JVM by throwing an Out-of-Memory exception as a form of protest against the fact that there was not enough contiguous space on the heap.
Heap partitioning or other mechanisms of application isolation within a single JVM (if ever implemented in Java) would not be a complete solution as the VM is still treated by the underlying OS as a single process of execution. To become a fault-tolerant system, the Java EE platform should have built-in support for clustering (which can be switched off, when needed). Support for clustering as an enterprise feature is implemented by all application servers (e.g. IBM® WebSphere® Application Server Network Deployment). The idea is to recognize clustering as an essential enterprise service and build it into the core platform.
