Java EE 6 Spec Lead Requests Community Feedback on Web Profile Options

Posted by Ryan Slobojan on Feb 27, 2008

Sections

Process & Practices,

Development,

Operations & Infrastructure

Topics

Application Servers ,

Community ,

JCP Standards ,

Java

Tags

EJB ,

Community ,

Java EE

In a recent blog post, Java EE 6 (JSR 316) specification co-lead Roberto Chinnici presented the two leading candidates for the Java EE 6 Web Profile, and asked for feedback from the community on which of the two options the JSR 316 Expert Group should move forward with. InfoQ took the opportunity to analyze each of the Web Profile options in greater detail.

One of the new ideas which will be arriving with Java EE 6 is the idea of profiles, which is described in more detail in this InfoQ article. Owing primarily to time and resource constraints Java EE 6 will likely have only 1 profile, which is the Web Profile. Chinnici described this as a benefit:

One of the driving ideas around profiles is to move away from a big-bang model for the delivery of the platform, enabling smaller, focused communities to forge ahead in the context of a profile they define. It is natural then to achieve as much decoupling as possible from the beginning and push profiles into separate JSRs, to be finalized on their own timeline.

This said, we originally proposed defining a Web Profile as part of the Java EE 6 JSR because (1) it's helpful to have a use case at hand when developing the notion of profiles, as opposed to doing so in the vacuum, and (2) we believe that there is interest in the market and in the community for a web-centered profile of the EE platform. Incidentally, the amount and depth of EG mail that the Web Profile generated more than proved the first point.

Chinnici presented each of the Web Profile options as a side-by-side listing of component technologies, with the full Java EE 6 technology stack also listed for comparison:

(A)	(B)	Full platform
Servlet 3.0 JSP 2.2 JSR-45 EL 1.2 JSTL 1.2 JSR-250	Servlet 3.0 JSP 2.2 JSR-45 EL 1.2 JSTL 1.2 JSR-250	Servlet 3.0 JSP 2.2 JSR-45 EL 1.2 JSTL 1.2 JSR-250
	EJB 3.1 (Lite) JTA 1.1 JPA 2.0 JSF 2.0 * Web Beans 1.0 *	EJB 3.1 JTA 1.1 JPA 2.0 JSF 2.0 Web Beans 1.0
		JAX-RS 1.0 Connectors 1.6 JAX-WS 2.2 JAXB 2.2 JSR-109 1.2 JSR-181 1.1 JMS 1.1 JAF 1.1 JavaMail 1.4 JSR-115 JSR-196 JSR-88 1.2 JSR-77 1.1 JAX-RPC1.1 JAXR 1.0

Chinnici also noted that the inclusion of the two technologies marked with * in proposal B are controversial, and that the "EJB 3.1 Lite" referred to is a proposed subset of EJB 3.1 functionality which still has to be accepted by the EJB 3.1 (JSR 318) Expert Group.

Another feature of Java EE 6 which plays an important part in the Web Profile discussion is extensibility:

[...] in the web tier extensibility refers to the ability of taking advantage of third-party frameworks with a much simplified programming model. Developers won't need to manually edit the web.xml descriptor to add context listeners, filters, servlets and servlet mappings per the instructions given by their favorite web framework. Rather, adding a third-party jar to the web application will trigger the addition of all these elements, with no developer intervention. We expect that this feature will cover the requirements of all major web frameworks such as JSF, Struts and Spring MVC, scripting solutions like JRuby on Rails and Grails, WS-* web services following the JAX-WS 2.0/JSR-109 model and RESTful web services written to JAX-RS 1.0. One important point to note here is that extensibility is agnostic to whether a technology is based on a JCP standard or not.

Chinnici also pointed out that the Web Profile was meant as a base specification, not as a comprehensive list of technologies - vendors have the freedom to add new extensible components to a Web Profile-compliant Java EE 6 implementation, which is intended to complement recent attempts by application servers to present a modular infrastructure. Chinnici also expects there to be an experimentation phase in which several vendors mix and match Java EE 6 technologies with the Web Profile base to test the marketplace, and that one or more of those feature sets will become popular and form the basis for another Java EE 6 profile.

Current technology interaction requirements will also be maintained in the Java EE 6 specification for only those profiles which contain all of the component technologies -- For example, the interactions between JTA and servlets will apply to Web Profile option B, but not to Web Profile option A since JTA is not part of option A. According to Chinnici, the reasons for this are:

[...] on one hand, we think that the Java EE requirements add significant value to standalone technologies, as testified e.g. by the large number of servlet containers which implement JTA in a way that is compatible with what Java EE mandates; at the same time, calling out the requirements will help ensure that applications that target profiles will work on the full platform. Overall, this makes profiles more than just collections of independently tested technologies, because those technologies will be tied together in interesting ways, deliver more functionality than they would on their own.

Finally, the question of compatibility is raised, with Chinnici pointing out that any application that requires Web Profile plus some other Java EE 6 component (e.g. JAXB 2.2) will never run on plain Web Profile. The solution to this is given as the full Java EE 6 profile, with the idea that any application that will run in a subset of Java EE 6 technologies will run on the complete set of technologies as well.

Which Web Profile do you prefer? Option A or Option B?

1. Back to top

   JMS in A or B

   by Jacob Hookom

   Trusted async processing is huge-- the event driven concepts and the fact that not everything should be efficiently processed in the request thread-- come on-- JMS/events isn't a swappable technology like XML/RPC/SOA communications-- JMS should be represented as a much more basic facet in these profiles.

   Reply

2. Back to top

   Agree with async and add webbeans

   by Donald Kittle

   I agree with Jacob on async processing.
   
   I'd also like to throw a vote in for WebBeans to ensure that all containers support the same basic scopes and to provide wiring between components.
   
   My preference would be Option A with these two additions.

   Reply

3. Back to top

   Web Profile without JSF

   by Jason Lee

   I'll admit a bias as well as not having followed this really closely, but I don't understand why a web profile* would leave out the standard web app framework. Seems a little weird. Maybe someone can clue me in. :) In the meantime, I'll follow the links...
   
   * Standard in the sense that it's in the EE spec, not in the everyone-is-using-it sense of the word. Though they should be. :)

   Reply

4. Back to top

   Re: Web Profile without JSF

   by Samuel Doyle

   I don't see any sense in excluding WebBeans or JSF from the profile whatsoever?? I'm more in favor of option B at a glance but that opinion could change as I delve into this more. If my option does change it will likely lean more to full platform then A.

   Reply

5. Back to top

   Option B please.

   by Neil Belford

   Option B looks to be a very good idea. I cant see any point in option A at all.

   Reply

• Older >