Raible Designs

The LinkedIn Journey Continues

As you might know, I've spent the last several months working for one of the coolest clients ever: LinkedIn. They hired me back in July 2007 and I was impressed on day one. I was originally hired to help them evaluate open source Java web frameworks and try to determine if moving from their proprietary one to an open source one would help improve developer productivity.

After looking at all the options, I recommended we look at Struts 2 and Spring MVC - primarily because they seemed to be the best frameworks for a LinkedIn-type of application. Another Engineer and I prototyped with Struts 2 for about 6 weeks and came up with a prototype that worked quite well. While our mission was successful, we found a couple issues with Struts 2 and standard JSP that might actually hurt developer productivity more than it helped.

Following this project, I worked on the New Homepage Team, which is now visible to everyone that logs onto LinkedIn. My role was minimal, but it was still a very fun project to work on. You know those widgets in the right panel? I did the initial UI and backend integration for those. All the business logic, Ajax/JavaScript, CSS, and optimization was done by other folks on the team. Shortly after this project went live in November, I started prototyping again with Spring MVC + JSP.

The reason I was asked to prototype with Spring MVC was because they were using Spring on the backend, Spring MVC in a couple other projects, and a new project was being kicked off that used Grails. Rather than add another framework (Struts 2) to the mix, they wanted to see if they could suppress any further framework proliferation.

After a month of prototyping with Spring MVC + JSP, my results weren't as good as Struts 2. With Struts 2, I was able to use OGNL to do all the things their current JSP implementation allows them to do (call methods with arguments, use statics in EL, etc.). With standard JSP, a lot of this wasn't possible. If it was - it required writing lots of tag libraries and made it more cumbersome for developers to do certain things. At the end of that project, I determined that using FreeMarker might solve these problems. I also determined that neither Struts 2 nor Spring MVC would solve the ultimate problem of developer productivity. Neither framework would allow developers to go from make-a-change-and-deploy, wait-3-minutes-to-see-change-in-browser to make-a-change, save and wait-15-seconds-to-see-change-in-browser.

I recommended that this be the ultimate goal - to get rid of the deployment cycle and to allow minimal turnaround when deploying modified classes. After that problem was solved, it's true that moving to an open source web framework would likely provide an easier-to-remember API. However, the problem with moving to a new web framework would be that everything used to construct the existing site would suddenly become legacy code.

In the end, we concluded that the best solution might be to enhance the existing framework to be more like the available open source options. This would allow existing applications to keep using their code -- and if we enhance properly -- new applications can use a simpler, less verbose API and a templating framework that's easier to understand. We can make LinkedIn's version of JSP more like standard JSP while allowing its powerful EL to remain. We can add support for JSP Tag Libraries and Tag Files.

One of the benefits of moving to an open source web framework is there's a community, documentation and books that describe the best (or most common) ways to solve problems with the framework. LinkedIn has this, but it's all in code and no one seems to have a high-level of confidence that the way that they did it is the "best" way. Developers communicate well, but all the knowledge is stuck in their heads and inboxes - there's no way for new developers to search this knowledge and figure it out on their own without asking somebody.

By adopting an open source web framework, it's possible to solve part of this problem, but I think it's still going to exist - where a few engineers know how to use the framework really well (for the specific application) and the rest don't. We determined that regardless of open source vs. proprietary framework, what was needed was a set of developers that acted as authorities on how to develop web applications at LinkedIn. A UI Frameworks Team if you will. This would be their only job and they would never get pulled from this to work on projects or complete tasks related to LinkedIn's products. Some developers mentioned that they'd been asking for this for years, and some folks had even been hired for this. However, the formulation of this group has never happened and it's obvious (now more than ever) that it'd be awesome to have them.

The UI Frameworks Team
At the end of 6 months, it seemed my work was done at LinkedIn. I liked the idea of a UI Frameworks Team and recommended they start it with the authors of the existing web framework. They agreed this was a good idea. A few days later, I was pulled into the CTO's office and he offered me the job. He offered me the challenge of building this team and told me I could do it remotely (from Denver) and hire my own people to help me with it. I gulped as I realized I'd just been offered the opportunity of a lifetime. I knew that while this might not be the best option for LinkedIn, it certainly was an excellent opportunity for me. I said I'd think about it.

