The Caucho team just got back from Las Vegas for TSSJS and we had a great time. TSSJS is a really good conference to attend, especially from the point of view of a company like Caucho, because there is a real developer focus. The people there build real server-side applications and know what they’re doing. There were a number of questions about Resin, our own Reza Rahman gave several talks (including a keynote on Resin), and I got to see some interesting presentations from a wide variety of speakers.

(more…)

We at Caucho are very excited in working steadily towards getting Resin certified on the recently finalized Java EE 6 Web Profile. Along with GlassFish and JBoss, we are aiming to provide one of the earliest solid implementations for Java EE 6. In fact, Resin is the only major application server focused solely on delivering a very lightweight implementation targeting just the Web Profile.

This blog entry briefly discusses the Java EE 6 Web Profile, what it offers and how it fits with the lightweight development philosophy of Resin as well as the details of our implementation including Resin extensions to the Java EE 6 Web Profile.

(more…)

There’s still one more day of sessions left at JavaOne, but the Pavilion with all the booths is now closed, so I thought I’d give my impressions of some of what we saw from the booth. Almost all of the Caucho staff was at the booth at some point and because the company is mostly composed of engineers, we were able to have a lot of useful technical discussions there. These are some of the hot topics that people wanted to talk about:
(more…)

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

If you missed Monday’s talk by hi5’s Paul Lindner, you missed a great presentation. Fortunately, the slides are available on the meetup group’s page. Paul talked about the true ins and outs of running a hugely scalable, high performing social networking site. A lot of the architectural points he made are applicable to more than just social networking though. Basically, they do a ton of caching, a ton of monitoring/profiling, and just generally really clever use of resources, both hardware and software. Oh, and they also use Resin. Paul claimed hi5 to be one of the largest users of Resin.

The May Netcraft web server survey shows Resin is the top Java web server! Last month, Jetty managed to get on top for a moment to much fanfare, but if you look back over the past Netcraft surveys, Resin consistently tops Jetty and now it even tops every other Java web server.

We’re very proud of this achievement, but I’d like to note exactly what this means: It should mean nothing to you in terms of which technology you’re choosing for your project. However if you find that Resin fits the bill, you can be assured that you’ve got a large community of users who know and use Resin.

One of the issues with Quercus adoption is where to host it. At the moment, there are a ton of PHP developers/users using cheap, plentiful PHP hosting. For a lot of users who are putting up smaller sites which generate little or no revenue, this makes a lot of sense financially. Unfortunately, Quercus is not what’s being used in those hosting environments. Using Quercus requires that you have a Java host or ISP, hopefully Resin :-), and those haven’t been really affordable for most hobbyists.

Last week Sam Heisz, one of our Technical Sales people, pointed me at linode.com, a really cool web host that gives you a virtual machine on which you can run Linux. They have a number of distribution images already set up and you have root on them once you get set up. They’re only about $20/month at the entry level, so it’s still pretty affordable for most people. I actually set up my own personal website there (which I won’t post just yet as it’s not quite ready yet) using Drupal on Quercus. Look for a wiki post soon and possibly a video tutorial to show how to do this soon.

JavaOne wrapped up last week and I think it was very successful for Caucho. We had a few hundred people drop by the booth to learn about Resin, Quercus, and Hessian. A number of users of all of these technologies dropped by as well to let us know how we’re doing. Thanks to everyone who stopped in!

If you’re using Resin, Quercus, or Hessian in a project, let us know! We’re really interested in how you’re using the products, even if you haven’t purchased a professional license or support. All of our products have an open source component and for a lot of projects, that’s all you need.

I also did a couple of interviews during the show, one for Java Posse, which will hopefully show up in a podcast soon and one with Tony Baer of onStrategies, who blogged about Quercus. Look for Caucho to show up in the news more and more over the coming weeks. We’ve got a lot going on…

I went to MuleCon 2008 and got to meet not only a lot of cool Mule engineers and users, but also Dan Diephouse, the original author of CXF. The Mule people have a really active and energetic community and are now supported by a company called MuleSource, which employs many of the Mule engineers. Among the many topics that came up, one that I took interest in was REST. I asked Dan about the REST support in CXF, which I didn’t know a lot about when I asked. He said that they had an HTTP binding, but recommended going toward JAX-RS.

Coincidentally, one of our customers actually asked the next day about using the HTTP binding with CXF! So I had a look at it and it’s basically right on. It’s annotation based and uses Codehaus’ Java REST annotations (JRA). It’s a small set of method annotations first consisting of GET, PUT, POST, and DELETE to specify which HTTP method will get you to this Java method. Next, there’s a way to map the path and headers to method arguments. That’s it. And that’s pretty much all you need.

Now, I’ve looked at JAX-RS and while I’ll admit that conceptually it’s closer to the original intention of REST, I think it makes things way too complicated. Most of the people using REST do not truly understand the notion of resources and verbs and all that good stuff. They just see the power of passing different parts of a URL to a certain method. When it comes down to the implementation of most normal REST schemes, you end up with a mapping from a URL to a method invocation. That’s what the JRA does in a very simple way.

JAX-RS defines an object tree based on the resources and sub-resources specified by a path. Methods may return sub-resources on which further resource specification is invoked until you get to a terminal method. Did you get that? It’s very nice, academically. However unless you’ve been working with REST for a while and are really a dyed-in-the-wool believer, all that just gets in the way when you’re just trying to map a URL to code. I question the ability to make this fast as well, given the sub-resource concept. Not to mention that the spec itself says it does nothing to create client. I’m a believer that there should be a service interface shared on both the client and server: the server should implement it and the client should get a proxy facade using it. JRA lets you do that and JAX-RS doesn’t.

Anyway, this is probably a futile discussion as JAX-RS is being discussed for inclusion in the next JavaEE standard (!) and a lot of people are thus looking at it as the way to do REST on Java. I hope I’m wrong…