This week, I’m teaching the Resin administration course, so last week’s meeting dealt a lot with preparations for that and the focus of the training. We’ll be discussing Resin 3.1 in depth this time, as opposed to last time when we also include Resin 3.2. Now that 3.2 is turning into Resin 4.0 and the first release isn’t out yet, we wanted to show the students a nice stable version.

The other main topic of the meeting was technical whitepapers. Nam is working on finishing up with his paper on Quercus performance (preview: 400% over standard PHP with APC), so that should be available quite soon. The other whitepaper we have in the planning stages is for the new Resin 4.0 cloud functionality. We had a nice phone meeting with a customer on Thursday to give a roadmap of where Resin and Caucho are going and they were very interested in using the cloud features, so we got even more inspired. This particular customer was interested in doing an internal EC2-like deployment (I think they meant hot redeploys with virtualization), so Resin 4.0’s capabilities would fit that quite well. They wanted more in-depth details about how Resin will achieve 1) distributed caching/sessions 2) cluster-wide deployment and 3) dynamic start and stop of cluster members. So far we’ve discussed the clustering in high-level terms, but now that it’s becoming real, it seems people want to get technical to convince themselves it will actually work and to see if it will fit the purpose they have in mind.

We had a brainstorming session on the topics we want to make sure are in the cloud whitepaper. They’re listed below. Please take a look at them and if you see anything missing, we’d love to hear about it.

(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.

Every Friday, the Caucho engineers get together to discuss the work we’ve done over the past week and to plan for the next week and beyond. As an experiment, I’m going to start a new weekly series on this blog giving a summary of our meetings. We hope you enjoy it…

Starting with version 4.0, Resin is moving in a new direction to allow users to take advantage of cloud computing infrastructure more effectively. Of course one of the first problems with “cloud computing” is the name itself. It seems like everyone has a vague (perhaps cloudy?) notion of what cloud computing is, so I did a bit of research before Friday’s meeting to make sure that we weren’t adding yet another definition to the mix. Happily, it turns out that we’re not. While the actual implementation of cloud computing infrastructure and tooling is under construction, the desire to be able to run applications transparently on a dynamically changing set of servers seems to be constant.

Our notion of cloud computing is that numerous instances of Resin will be run within virtual machines on hardware that may or may not be managed by the user. The behavior of these Resin clusters will appear to the application to be the same as if they are running on a single instance. The only thing that changes is the ability to scale as the application is running both up and down. What’s new about our approach is that it introduces distributed sessions, caching, and application deployment for web applications.

One of the other topics that came up at our meeting was Quercus Personal. Whenever we go to tradeshows or talk about Quercus, inevitably people want to run the compiled version for personal or hobby projects, but the full professional version of Resin is a bit out of their price range or they don’t really need clustering features. To address this market, we’re planning Quercus Personal which is exactly like Resin Open Source, except that Quercus compilation is available to speed up PHP. The price point is much lower since enterprise clustering is not included. Our goal is to make this version of Quercus just as easy as installing a LAMP stack or nginx/PHP.

Finally we talked about my work on the Eclipse plugin for Resin. This plugin is based on the Eclipse Webtools generic server functionality. We’ve got a basic version working with the standard .war deployment, but I recently made some modifications to allow running a web app directly from the Eclipse project directory. Resin 4.0 now allows deploying a web app dynamically across the cluster, so we also added a way to access that functionality directly from Eclipse. There are still a few places where we need to add UI elements to make this more natural within the Webtools framework, but the basic operation is now available. Of course, we’ll also be documenting the plugin and making it available for installation from directly within Eclipse.