In the meantime, I was given a project which you might've read about. They asked me to migrate a Rails application to Grails and try to determine if they really needed both frameworks. I spent 2 weeks coming up to speed on both and flew to Mountain View to deliver my conclusion. Here's an excerpt from an internal blog post I wrote.

The application that I was asked to port from Rails to Grails? The one that was launched last week - LinkedIn Mobile.

After doing this research, I stepped up to the plate and accepted the offer to start a UI Frameworks Team and recruited some kick-ass Java Developers I know to be the founding members. Last week, I flew out to Mountain View to do some kickoff meetings and start getting the infrastructure in place so we can document, support and release code like a well-oiled open source project. There's nothing saying we won't use an open source web framework as the underlying engine, but I think this should be an excellent chance to see the power of open source governance and development style in a corporate environment.

Director of Engineering, Core Experience
I should mention one last thing. If you're an experienced Java Developer/Architect with a passion and deep knowledge of UI development (JavaScript, CSS, HTML), we've got a Director of Engineering, Core Experience position with your name on it. I might even get to interview you if you apply for this job. Furthermore, whoever gets hired will likely work very closely with my team. What's not to like about that!?

All Java web frameworks should support hot deploy of a single class

In Anyone else using Groovy?, Tim Fennell (inventor of Stripes) raves at how much he likes Groovy now that it supports Java 5 features. He writes that Groovy might offer a solution to make development with Stripes faster:

The other thing I've been wondering about is that if there were enough demand for it we could try adding "improved" groovy support. E.g. throw your groovy actions under WEB-INF and we'll use groovy's built in stuff to do auto-reloading etc.

Gregg Bolinger responds with an excellent idea:

It would be really cool if Stripes could automatically discover and load changes to action beans (including new ones) without the entire app restarting, regardless of what the action bean is written in. But I realize that is a pretty tall order. :)

I agree that it might be a tall order, but I don't think it's impossible. In fact, I think all Java-based web frameworks should support hot deploy of a single class. We shouldn't have to buy JavaRebel to do this. It should be mandatory.

When an application reaches a certain size, the startup time can get pretty lengthy. This is lost development time. Furthermore, if any part of the development cycle takes longer than 15 seconds, there's a good chance developers will do something else (check their e-mail, move onto another task, etc.). Multi-tasking may be a good skill to have, but it's a horrible way to be productive.

Of the frameworks I'm familiar with, only Tapestry 5 and Seam support reloading single classes without restarting the whole application. Why can't the other frameworks "borrow" Tapestry 5's code? Maybe someone should just buy ZeroTurnaround and give away JavaRebel for free.

If I had one wish for 2008, it would be for all Java web frameworks to support this feature. Pretty Please?

Migrating a Rails app to Grails

There's an interesting trend I've seen happening at companies over the last year. More and more, they're experimenting with Rails and/or Grails for both prototyping and real applications. I think this is an excellent use for these frameworks as they both are very productive. The reasons for their productivity is simple: zero turnaround and less code.

For a Java-based company that's built their bread and butter applications on Java and been successful with it, both frameworks can be disruptive. Bread and butter applications tend to be large and somewhat difficult to maintain. In my experience, the biggest maintenance headache is not writing code or fixing bugs, it's the turnaround time required to make changes, run tests and build the application to test in your browser. Since Rails and Grails eliminate the turnaround, it's only natural for developers at companies with a lengthy build process to love their increased productivity.

Over the next couple weeks, I'm going to do some experimenting with porting a Rails application to Grails. Why? Because I think companies are going to have a difficult time choosing between these two frameworks for rapid prototyping and (possible) production deployments. While both frameworks are great for prototyping, the last thing most developers want to do is throw away the prototype and develop it with something else. They want to continue to enhance the prototype and eventually put it into production. With Rails and Grails (and many others), it's possible to build the real application in a matter of weeks, so why shouldn't it be put into production?

For most Java-based companies, putting a Rails application into production is unfamiliar territory. However, a Grails application is just a WAR, so they can continue to use all the Java infrastructure they know and love. So for companies with an established, tuned and successful JVM infrastructure, does it really make sense to use Rails over Grails? The only thing I can think of is language reasons - there's a lot of Ruby fanatics out there.

