Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Ryan Slobojan on Feb 27, 2008
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-250Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250EJB 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.0JAX-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?
The 5 Mandates of Software Development Teams - Presto Manifesto
Regaining control of the data centre
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Unix, Linux Uptime & Reliability Increase While Patch Management Woes Plague Windows (Yankee Group)
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.
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.
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. :)
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.
Option B looks to be a very good idea. I cant see any point in option A at all.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
5 comments
Watch Thread Reply