Late May we released our Sites application for one of our internal companies, Taylor and Francis. The Sites app is part of a larger project that involves identfifying new book sales opportunities, sending professors inspection copies of requested books and obtaining feedback on what professors intended to do with the books. Professors typically either return the book, buy the book for their own use or (the preferred option) adopt it for their class. The feedback process was originally done via snail mail and could take anywhere from 6-8 weeks to enter the details into

When I saw Marc Benioff's announcement at Dreamforce regarding Sites, I immediately recognized it as the technology that could dramatically cut the feedback time and streamline our manual, paper-based processes. The automated process with Sites would enable the professor to update the same record in that our internal resources would maintain. I pitched Sites to the business and they eagerly adopted it. In the end, we eliminated the manual entry and cut the feedback time to roughly 3 weeks.

Near the end of the Sites project I was working on the Google App Engine for Java Toolkit and was really starting to get into it. We decided that a good test would be to try and port the Site to GAE/J. Not only were we interested in the technology but we wanted to see if it would be a viable competitor. There are pros and cons to each technology and neither one is better than the other; just different. states that the GAE/J is not a competitor to Sites but a complimentary product. The more talk there is about cloud computing in the industry the better for both and Google.

Based upon our development, here are some of my observations on both technologies:

Google App Engine for Java

  • Develop offline - this is a really nice feature that you miss when developing for The ability to be able to work in the car, on the train or in a cave makes GAE/J quite convenient. GAE/J does a nice job of simulating database calls and authentication.
  • Compile locally - waiting for to save my code to the server and compile it can sometimes be a time consuming process.
  • Testng framework - one thing that really irks me is the lack of a testing framework with . It's nice to be able to plug in JUnit to Eclipse for test driven development.
  • Deployment - the deployment to Google is virtually a one-click process and is a little faster and smoother than One of the main reasons is that runs your test cases as your code is being deployed while Google assumes that you have already tested locally and doesn't require testing.
  • Object access - With Sites, locks down access and functionality to some of the standard objects. Since GAE/J utilizes the Partner API you have access to all of the objects based upon your profile. Sites
  • Data model - With Sites I didn't have to create my own data model. It's easy enough to create POJOs and CRUD code with Java but this was a time saver initially and will be down the road for maintenance.
  • Integration - Since we were using Sites natively on the platform, there was no need to write an integration layer for external access. We also didn't need to write any sort of scheduling framework to move data to and from GAE/J for replication.
  • Authentication - Eventhough you can authenticate against Google's infrastructure, utilizing Customer Portal logins seems more straight forward for internal users as contacts are already in According to the Sites product manager, they have made the licensing extremely attractive.
  • Centralized administration - Users seem to prefer having their applications in one centralized location as this minimizes confusion and training.
  • Validation rules - IMHO, this is probably the most attractive feature of Sites. There are a number of Javascript frameworks that can implement form validation in GAE/J but it seems like double the work to me. When you modify your validation rules in you need to remember to make those same changes in your GAE/J app and of course re-test. With Sites, the same validation rules fire for internal users and well as external ones.
In the end we came to the conclusion that Sites was a better fit for this project. However, there are plenty of use cases when we might use GAE/J over Sites. They are both great technologies but a little half-baked. GAE/J was a little more flexible but the integrated approach of Sites made for a shorter development cycle.