After a hiatus during a paper/presentation/training season, I’ve finally gone back and cleaned up the Flash/Flex versions of Hessian and BAM. The Hessian side is now updated to be compatible with the latest Hessian 2 changes. As Scott mentioned, the BAM API and protocol has undergone some changes since the last revision, so I’ve rewritten the Flash implementation of that as well. It was a surprisingly large amount of work, but I think everything is now up-to-date as well as a bit more stable.

For those that are interested, here’s a quick hello world with the new BAM API with a Flash client and a Java backend…
(more…)

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…)

When you deploy an application using eclipse or ant, Resin propagates the .war updates to the cluster using the triad as the reliable store. The deployment is both incremental and transactional. Only changed files need to be sent, and the updates are only visible when they are complete and visible. Partial or incomplete deployment does not update the site.

1. eclipse/ant sends the .war to triad server A
2. Triad server A replicates the .war to triad servers B and C
3. The triad updates the rest of the cluster with the new .war file
4. Once all servers have the new version complete and verified, they can restart the web-app with the new data

(more…)

Last Friday we discussed a number of topics, but the only technical subject that came up was the naming for the BAM API. I’ll discuss that first. As you may know, we’ve been working on BAM for sometime now and even given a few talks on it. We’re using it extensively for the internals of the dynamic clustering implementation, but originally we were planning on making it a public API for games, finance, and other messaging based applications. That’s still the goal, but the other work on Resin 4.0 has pushed back the time line for the release of BAM at the user level.

After attending this week’s SF Java Meetup on Scala, I started comparing Scala’s actors and BAM agents/services. There are a lot of similar concepts, but this started us thinking about whether we shouldn’t rename the A in BAM, which currently stands for agent, to actor. Well, BAM can handle the duties of an actor, but it actually makes more sense to think of the building blocks as services. So it may turn out that like many architectural/standard acronyms, the letters of BAM won’t actually stand for anything. Anyway, we decided that our interfaces will have the prefix Bam*, while abstract classes will not. And the word “agent” is going away…

As for the non-technical points we touched on, probably the most relevant is the reorganization of the documentation. We’ve got a lot of docs, but they’re a bit scattered, so we’re planning on refining them and putting them into a book-like structure. There’ll be three parts to the book: an administrator guide, a developer guide, and a cookbook. As you may have noticed, we’re moving to a completely WebBeans-based configuration model. If you saw my post from last week, you know that tooling for WebBeans should be extremely useful and straightforward. Because of this, we may decide to create a doclet that outputs documentation of our configuration directly from the code!

A couple of other small topics came up this week as well. Many of you may know that we’ve been sending out a Caucho monthly email newsletter since last September, but we never actually had a formal way to sign up for it. We’ll this week we’ll be changing that by allowing you to sign up on the site and to view the past newsletters. Just keep checking the front page of caucho.com and you’ll see it as a new tab. The last thing that came up was our training course. The second class will be here in just over a week! There’s still a couple spots left, so if you’ve been putting off signing up, now it the time to do it. This week I’ll be putting in a few updates and polishing the material, so it should be a good one.

With the rise of instant events like twitter and RSS, publish/subscribe technologies are finally getting the respect they deserve. With HMTP, a client can subscribe to a message stream and wait for messages to arrive, avoiding the need for polling. In fact, since HMTP is an addressable architecture, the client can subscribe to multiple publishing services at once, with a single connection and receive notifications as they happen, not waiting every 15 minutes.

To support publish/subscribe (and following the Jabber/XMPP specification), HMTP has 8 packets devoted to subscriptions and presence notifications:

• presence - notify a service that a client has logged in
• presenceProbe - query for client capabilities (text, html, mp3, etc.)
• presenceUnavailable - notify that a client has logged out
• presenceSubscribe - request for a new subscription
• presenceSubscribed - successful subscription notification
• presenceUnsubscribe - unsubscribe from a service
• presenceUnsubscribe - notice of unsubscription
• presenceError - error occurring during presence/subscription

(more…)

2008 has been a great year for Caucho and we’d once again like to thank our customers, users, and community members for their support! This year we’ve seen

• Resin 3.1 become stable
• The introduction of BAM and Resin 3.2
• New large-scale deployments of Quercus
• A new streamlined Hessian
• Early snapshots of Resin 4.0 featuring cloud computing and OSGi

But we’ve made more than just technological strides over the past year — we’ve also been reaching out to the community:

• As Caucho’s evangelist, I had the chance to speak 8 times this year
• I’ve written 4 articles about Caucho products
• We created a Caucho Newsletter
• We launched a new training program
• We started this blog

Thanks again for a great 2008! See you in 2009…

In case you haven’t noticed or checked out what we’ve been doing with BAM, now might be a good time. BAM takes its inspiration from XMPP, but expands it into a fully-fledged enterprise message architecture. What this means for developers is that we’re presenting a much cleaner, easier, and more composable framework in which to write your message-based apps compared to SOA and JMS-style approaches. How do we know it’s cleaner and easier? We’re using it ourselves as the basis for our next-generation of Resin for advanced clustering features, remote deployment, and even JMS. This being said, BAM is still in development so it might take a couple of releases before we declare it stable.

If you’re interested in checking out BAM, come on out to the Silicon Valley Code Camp this Saturday to see me talk about it.

The Silicon Valley Code Camp is coming up in just under 3 weeks and they need to figure out how big of a room to assign to each talk. If you’re coming to the Quercus and/or BAM talks, please go and let them know your interest on this page: Caucho Sessions. That way we won’t have to worry about not having enough seats.

You might have noticed that posts slowed down here after my talk at JavaZone, which is because I took some time off to see Scandinavia. But I’m back now and getting ready for even more upcoming events! Just a quick review:

1. San Francisco Java Meetup - I’ll be speaking here again, this time about Resin’s OSGi container implementation, as well as general OSGi issues along with fellow Java Meetup regular, Andrew Headrick. This is just one week away on Monday, Oct 6 at 6:30. The signups are full right now, but keep an eye on the page in case anyone drops out…
2. Resin Administration Training - There are still a couple of spots left for this course, so sign up ASAP to guarantee your seat. I’ll be teaching this at Marakana’s facility in San Francisco on October 22-24. It should be an action packed 3 days!
3. Silicon Valley Code Camp - This informal, but highly technical conference is growing by leaps and bounds. With already over 500 signups, I expect the Code Camp to be a ton of fun and very successful. I’ll be speaking on Quercus and BAM, so stop by for those and the other speakers’ talks on Nov 8 & 9 at Foothill College.
4. Devoxx - You might know this as JavaPolis or briefly JaVoxx, but the newly renamed Devoxx is still the same great conference that attracts developers from all over the world. It will be held Dec 8-12 in Antwerp, Belgium. I’ll be giving a talk there and Caucho is a plugin partner, so look for us on the convention floor as well.

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.