Archive for the ‘Engineering’ Category
Wednesday, April 8th, 2009
Because Resin 4.0 can now use Java Injection (JSR-299) for its configuration, we’ve taken advantage of the new syntax to redesign Resin’s rewrite and dispatch capabilities, used for sites migrating from Apache’s mod_rewrite module. The admin documentation is at http://caucho.com/resin/admin/rewrite.xtp and the JavaDoc for the tags is at com.caucho.rewrite (the JavaDoc describes the tags because Resin-rewrite uses Java Injection - JSR-299 for configuration.)
Rewrite matches HTTP URLs with a regular expression and dispatches them to servlets or load-balancing or HTTP proxies or HTTP redirects. PHP applications like MediaWiki and Drupal use rewriting to present pretty URLs to the world, but use /index.php internally.
Monday, April 6th, 2009
Last week I was been looking at ways to take advantage of Resin 4.0’s new cloud features within Amazon EC2. I’m in the process of developing some tools to make this simpler, but in the meantime, it’s already possible to get up and running with Resin 3.1 on Amazon EC2. In this post, I’ll show you how to create an Amazon Machine Image (AMI) with Resin and install WordPress on Quercus with MySQL so that your data persists on the Elastic Block Store.
Thursday, March 26th, 2009
There’s a lot of talk about “Cloud Computing” right now, including from Caucho, but much of it seems vague or over-hyped. You hear more talk about benefits of scaling, redundancy, and cost savings than about actual features. We recently put out a whitepaper talking about Resin 4.0’s support for cloud that hopefully shows what we’re providing. However it is a pretty big document with quite a bit of behind the scenes technical detail, so I thought I’d break it down a bit here to give you a look at where we fit into the cloud environment. In other words, here are the actual features in Resin 4’s cloud support.
Monday, March 23rd, 2009
There was a lively discussion a couple of weeks ago on the Resin interest mailing list about why people are using Apache with Resin and whether it’s actually necessary. Of course, we recommend that our users use Resin as both the HTTP server and the app server, but sometimes that’s not possible because of other legacy apps, non-Java apps on the same host, or simply internal politics. The trend in the non-Java world lately has been to move away from Apache to nginx because of its simple configuration and raw speed. For backend applications, it uses simple proxying or FastCGI instead of the mod_* model of Apache. I decided to check out nginx this morning and see how to hook up Resin. Turns out that it’s pretty easy!
Friday, March 20th, 2009
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 firstname.lastname@example.org
Friday, March 13th, 2009
You might have used Resin’s built-in database connection pooling, but did you know that Resin can also load balance across multiple database servers in the backend transparently? It’s as simple as adding more database drivers to your database pool. What’s more, Resin supports database server failover and even failover pools!
Thursday, March 12th, 2009
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…
Monday, March 2nd, 2009
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!
Wednesday, February 25th, 2009
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.
Tuesday, February 24th, 2009
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.)