After a long few months of hard-work, we finally see the light at the end of the tunnel for getting Resin 4 Java EE 6 Web Profile certified!

We are now passing the Servlet 3.0, JSP 2.2,  EL 1.2, JSTL 1.2, JSF 2.0, Bean Validation 1.0, CDI 1.0, JPA 2.0, JPA 2.0 and JMS 1.1 TCKs. Note, although JMS is not part of the Java EE 6 Web Profile, we are still implementing it since a number of our customers have asked for a lightweight messaging option in Resin.

The last TCK that we need to pass at this point in order to be Java EE 6 Web Profile compliant is EJB 3.1 Lite. As such, we do have the basic functionality for stateless session beans, stateful session beans and singleton beans including life-cycle, concurrency, registry/look-up, interceptors, security and transactions. Indeed, Adam Bien recently blogged about the usability of the current Resin 4 development release: http://www.adam-bien.com/roller/abien/entry/java_ee_6_server_resin and we have been demoing full-stack Java EE 6 applications for a while now including at JavaOne 2010 (albeit without EJBs, using EJB service annotations/aspects directly in CDI managed beans).

Resin TCK Progress

At this point, it is a matter of working through the cases caught by the EJB 3.1 Lite TCK. I’d say a majority of it is minor bug-fixes with singletons having the most and stateless session beans the least amount of issues.

Although technically not part of EJB 3.1 Lite, we are also implementing scheduling, asynchronous processing, remoting (Hessian based) and message driven beans because we feel these are valuable parts of the EJB specification. We will also include a JCA implementation for better resource pluggability. At this point, we have the basic functionality of timers/scheduling as well as asynchronous processing done. The remoting and the message-driven bean/JCA parts still need significant work, including creating a new messaging model around CDI events as a supplement to the older message driven bean model. My personal guess is that we will have the officially Java EE 6 Web Profile certified release of Resin 4 by the end of the year. We will then have a few releases focused purely on stability, optimization, foot-print, start-up/shut-down time and runtime performance since these have always been primary differentiators for Resin.

The final release of Resin 4 will allow us to then focus on some of the work around CDI portable extensions that we wish to do including Seam 3 modules/Arquillian integration as well as things like HTML5/WebSocket, modularity, cloud/NoSQL APIs, etc.

Obviously, Resin 4 is a very important milestone for us as a team but is very significant for the Java EE 6 ecosystem too. I would expect the JBoss guys to announce their final Java EE 6 compatible version shortly after us, probably followed by Geronimo, WebLogic, etc.  It seems IBM has been uncharacteristically proactive with the WebSphere Java EE 6 work too.

In the meanwhile, do send us your comments and wish us luck on the final stretch of the Java EE 6 implementation marathon!

We’ve used test-driven development from the beginning of Caucho, almost 12 years now, and it heavily influences our development, refactoring, and also our release cycle. Today, we’re in the final two weeks of the release cycle for 4.0.1 which means passing our regression test suite and working through load testing.

Each week in our release cycle is influenced by our TDD methodology. For Resin, we aim for an eight week release cycle, and usually slip a week or two so it ends up being ten-ish weeks.

(more…)

Thanks to Frank Greco and everyone who came out to see my presentation at the NY JavaSIG. I got some great questions and it looked like a lot of people were starting to understand the problems with interactive applications using HTTP. BAM is the way to go! Anyway, here are the slides from my presentation: NY JavaSIG slides on BAM/HMTP

And, a correction: During my presentation, I stated that there is no standard intereface for Comet on the server. While technically true, the new Servlet 3.0 draft spec has an API. Someone mentioned this during the Q&A and I said that while I had looked at the spec, I didn’t actually see the Comet references in there. Well, they are there in Section 2.3.3.3. I haven’t had a chance to review the spec thoroughly, but it looks like a nice compromise. Webtide’s Greg Wilkins has a nice intro here that features Comet use cases in Servlet 3.0. There were a lot of attempts to create Comet APIs from us, Jetty, Tomcat, and Glassfish, so if we can standardize on something reasonable, that will help everyone. It still doesn’t change the fact that HTTP was not designed for this kind of interaction though.