So again, the purpose of my experiment is simple: to see if a Grails app can do everything a Rails app can. As for language features and scalability, I'm not really concerned with that right now. I'm not looking to prove that either framework should be used for all web applications - just certain types.

Has anyone out there ported a Rails application to Grails? If so, are there any gotchas I should watch out for?

NOTE: I realize that Rails can be deployed on the JVM with JRuby. However, I think many companies have existing Java-based tools (logging, JMX, Spring backends, etc.) that more easily integrate with Grails than Rails. I could be wrong.

A Positive Wicket Experience

Julian Sinai recently released the first version of his company's product based on Wicket. In A Year of Wicket, he describes the experience (emphasis mine).

I've been working with Wicket for almost a year. We've just released our first product that uses Wicket for the user interface, and so it seems like a good time to take stock. Unfortunately, it's not a public site, it's an installable enterprise product, so I can't show it to you. If you don't want to read further, here's the executive summary: Wicket rocks!

I was hired as the GUI Architect for this project. I came to it with many years of GUI experience, mostly using Swing, but without a lot of web development experience.

Because of my Java and Swing background, I was drawn to Wicket. It maps fairly closely to the Swing model of development. So does GWT, but when I evaluated it, it seemed so different from other J2EE frameworks that I felt it was a step too far. No HTML, and no WAR files, for example. This made my colleagues nervous, who were used to Struts and PHP. Me too, as a matter of fact.

I had done some pretty serious prototyping for another project with Tapestry, and there were certain things I liked, like runtime bytecode generation. But the learning curve was pretty steep. At one point I needed to create a custom component, and to do so I needed to learn about engine services and other arcane things that I felt made the process too hard. By contrast, custom components are Wicket's bread and butter, and they are very easy to build.

I also took a close look at JSF. It seemed overly complex to me, and not much of a departure from the Struts era. It came across as a technology designed by committee, with the combination of several complementary libraries required to get the job done, and there are still too many configuration files.

So we decided to use Wicket.

...

One of Wicket's advantages is the strict separation of design from behavior, that is, HTML from code. While we did not have a web designer on the team who built the HTML (the developers did this), and therefore didn't get any mileage from the separation in that sense, we definitely gained from having all the behavior in Java code, because it gave us all the power of refactoring, compile-time error checking, and maximum reusability. [Read More]

I really like how Julian talks about reasons they didn't choose other frameworks. Beyond that, I think it's important to note that Wicket was a perfect fit for someone with heavy Java and Swing experience. I still think Wicket is a little verbose for Web developers that program in Java (me), but it's unlikely there's very many of those. Building a form in Java seems so much more cumbersome than building it with HTML - but that's probably just me.

REST and Seam Talks at Denver's JUG

After a long hiatus, I decided to attend the Denver JUG meeting this evening. Tonight there's a couple of interesting talks:

• Give It a REST by Brian Sletten
• Seam by Norman Richards

I'll do my best to live-blog these sessions, so hopefully you can read along and learn everything I do.

Give It a REST by Brian Sletten
This talk isn't an implementation talk, it's more of a motivational talk. Brian is trying to answer the question "Why do we care?". We care because we have a lot of WS-Dissatisfaction. "Conventional" Web Services are often:

• too difficult for non-trivial tasks (real complexity)
• too complex for trivial tasks (artificial complexity)

RPC-based Web Services are mythically interoperable and time/process coupled in painful ways. SOAP has largely become popular because of marketing dollars behind in. REST is more like the "hippy" way that has grass-roots support with no corporate sponsor.

What makes SOAP difficult? It's remote procedure calls and its tunneled using existing application protocols (HTTP). Furthermore, there are no nouns (mappings to business terms), only handlers. There are no semantics, only handlers. When you tie yourself to a contract/WSDL, you can have anything back that you want - so as long as its simple XML. This isn't entirely true because a lot of things can be shoved into XML (Word documents that are Base64 encoded).

The main problem with SOAP is it solves a problem that most people don't have. It solves an edge case, rather than the main problem.

