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…