By adding Java to their App Engine, Google has opened the door for a whole slew of languages that have been implemented on the JVM, now including PHP via Quercus. For the last couple of weeks, I’ve been looking at Google App Engine and what its possibilities are for Quercus. Some folks from a PHP shop in Britain got Quercus running, but the version they were using was pretty old and seemed to come from a bizarre cross slice of our SVN repository. We wanted to make sure that the current version of Quercus runs on GAE with all its performance and compatibility enhancements. So Scott created a GoogleQuercusServlet just for the task. I wrote up how to get started using Quercus on GAE and some notes about what PHP can and can’t do within GAE at the moment.
Archive for the ‘Engineering’ Category
This week, I’ve been prepping for a talk on Quercus in which I promised to show a demo of Spring MVC using a PHP view. So that means that I actually had to do it. Turns out it was quite easy and PHP makes for a very nice, compact view technology for Spring MVC. This is a bit of tease since the code for this won’t go out until at least next week, but since a number of people have been asking for this a while, I thought I’d give a preview…
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.
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.
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.
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!
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
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!
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…