Many people say "SOAP is secure and REST isn't".

Why do people believe this? It's because of the long list of SOAP-related security acronyms: XML Encryption, XML Signature, XKMS, SAML, XACML, WS-Security, WS-Trust, XrML. Even if you're using these in your system, there's no proof that your implementation is secure. REST is what we all use on the web with online shopping, etc. We don't seem to have a problem with the security we use everyday on the web, do we?

SAO is an architectural style promoting loose coupling among software participants. Sompanies have rigid definitions of what constitutes a SOA. Many believe that SOAP is an essential piece, but it's not. SOAP 1.2 and Doc Lit are improvements, but are they necessary? Interestingly, 85% of Amazon's users chose REST over SOAP when given the choice.

What is REST? The acronym stands for REpresentational State Transfer. It's an architectural style based on certain constraints designed to elicit properties of scalability and extensibility. It's an idealized notion of how the early web should work and helped drive the way it eventually did work. It's more than just URLs!

Resource-Oriented Computing focuses on information spaces, not code or objects. It focuses on logical connections and reduces complexity by separating actions from nouns. In the history of the web, we started with URLs that pointed to documents. Eventually, these documents became dynamic and were generated on-the-fly.

URLs are locations on the web that are horrible names because they change so much. URIs are good names that have no way of being resolved. Fundamentally, REST is a separation of the parts of the system: Nouns, Verbs and Representation. A Resource (in a REST architecture) can be a file, a service or a concept. It can also have different representations. Resources are named with Resource Identifiers. It's simply the means of naming a resource. It's a standard syntax that allows various schemes. Often known as URIs (or IRIs). It's orthogonal to satisfying the reference and it's one of the missing pieces of "normal" web services.

Examples of Representation include 1) a particular dereferencing of a Resource Identifier to a Resource at a particular time, 2) a byte-stream tagged with metadata or 3) it could change based on request or processing/display capabilities of the client (Firefox vs. WAP).

REST's verbs are design decisions to minimize the the complexity of implementing a system. GET retrieves a resource and always returns the exact same result. It doesn't change anything in the backend system. Because of this, it allows for easier layering of your system - particularly when you introduce caching for GETs. POST is used to create (or update) a Resource. It does not require a "known URI" and it supports the append operation. PUT creates (or updates) a Resource, but requires a "known URI" and also supports an overwrite operation. Lastly, there is DELETE, which removes a Resource. This is not supported in modern browsers. Just because browsers don't support them doesn't mean you can't implement them in your applications.

REST's concepts were developed by Roy Fielding in his thesis. He was trying to create a system that had the following architectural properties: performance, scalability, generality, simplicity and modifiability. REST allows us to create true client-server applications. To satisfy scalability requirements, REST is stateless. All parameters travel with the request and no session information is maintained on the server. This improves scalability through load-balancing and allows visibility of intermediary processors.

One of the first things that becomes a bottleneck in enterprise systems is the database. This works fine if you like paying Oracle. By using REST and HTTP concepts, it's easy to take advantage of a cache. This allows replication of an external data set where it's too large to copy locally. REST allows you to create Layered Systems that allow you to have managed dependencies between layers. Having a RESTful architecture allows you to swap out the backend without changing the front-end and vise-versa.

Now Brian is going to do some demos using NetKernel. He recommends using HTML documents to describe services. The beauty of developing a RESTful system is there's nothing preventing you from appending ?wsdl to your URLs to return SOAP.

Invoking functionality using web-friendly techniques is a very nice way to build web applications.

What is controversial in REST? When you are not dereferencing you should not look at the contents of the URI string to gain other information.. However, if you structure your URLs in your application in a hierarchical manner, people will be able to use URIs in this way.

What isn't controversial? No one believes you should rely on sessions or other state at the application level. They also believe using nouns, not verbs is an excellent idea.

Seam by Norman Richards
Seam isn't just a web framework, it's an integration technology for building applications for the web. It's a technology that takes your persistence and web technologies and unifies them so you have a simpler view of your system.

First of all, what is Seam?

