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!

As part of the Resin 4.0 work, I’ve refactored and renamed the key BAM classes to better describe the architecture and roles. The key classes are SimpleActor and ActorStream.

BAM is a lightweight serializing messaging API, designed for small, bidirectional, interactive messages for applications like SAAS (software as a service) or online gaming. Resin 4.0 uses BAM/HMTP for its clustering protocols, including our distributed caching, JMS, and distributed deployment. BAM is designed to work with multiple wire protocols including HMTP (Hessian Message Transport Protocol) and XMPP (Jabber, eXtensible Messaging and Presence Protocol.)

(more…)

Chris Chen has a nice description of messaging use cases from resin-interest:

I think integration is interesting, but more relevant are the use
cases surrounding each type of system.

*) BAM - lightweight for super fast and scalable message brokering for
things such as stock market price streaming (no need for persistence)
or twittering type messages. The main thing here is “as fast as
computerly possible”.

*) JMS/persistent subscriptions - These are for those that broker
highly mission-critical data. The primary interest here is “as
reliable as possible”. Speed is less of a concern compared to the
data. Inherently, this type of use conflicts with BAM. Transactions
will bog down the speed.

*) ESB/SOA activities - these, in my view, are for those that require
high data/service compatibility and integration. The message here is
“as promiscuous as possible”. The focus is on the adapters and being
able to communicate and connect to many different systems.

I think all of them centers around a hub-spoke model. It’s possible
to integrate all of them together through layers. The lowest layer
(in this case, BAM) focuses entirely on speed. A secondary layer can
add the reliability that can be similar to XEP persistence. Possibly
a persistence component that subscribes and listens to any topic/queue
that requires such a service and separately deals with reliability. A
third component can create a set of adapters to connect to different
systems. This third component mainly focuses on data/message
translation.

Just a quick update to let everyone what’s going on this week. I’ve got three big projects that I’ve been working on this week. First up is the newsletter. We trying to get a monthly newsletter going to let people know about success stories, new features in Resin, upcoming events, and general Caucho news. That’s cool and I like letting everyone know what’s going on, but the fun part has been writing the newsletter sending app. I’ve been writing it in Quercus and using some of Resin’s lesser known facilities like scheduled tasks and the authenticator framework. It’s pretty cool how these two features come together and make PHP apps so much easier to write. When some time comes around (i.e. after May and JavaOne), I’ll try to write up a description of how I put all these things together.

Hessian messaging (codenamed HMPP/Hemp) is getting pretty exciting. It’s inspired by XMPP and basically allows creating truly rich client side applications. Actually, it’s even more than that. It combines RPC and messaging into one elegant protocol which lets you do pub/sub and a bunch of other cool things. It’s still preliminary now, but I’m writing what should be a really cool demo for JavaOne. Make sure you stop by the booth to check it out!

A couple of months ago, I talked with the guys from Terracotta at the Silicon Valley JUG. Since then, we’ve been working out how to make sure Resin and Terracotta work together. The basic distributed shared objects work fine, pretty much out of the box. Earlier this week, I was also able to get Terracotta’s distributed sessions going, but then tried it again and it stopped working. Don’t you hate it when that happens? It seems there’s an issue with classloader naming. Anyway, we expect to get it worked out soon so Terracotta and Caucho customers will hopefully get to use the full features of both companies’ software.

Woohoo! I’m pretty excited about this one. There are so many new cool features. Here’s the list:

• Resin IoC - Fully WebBeans (JSR-299) compliant IoC container
• Embedded Resin - Use Resin in an existing application or within a unit testing framework like JUnit.
• Support for gobs of 3rd-party packages: Maven2, Ivy, Mule, Struts2, CXF, Wicket, and more!
• Lots of updates to security, including an update to the authenticator configuration
• Exposure of the Resin JMS queues as BlockingQueues
• Watchdog updates
• Security updates
• Resin remoting

Wow… there are a lot of features there. I was going to write a bigger entry to cover everything, but I think now that it would be better if I split it up. Over the next few days, I’ll be writing more in depth entries about each of these features. It’ll probably take a week…