It’s the last day of TSSJS here in Las Vegas and it’s been a really successful and fun conference so far. The skill level of the attendees is great, meaning a lot of meaningful conversations on the industry and trends in development. On Wednesday, our CEO Steve Montal gave a quick 5 minute overview of our current and upcoming technologies like Resin 4 with Java CanDI and cloud support as well as Quercus. There was a lot to pack in, but even this short speech garnered us a lot of attention. We also handed out our Resin 4 whitepaper which I think was well-received.

Thursday was a particularly interesting day because of talks at the beginning and end. Rod Johnson started out with a talk on Spring, where he (once again) declared JavaEE unnecessary and overly complicated. He claimed that an acquisition of Sun by IBM would be meaningless to developers, because nobody cares what they do anyway. It was a bit controversial to say the least. The part that irked me the most was that he claimed that SpringSource is the only independent application server vendor left… Caucho has been around for 10 years and is going strong, even in this economy. We predate Tomcat and SpringSource, so I think Rod was mistaken on this point.

At the end of the day, Reza Rahman lead a discussion of the direction and progress of JavaEE 6. We’re targeting the Web Profile and we’re participating in the JSR-299 (Java CanDI) expert group, so naturally we were interested in the community’s opinion of the new standard. There was an interesting debate on the contents of the Web Profile, with a lot people arguing for a profile that does not include a view technology. Reza explained that the view of the committee was that a JavaEE certified project needs to be able to build a complete application out of the box without add-ons, yet not prevent add-ons. The Web Profile is targeted at the 80% of developers who don’t need the extra bells and whistles of the full profile.

It turns out that the only thing holding up JavaEE 6 is the debate over Java CanDI and whether it should be included. There are not a lot of complaints about the technology itself, but rather its scope. What I found interesting is that while this topic seemed to be very contentious within the JEE 6 EG, the attendees of this session just wanted Java CanDI in. Its utility was apparent to them and they didn’t care about the political debate, they just want it in. Of course, that’s just what I heard…

Update: If you want the Java EE 6 spec committee to include Java CanDI (aka JCDI, aka JSR-299), let them know at jsr-316-comments@jcp.org

Over the last couple of weeks, I’ve been preparing a whitepaper to explain the technical backing of Resin 4.0’s dynamic clustering support. We’re planning to have it available in printed form at this month’s TSSJS in Las Vegas, but you can download it now!

This blog is now 1 year old! A year ago today, we made the first blog post. Thanks to everyone who’s read, subscribed, and commented!

A quick update on what’s going on this week: the Resin team is working on the big changes for Resin 4.0 including the dynamic server support that offers distributed sessions, distributed object caching, and remote application deployment. The JavaEE 6 compliance work for Resin 4.0 is also under way, with the team focusing on EJB 3.1 Lite this week. The Quercus folks are working on improving the already awesome performance and reducing the memory footprint. Dynamic languages can be rough on the allocation system..

I’ve been finishing up a whitepaper on Resin 4.0 and all its new features that should provide an in-depth introduction to what Resin 4.0 does and how it does it. We’ll be distributing it at TSSJS next month in Las Vegas and on the website soon. I’m also working on Hessian Flash/Flex this week, bringing it up to speed with the latest Hessian 2 protocol fixes. In addition to the rigorous regression test that we run, I’m planning on writing an application in Flex for the next training course that should find any problems that show up in real use.

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

Because the main purpose of Resin 4.0 was support for dynamic servers, we needed to upgrade our distributed session management to handle the case where servers can appear and disappear frequently. Resin 3.1 session replication relies on a static set of servers to choose backup and triplicate servers. Dynamic servers change that model because a 3.1 session backup might be shut down indefinitely. So we needed a new architecture.

At the same time as we redesigned sessions, I wanted to generalize the distributed store to support standard caching and storage using the javax.cache API, while retaining the scalability and reliability of our original design.

• A hub of 3 fully-redundant servers for reliability (the triad)
• Other servers dynamically appear and disappear for deployment flexibility
• Updates using lightweight messaging using BAM/HMTP
• Cache entry ownership and leasing for performance
• Support storage (infinite expire), caching (timed expire), and session (timed idle invalidation)
• Support serialized objects (using Hessian), and binary data

The cache architecture is heavily influenced by the messaging and extra complications of distribution.

(more…)

For the Resin 4.0 remote deployment, I wanted some key features: incremental updates, transactional updates, reliable replication, manageability, and solid performance. It’s taken several months of toying with alternate architectures until the current design came together. At the core of the deployment architecture is the .git source code repository.

• atomic updates
• consistent file store - no broken updates
• independent - multiple writers and readers avoid seeing partial updates
• durable store to the filesystem (and replicated)
• incremental updates only of changed files

The key insight in the .git design is using a hash to identify versioned files. The hash design solves the transactional problem by treating files as immortal, immutable, written-in-stone documents.

(more…)

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 week, I wrote a post about how to use the new remote deploy functionality in Resin 4.0 using Ant and Maven. Now I’ll show you a click-by-click walkthrough of how to use the same facilities from the Eclipse plugin. Some of the navigation in Eclipse can be tricky if you haven’t used it before, so there’ll be screenshots all along the way. (Warning: there are lots of images below the fold…)

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

Scott and Alex have been working hard to make remote deployment possible in Resin from the server side. For the past couple of weeks, I’ve been working on making clients that can deploy your application to a running server. We have a number of vehicles in the works including an ant task, a maven plugin, and an Eclipse WTP deploy target. The interfaces to those are still under construction, as is the whole remote deploy framework, but I thought I’d give a quick preview of how to configure Resin and deploy to it.

(more…)