• It's a unified component and event model - you access all your components the same way
• It has a declarative state with a rich context model
• It provides deep integration with minimal glue code
• It minimizes configuration, prefers annotations to XML
• It allows a freedom of architectures and technologies
• It also allows testing of components in context

With Seam, you have a number of technology choices to make. The first is which business component model you want to use (EJB 3 vs. POJO). You might choose EJB 3 if you want more clustering capabilities. For persistence, you can use Hibernate or any JPA implementation. Norman recommends using JPA if possible. You also have a choice of languages: Java or Groovy (and possibly Scala in the future). Seam gives you a choice of web frameworks. All the examples today will use JSF, but there's also support for GWT and 2.1 will have support for Wicket. Also, there's some non-committers developing support for Flex. Norman believes component-based web frameworks are the best way to develop web applications. While I hear this from a lot of folks component-based framework authors, it seems ironic that the "best" way to develop webapps is not the most popular way (PHP, Struts, Rails).

I think it's ironic that there's a REST (no state) and a Seam (it's all about state) talk in the same night. I'm tempted to ask why a stateful architecture is better than a REST one, but I'm not really that interested in the answer. I think your architecture should be determined by the needs of your application, rather than choosing the architecture and then implementing an application with it.

In addition to choices, Seam gives you a number of tools: CRUD generation, Eclipse and NetBeans support and full IDE support in JBoss Tools / JBoss Developer Studio.

Now Norman is doing a demo - starting by creating a new Seam Web Project in Eclipse. He mentions that he's skipped a number of steps: downloading and installing Seam, downloading and installing JBoss and configuring your Seam installation and database in Eclipse. He has two projects in Eclipse - apparently the New Project wizard creates two - one for the application and one for testing. It's strange that the tests don't go in the actual project. The directory structure has src/action and src/model for your Seam components. After doing some simple CRUD, Norman starts JBoss and looks at the master/detail screens it generates.

To make a Java class a Seam component, you usually only have to add a @Name annotation to the class. While trying to show us how the Authenticator/login works, Norman tried to open components.xml. Unfortunately, this crashed Eclipse and 30 seconds later - following a bevy of "file does not exist" errors, we're back in action. To inject dependencies in a Seam environment, you use the @In annotation. In the example class, here's what the code looks like:

try {
  currentUser = (Person) entityManager.createQuery("select p from Person p where" + 
       " p.email = #{identity.username} and p.password=#{identity.password}").getSingleResult();
} catch (NoSuchEntityException e) {
  currentUser = null;
}

This example appears to encourage title coupling with the data layer, rather than loose coupling (i.e. a DAO layer). I'm sure Seam doesn't prevent you from developing a more loosely coupled application.

Bug Alert: The <h:messages> tag looks like it always has an <li> - even when there's only one message. Struts 2 has the same issue with its <s:errors> tag. It's disappointing that so many Java framework developers don't have more attention to HTML details.

Probably the coolest part of Norman's demo is how Eclipse auto-synchronizes with JBoss so he never has to start/stop anything when he changes Facelets pages or Java classes. Of course, hot deploy should be possible with any web application if you're using Eclipse Web Tools effectively.

I do believe all-in-one starter frameworks like Seam, Rails, Grails and AppFuse are excellent. However, I also believe they're solving a problem that only 10% of companies have. Most companies don't have the ability to start applications from scratch - unless they're a startup. Most companies have an existing infrastructure in place for the backend and they simply need a better web framework to slap a pretty face on it. I don't know the best solution for this, but it seems like a logical choice to RESTify the backend (possibly with a web framework) and then use a modern web framework for the front-end. IMHO, the best web frameworks for a RESTified backend are Flex, GWT and Appcelerator. If nothing else, these appear to be the most hyped for 2008.

Many of the enhancements that Seam has added to the Java web programming model are being pushed back into the Web Beans JSR. With Seam, injection is bi-directional (input and output), is continuous during application invocation and dis-injected after action is done. The whole purpose of this is to let Seam handle the state of your application. By not worrying about storing/maintaining state, you as a developer can concentrate on business logic more and get your applications done faster.

At this point, Norman started talking about Seam's events and how you can use them. Unfortunately, my battery ran out and I drifted off to do some other stuff. I'm sure Seam's Event Model is pretty cool, I just missed it.

Spring MVC, JstlView and exposeContextBeansAsAttributes

Did you know that Spring MVC's JstlView has a exposeContextBeansAsAttributes property you can use to expose all your Spring beans to JSTL? I didn't. To configure it, you configure your viewResolver as follows:

<bean id="viewResolver" 
    class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
    <property name="exposeContextBeansAsAttributes" value="true"/>
    <property name="prefix" value="/"/>
    <property name="suffix" value=".jsp"/>
</bean>

After doing this, any Spring bean can get referenced in JSTL with:

${beanId.getterMethodWithoutTheGetPrefix}

If you're using Spring 2.5a annotations and <context:component-scan>, you'll need to specify a "value" attribute on your annotations in order to reference them in JSTL. For example:

@Controller(value = "beanId")
@RequestMapping("/foo.html")
public class MyController extends SimpleFormController

...

@Component(value="testClass")
public class TestClass {

Pretty cool stuff. It'd be a lot more useful if you could call methods with parameters. Hopefully JUEL will solve that problem. JSTL's functions work, but I'd rather write ${foo.method('arg')} rather than ${taglib:callMethod(foo, 'method', 'arg')}.

Go Light with Apache Struts 2 and REST by Don Brown

After attending Dan's talk on REST, I stayed in the same room and listened to Don Brown talk about Struts 2's support for building RESTful applications. Below are my notes from the event.

What is wrong with today's web applications? You're using a modern web framework and you've cleanly separated your presentation and business logic. The biggest problem in modern web applications is Confusing URLs.

A URL should be a resource indicator - not a method invocation. Often, web applications have little or no caching. People use GET to perform data manipulation and POST may or may not change state (especially with JSF). Another big issue with modern web frameworks is there's too many abstraction layers that hide HTTP headers and it's difficult to manipulate them.

Today's applications are "information silos". There's a lot of information in your applications, but it's all buried in HTML, JavaScript and CSS. There's no way to get this information out of your application unless you explicitly expose it.

The answer to many of these problem is REST. It's the Way of the Web. To solve the information silo problem, you can create a single interface that has multiple representation of the same resource. There's one URI for all types of resources - be it XML, JSON or HTML. How does this work w/o modifying the URL? You modify the URL's extension.

Struts 2 has a couple of plugins that make developing RESTful services easier. The first is the Codebehind plugin and the 2nd is the REST plugin. Don is doing a demo with the REST plugin and shows that there's no Struts configuration files needed (no struts.xml and no struts.properties). The only thing that's necessary is to specify an "actionPackages" init-param on the DispatcherFilter in web.xml. This activates the Codebehind plugin that uses conventions to determine the view template's path.

In Don's demo, he's creating an "OrdersController" that implements ModelDriven. After implementing a setId() method (to set the id from the request parameters), a getModel() method (to return the Order object) and implementing a show() method that returns HttpHeaders, Don starts up his server and shows that http://localhost:8080/order/5 returns an HTML page. Changing the URL to end in /5.json returns JSON, /5.xml returns XML.

public HttpHeaders create() {
    service.save(order);
    return new DefaultHttpHeaders("success").setLocationId(order.getId());
}

The Poster Plugin for Firefox is great when you're working with REST services. Don used this plugin to show us that it's possible to post to JSON and get back JSON results. His demo was impressive, especially the fact that there was no XML configuration required for Struts. I also like how the DefaultHttpHeaders class allows you to manipulate headers in a type-safe manner.

To use the REST plugin, you'll want to use Struts 2.1. If you're using Maven, all you need to depend on is struts-rest-plugin. The struts-codebehind-plugin (as well as struts-core) will be pulled in by transitive dependencies.

One disadvantage of REST vs. WS-* is you can't generate client code from a WSDL. You'll have to write your client by hand. However, one advantage of REST is there's already lots of clients - your browser, curl, etc.

The Struts REST Plugin hasn't been officially released, but hopefully will be in Struts 2.1.1. You can checkout the code from SVN using the URL below. The documentation is located here.

http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/rest

Great talk Don - and excellent work on the REST plugin for Struts. I can't wait to try it out.

Choosing a JVM Web Framework: Stories Wanted

My last post on choosing a web framework got quite a few comments. Some seemed to like the application categorization technique as a means to narrow the choices. However, others seemed to disagree. So if application categorization is not a good methodology for narrowing the choices, what is?

I think one of the best ways to figure out a good methodology is to find out what people have done to choose their web framework. I'm looking for stories from developers who have evaluated 2-3+ frameworks for a project. I'd like to come up with 3-5 stories as part of my talk to highlight how some teams have chosen their web framework. What were your important criteria? What made you choose the one you did? Was it a tight race between a few of them? Did industry buzz or application categorization play a part in your decision?

Please send any stories you'd like to share to [email protected]. Of course, you can also post your story in the comments - but an e-mail gives it a bit more validity. If you'd like to share your company name, that'd be great, but it's by no means required. I haven't decided if I'm going to prevent all cases as anonymous companies or not. If you do send a story, I'll make sure and ask your permission before I share any of your personal/company information. Thanks!

Choosing a JVM Web Framework

I plan on rewriting my "Comparing Java Web Frameworks" presentation for this year's Colorado Software Summit. Rather than "Comparing Java Web Frameworks", I'm going to make it into more of a "Choosing a JVM Web Framework" presentation. I think this opens it up to more possibilities such as Grails, JRuby on Rails, Flex and GWT.

One of the things I hope to talk about is choosing the right tool for the job. I think there's 3 types of web applications you can develop:

1. Consumer-facing, high-traffic, stateless applications
2. Internal, more desktop-like applications that are stateful
3. Media-rich applications that require a RIA framework like Flex

Once you've decided on which of these you're developing, it's much easier to narrow down the choices:

1. Struts 2, Spring MVC, Stripes
2. JSF, Tapestry, Wicket
3. GWT, Flex, OpenLaszlo

I'm not sure if GWT fits in the RIA category. I'm not sure where Rails or Grails fit either. They more closely resemble category #1 than any other, yet there's a lot of speculation about their scalability. I think if that perception can be changed, they'll fit into the first category quite well. However, I don't think they compete with component-based or RIA because they don't hold state or offer rich-media capabilities.

Sidenote: I find the scalability debate quite interesting. There's a fair amount of propaganda in Javaland that scalability can be achieved with appservers and clustering tools like Terracotta. If this is true, I've yet to read good solid proof of it. Most of the "how to scale" information out there suggests "share nothing" architectures that shard data and applications across several servers. Of course, there's scalability and then there's massive scalability. Can appservers and clustering solve massive scalability like Google and Amazon require?

The 2nd and 3rd categories have someone of a blurry line, so I'm hoping to figure out how to clarify that. There's also a lot of other factors that will go into choosing a web framework. What if you're simply trying to replace a home-grown framework with an open-source one? If you want to keep your backend and all its logic, does it make sense to use something like Seam, Grails, JRuby on Rails or even AppFuse? Probably not - all their wizbang features and CRUD generation doesn't mean much if all you're using is the web framework. Also, if your application requires support for non-JavaScript browsers (for 508 compliance), then GWT and JSF can be easily eliminated. I know that there are many claims that JSF doesn't require JavaScript, but I've yet to see a real-world application developed with JSF that expects JavaScript to be turned off. Progressive enhancement is a requirement by many of my clients these days.

What's your opinion? How can we make it easier for developers and companies to choose a web framework? Is categorizing application types a good technique?

OSCON 2007: Comparing Java Web Frameworks

This afternoon I delivered my Comparing Java Web Frameworks talk at OSCON in Portland. I told attendees I'd post it here afterwards, so here it is:Download Comparing Java Web Frameworks Presentation (5.1 MB)

For comments on this presentation from earlier this year, see related postings from ApacheCon EU and JA-SIG. This presentation is pretty much the same as the one from ApacheCon and JA-SIG, except it has a different theme and I chopped out the Sweetspots section (due to time constraints).

Portland is great this time of year, but unfortunately I won't be sticking around. I'm heading down to Salem to work remotely for a couple of days, returning for the Oregon Brewers Festival on Friday and heading back to Denver on Saturday. I'll be glad when July is over - I've traveled to a new state every week.