Creating a new web-service should be a reasonably simple operation.

During the rebuild of our Bizrate and Shopzilla websites we found that we built a lot of similar web services:  Simple read access to enriched data sourced from other web services and databases with XML payloads.  Each service would also support a variety of common endpoints for health checks, configuration information and include a standard set of MBeans for operational monitoring.

We invested in a Maven Archetype to create a template for developing a new service.

From a Configuration Management perspective all our services have a consistent approach to builds, configuration and deployment.  From an Engineering perspective we have consistent project structures, technology choices and best practices.  For example, connection pooling strategies and libraries, layout of maven projects including separation of concerns between Maven modules, publishing project documentation via Continuous Integration, environment agnostic archives, and code coverage checks.

An example of a command to generate a new service from an archetype:

mvn archetype:generate -DarchetypeGroupId=com.shopzilla.archetypes \
-DarchetypeArtifactId=shopzilla-modular-hibernate \
-DarchetypeVersion=2.0-SNAPSHOT \
-DgroupId= \
-DartifactId= \
-Dversion= \
-Dservice-version= \
-Dshortened-service-name= \
-Duser= \
-DcurrentYear=


This produces the source code for a ready-for-Git, ready-for-Hudson, web-service, with 90% code coverage checks with all the standard endpoints, MBeans plus an example endpoint that integrates with a database via Hibernate.

We continually contribute features back to the archetype to ensure that new services will keep pace with any new technology decision.

At the moment our Maven Archetype makes use of Apache Velocity in order to apply naming decisions, such as Java packages and the web-service name, to the generated code base. We’re keeping a close eye on Spring Roo in order to understand how our Archetype can continue to evolve and improve.

Having homogeneous projects also helps further our goal of enterprise Collective Code Ownership.  Its very easy to checkout and build any service and be instantly familiar with how its engineered.

Shopzilla had a great time at Velocity 2009.  It was our second year attending but our first time sponsoring and presenting.

Steve Souders wrote a great synopsis of why it’s important for companies to focus on performance.

Check out Phil Dixon’s presentation of “You Get What You Measure“:

One thing we’ve learned is that maintaining a high performing web site is a continuous effort; you can’t take your eye off the ball.  We’re working on improving our automation of real-world full page load measurement so that we can prove to our business stakeholders that our site continues to deliver a fast experience to all our end users.