The latest version of Enterprise Java, which was approved a few days ago, features a capability for function-based profiles. The first one published is the Web Profile, which aims at web developers, but it is uncertain if it will be enough to boost the platform’s adoption in a field with so many appealing offers.
As the Final Draft for the Web Profile mentions, the rationale is to target at developers of modern web applications offering a reasonably complete stack while also setting a limit to the footprint of web containers, both in physical and in conceptual terms:
In terms of completeness, the Web Profile offers a complete stack, with technologies addressing presentation and state management (JavaServer Faces, JavaServer Pages), core web container funtionality (Servlet), business logic (Enterprise JavaBeans Lite), transactions (Java Transaction API), persistence (Java Persistence API) and more.
As for simplicity, it leaves out many of the enterprise backend APIs that are part of the Java EE platform. It also relies on the new pluggability features in the Servlet specification (see e.g. Section 8.2 of that document) to allow applications to use libraries that extend the servlet container with minimal configuration overhead. For example, a standard technology such as the Java API for Restful Web Services (JAX-RS), which is part of the full Java EE platform but not of the Web Profile, can be “plugged” into a web container without requiring any changes to an application’s web.xml descriptor.
It is worth mentioning that there are not optional components and that the following technologies must be implemented fully for a solution to conform with the Web Profile:
- Servlet 3.0
- JavaServer Pages (JSP) 2.2
- Expression Language (EL) 2.2
- Debugging Support for Other Languages (JSR-45) 1.0
- Standard Tag Library for JavaServer Pages (JSTL) 1.2
- JavaServer Faces (JSF) 2.0
- Common Annotations for Java Platform (JSR-250) 1.1
- Enterprise JavaBeans (EJB) 3.1 Lite
- Java Transaction API (JTA) 1.1
- Java Persistence API (JPA) 2.0
- Bean Validation 1.0
- Managed Beans 1.0
- Interceptors 1.1
- JSR-299 1.0
- JSR-330 1.0
An issues that both Java EE and SE face is Sun’s inability to convince the community about its plan to “open up” the platform. This has been made even more pressing by the uncertainty that has followed the ongoing acquisition by Oracle. Concerns like these might be prohibiting organizations from doing a strategic investment in the platform and as the voting log shows where raised during the JCP process. In fact it was the reason that the Apache Software Foundation voted “No” for the Java EE 6 Spec:
RedHat:
The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no "field of use restrictions", as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing. However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR. Consequently, in the future, for any submitted JSR (by Sun Microsystems or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.
Intel Corp.:
By the time EE 6 JSRs come to Final Ballot, we expect a statement that the EE 6 TCK License does not restrict field of use, does not require implementing anything other than what is required in the spec itself (no "value add" preventing implementation of just the spec) and does not require any other license that restricts field of use of JCP Specs.
Apache Software Foundation:
Apache must regretfully vote "No" for JSR-316, as we contend that the spec lead - Sun Microsystems - is not complying with the JSPA with respect to Java SE TCK licensing. We believe that members of the JCP that do not comply with the letter and spirit of the governing rules should not be allowed to lead JSRs. This is not a statement about the technical merit or quality of work done by the Expert Group to date, and if it were not for the unresolved non-compliance by Sun, Apache would most likely vote "Yes".
Also it is very unclear at the moment which vendors and when, are going to implement the Web Profile. It is possible that VMWare, through Springsource, might end up doing so - they've certainly been talking about it in the dm Server issue tracker, but they've also expressed some negative comments about it in public. For example JürgenHöller, co-founder of the Spring framework, during his QCon presentation about Spring and Java EE 6 was negative about the Web Profile:
Implementing this profile is not very attractive. I am yet to see a vendor who is aiming to implement this profile but not the full profile.
Similarly Dimitris Andreadis, project lead for JBoss AS has expressed his concerns about the purpose of having “a pre-defined web configuration”:
As you know, you can trim down the JBoss AS configuration to the set of services that you actually need; this has always been possible with JBoss. Now having a pre-defined web configuration, this looks like more like a marketing decision at this point rather than a technical one. Removing capabilities and features is easier than adding new ones. For the time being we have focused on moving higher up the chain by introducing the JBoss Enterprise SOA Platform that adds JBoss ESB, JBoss jBPM and JBoss Rules functionality on top of JBoss EAP. But if there is true market demand, or the Java EE 6 profiles go forward, we'll probably create and support a Web Platform bundle, too.
JBoss has in fact announced that it is working on a Web Profile prototype for their application server, although their current offering, the JBoss Enterprise Web Platform “enhances the Java EE Web Profile with enterprise features”.
On the other hand Gavin King, creator of Hibernate, is positive that the creation of the Web Profile is a positive thing for the Java platform and will aid web developers who until now where trapped between either choosing a plain servlet container which lacked in features or take the overhead of adopting the full EE stack:
The Java EE Web Profile defines a "smaller" container, with just the technologies that most developers really need: servlets, JPA, JTA, CDI, EJB Lite. That makes EE easier to implement, which might result in a more vibrant market, with more implementations, and shorter release cycles. It definitely removes the main reason many developers give for not adopting Java EE.
Even better, the CDI portable extension SPI make it much easier to integrate technologies into the Java EE environment. And, since some CDI implementations also run in a plain servlet container like Tomcat, CDI can also serve as a foundation for integrating technologies into these environments.
In the same way, Sacha Labourey former JBoss CTO, is very optimistic about the potential of the Web Profile:
It is with GREAT pleasure that I’ve learned that the JCP EC had approved the final ballot for Weld and EE6!
This really finishes the work started with EE5 and clearly positions EE6 as the most powerful and yet the easiest to use Java runtime environment, clearly ahead of Spring and its XML logorrhea. Furthermore, the definition of a powerful Web profile without the hassle of some of the most legacy EE specs (IIOP anybody?) will give fresh air to the too many IT teams building (and attempting to maintain) their own Tomcat on steroids.
What do you think about the Web Profile? Does it help make the Java platform a compelling solution for web development?