The Web Profile is targeted at developers of modern web applicationsIMO, most of the modern web applications make use of REST. Or at least this is my perception. In Rails world, AFAIK, violating REST principle is a subject for brutal prosecution by the colleagues :) Luckily Java EE 7 fixes that mistake and JAX-RS specification is now a part of Web Profile.
Targeting “modern” web applications then implies offering a reasonably complete stack, composed of standard APIs, and capable out-of-the-box of addressing the needs of a large class of web applications.
OK, now you can really develop "modern" web apps with Web Profile, but...
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.
Sounds like redundancy to me. For instance, why would you need EJBs there? If CDI supported interceptors properly there wouldn't be a need for EJBs in that sense. Or, JSF? Well, I'm just not a fan of that.
What I'm trying to say here is that since for compatibility reasons there wouldn't be possible to drop specs from Web Profile, maybe it is now time to create a "Light Profile"? A minimalistic set of Java EE specs that would be sufficient for building modern web applications.
Of course the term is a bit foggy - what should we consider a modern web application. These days it is a combination of a REST backend and UI technologies such as HTML5 and JavaScript. My logic says that since Java EE doesn't specify UI technology then the main specification that required is JAX-RS and the complementary specifications to support transactions (JTA/JTS), persistance (JPA), and dependency injection (CDI). Of course, there are some nice complementary specifications such as Bean Validation and Java API for JSON processing. But I would definitely drop JSF and EJBs for sure.
This would bring the containers like Tomcat and Jetty even closer to the spec and who knows maybe one day we will have a Java EE "Jetty Profile", why not :)
7 comments:
Thanks for offering your opinion, it is most certainly a good thing. The issues of whether to include JSF and EJB into the Web Profile is not new however. They were discussed at length during the Java EE 6 time frame (I took part in that discussion -- it was one of the longest threads in JCP history) and none of the fundamental arguments have changed much (at least yet).
While it is true that HTML 5 may bring profound changes to how UIs are written, those changes are yet to truly materialize. In the meanwhile, the vast majority of server-side developers require a server-side web framework and JSF use is pretty pervasive, certainly amongst core Java EE adopters (like myself), even despite the abundance of web frameworks out there.
CDI was never intended to replace EJB. It makes no attempt to address concerns such as declarative transactions, security, scheduling, asynchronous processing and the like -- EJB already does that. In fact, the EJB @Asynchronous and @Schedule annotations were moved to EJB Lite (EJB Lite is an EJB sub-set targeted specifically for the Web Profile) because the community asked for these EJB features in the Web Profile. While you can certainly rewrite EJB features ad-hoc using CDI interceptors there is little reason to reinvent the wheel, not to mention it would be strictly non-standard. Now, all this might change in the near future as we start decoupling more and more EJB style services from the component model as we have started to do with the JTA @Transactional annotation in Java EE 7.
As to standardizing Jetty and Tomcat, there is aleady a Tomcat Java EE Web Profile implementation - TomEE. In fact, the total number of Web Profile implementations are now eight -- inclusing Resin, a former "Servlet only" container. It hardly makes sense to make wholesale changes to the Web Profile based on just Jetty!
Lastly, it is indeed possible to drop specs from a profile if there is solid reasons to do so...
All views voiced are my own, not necessarily Oracle's.
Hi Anton,
this goes into the direction of a "Minimal Profile" ... like Antonio suggested back in June last year:
http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2012-06/message/4
I've written down my 2c already about this:
http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2012-07/message/0
Without a proper modularization solution in place this is going to end up as a "deploy 50mb apps to tomcat" solution which really can't be a solution at all ...
- M
Come forward to us & get solution for your income problems ,(11548)
Complete Our 3 day work at home training course and be
placed in a work at home job, with a real company that
will earn you over $50,000 per year Guaranteed!
Earn up to $100,000 Per year from home
as a certified home worker for more details visit: (http://www.JobzInn.com)
"My logic says that since Java EE doesn't specify UI technology then the main specification that required is JAX-RS and the complementary specifications to support transactions (JTA/JTS), persistance (JPA), and dependency injection (CDI). Of course, there are some nice complementary specifications such as Bean Validation and Java API for JSON processing. But I would definitely drop JSF and EJBs for sure."
--Sounds like Spring...
Typically TomEE is just a EE Tomcat...and why EJBs would be evil? EJB 3.1 are very close to CDI beans...they are not different enough to justify their removal.
What would be the benefit of a profile like this? The clear benefit of the web profile in EE 6 was that container vendors could drop some of the old specs and still be spec. compliant. This also opened up the container marked to new and smaller players.
An app server that has proper modularisation (e.g. Glassfish or JBoss AS) enables you to turn on and of whatever you need or don't need, and by lazily starting container services having more components in the app server should not make a difference during startup either. From an application developer perspective it doesn't matter if there are more APIs available then what I currently need; just don't add those APIs to your build classpath.
The real problem is in the fact that we lack a proper modularisation mechanism in Java EE, both in the spec itself and even more while developing applications. There is no way to define profiles that fits everyones needs, there will always be either too much or too little.
The real problem to focus on is how we write and deploy modular applications ourselves.
This iss a great blog
Post a Comment