JavaOne 2008 Conference (2) - Enterprise Java

Java has been there for more than a decade. The JavaOne 2008 conference shows that the technology is maturing, new ideas keep coming, and lots of future opportunities are still finding their ways. Here are some of my notes on JavaOne 2008 about Enterprise Java.

Traditional EJB Container will disappear
Currently, J2EE container has two flavors: The web container, and the Enterprise JavaBean (EJB) container. Tomcat is the most famous web container, and lots of the enterprise vendor sell the “application server” as the combination of both EJB and web container. Customers usally pay entry level charge for the “express edition” that gives you the web container only, and pay premium for the “enterprise edition” that can do the full J2EE stack, including EJB. Despite of Remote access and lookup, EJB is simple a Java object that has the following features:
-Lifecycle is managed by container
-Dependency injection by the container
-Object allocation is managed by container
-Access container managed resources, such as listeners, data source, connectors
In the next version of EJB, these feature can be included as part of the web container, so a web container is also a light EJB container. With the addition of annotation, there is no more need for define a local EJB separately (which is a bad idea from day one anyway). I think this will help acceptance of EJB, as a way of providing services. Java Persistence API already provides an alternative way of ORM aside from Entity EJB without containers. With this EJB 3.1 annotation change, it melts the boundary of the Express Server and the full Enterprise Application Server.
I don’t think EJB model itself will be a legacy, but the idea of charging premium for EJB container might no longer be true.

JSF tools are mature
JavaServer Faces is designed to be a good model for tooling. However, the tool support of JSF was horrible for quite a while. Rational Application Developer didn’t get it right. Earlier version of NetBeans didn’t do too good either. This year watching Oracle’s demo, looks like the JavaServer Faces are quite mature in the tooling world now. Not only Netbeans support on JSF is great, but also other part of the community is improved. Oracle’s tool is based on Eclipse and the JSF works. I hope IBM Rational can get them right in the future.

A side note, seems all enterprise company has moved their IDEs to Eclipse now: IBM, Oracle, CodeGear (Borland), Oracle-BEA, etc. Sun is focusing on the NetBeans of course, and looks like they are doing well too. I hate to have two IDEs for the same language in my desktop and I always choose Eclipse. However, I don’t mind to have an IDE for a different language, such as Ruby or JavaScript. NetBeans got me for this reason, not as a Java IDE (sorry).

Richer web experience is the trend, new security concerns rise
Ajax, Flash/AIR, JavaFX, and Silverlight make the web client market so busy, and consider all of them have their mobile variations. For so many years no one beat the Flash on rich web experiences, until Google shows how Ajax can serve the same purpose in a consistent user experience. Every year Sun tries to make Java come back to rich web experience. This year it is wrapped under JavaFX. Rich web experiences is not going away, and new view of web security need to be considered. The traffic between server and rich client might carry more information than you think, and the rich client might contain more business logic than the plain old HTML page. Hackers can have more fun to read the code now because the client is rich.

Web 1.0 technology is still the mainstream
While many people care about SOA and EJB, the topic that attracts most audience are still the web technology. Scalability is an apparently interesting topic. The comparison between web frameworks are very popular. Struts 1, Struts 2, JSF RI, JSF MyFaces, Spring MVC, they all have their pros and cons. Some of them excel others significantly in lowers load. Some of them are fast, but with some unpredictable pauses from time to time which might cause DoS.