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.
Comments (2)
Comment RSS | Trackback URI
Have you guys considered open sourcing your archetypes or are they too specific to your environment?
-paddy
It’s a great question. Our archetypes boil down to a couple of things;
Consolidation of deployment concerns – separating binaries from configuration, VIP health checks, a human readable configuration information page (for when the application is deployed), exposure of SCM version information. This is all boilerplate, and allows engineers to focus on the business problem at hand.
Code structure and layout – making code from different teams look and feel the same, meaning engineers are free to explore much of our entire Shopzilla domain easily.
Performance monitoring – using Jamon and JMX, our archetype configures the required dependencies and spring wiring such that performance annotated methods are exposed. We measure at the 95th percentile, though we’re considering moving to the 99th.
To answer your question, there’s probably a few separate things here we could opensource, likely starting with the performance monitoring piece, and following up with the archetype itself.
In thinking back, we probably “kick started” our archetype in about a week. Given a need to create a new web-service, we took our most recent web-service, and consolidated the above bullets into an archetype. We didn’t manage to incorporate absolutely everything we needed the first time. We’ve found continual improvement and curation of our archetypes to be vitally important.
Cheers,
Rod.
Related Posts (5)
Leave a Comment