Site Archive (Complete)
Java Blog: Spring a possible Java EE Profile?
Java
SWAINE'S CAFE

Black. No Sugar. Extra Caffeine.

by Mike Swaine
ERIC BRUNO'S BLOG

Java: The Daily Grind.

by Eric Bruno
October 18, 2007

Spring a possible Java EE Profile?

I recently spoke with Rod Johnson of Interface21, the maintainer of Spring and related software, about the future of Java EE.

What I learned about Java EE 6, and Interface21’s involvement, was very interesting. For instance, one of the largest and most welcome changes is the notion of profiles for Java EE. A profile is a subset of technology components that are targeted for a specific use, and this is also how Java ME breaks up its APIs so that applications can use only portions of it.

For instance, assume you’re deploying a web application built purely out of JSP, and maybe a standalone Servlet or two. You need a web server with a Servlet container. You can choose Tomcat, but if you’ve already invested in WebLogic, for instance, you may prefer to use that. However, WebLogic includes a whole lot more than support for a site built with JSP; it has an EJB container, a JMS provider, and everything else the Java EE specification demands. The problem is that with each deployment, you’re paying for a whole lot more than you’re using, and you have the bloat that comes along with it.

Java EE 6 profiles attempt to solve this problem. One proposed profile is a Web Profile, which is aimed at applications like this example. Other possible profiles are a Web Service Profile, an Enterprise Profile (includes EJBs), and a Real-time Profile. According to Rod, profiles truly redefine what an application server is. Be sure you’re ready for this change.

Another radical change with Java EE 6 is its extensibility. There will be deep support for users to extend the functionality of the application server in standard ways. This is one area that the Spring Framework will play a key role. Many users struggle at first with how to integrate the traditional Java EE features with the goodies that Spring offers. Changes in the next version of Java EE will not only make this decision more straightforward, but will provide standard support for it as well.

In fact, Rod mentioned that Spring itself may become part of, if not key to, a new Java EE profile all its own. I asked Rod what his goals are as a member of the JCP, and expert group for JSR 316. He stated that he wants to see the community benefit from a simpler Java EE model that gives them more choice in how the build and deploy their enterprise Java applications, regardless of whether that includes the Spring framework or not. Good answer.

The specification, and the fact that Sun is leading it, is not without controversy, however (see http://www.javalobby.org/java/forums/t99039.html). For instance, Apache took a hard-line stance and did not approve the specification, solely because they feel Sun is in violation of the Java Specification Participation Agreement (JSPA) in general – not necessarily regarding this specification. That’s a cheap shot in my opinion. I understand Apache’s view of Sun these days, but I don’t think it should translate into a vote on an unrelated JSR. That vote should be based on technical merits.

What’s your opinion on Java EE 6, the Sun / Apache situation, and the vote? Respond to this blog and let us know.

Happy coding,
EJB

Posted by Eric Bruno at 08:03 AM  Permalink




 

♦ sponsored
INFO-LINK


Related Sites: DotNetJunkies, SD Expo, SqlJunkies