The database consists of one table called ANDROID that's mapped to a Java class called Android. The generated data access object can then be used in our data access provisioning service:

public class ProvisioningDaoImpl extends AbstractDao implements ProvisioningDao {

    public Android findDroid(String id) {
       return (Android) load(Android.class, id);
    }
}

public abstract class AbstractDao {

    public Object load(Class clazz, Serializable id) {
       return this.sessionFactory.getCurrentSession().load(clazz, id);
    }
}

The configuration needed for Hibernate is performed behind the scenes using Spring.

WSDL-First, You Must Do
Vader is getting impatient. He still can't access his TPS reports since there's no external API. We can expose our data access service with a Web Service using a simple framework called XFire. Let's examine the steps to enable simple top-down Web Service creation.

WSDL-first development is the concept of writing the interface for your Web Service before you write the code. WSDL-first development makes sense because it focuses less on a particular programming language and more on the messages between systems. Many people take the approach of generating the WSDL from existing code whether it's an EJB, POJO, or some other programming construct. WSDL-first takes a more top-down approach wherein the schema and WSDL are designed first and code generation happens from there. XML Schema is language-independent and provides more flexibility than a lot of programming languages. Client code, interfaces, implementation code, and schema types can all be generated from a WSDL and schema by a number of SOAP stack frameworks. One of the main benefits of WSDL-first development is improving interoperability between disparate systems programmed in different languages.

Taking our top-down approach let's look at an operation defined on our WSDL:

<wsdl:operation name="findDroid">
    <soap:operation style="document" soapAction="findDroid"/>
    <wsdl:input><soap:body use="literal"/></wsdl:input>
    <wsdl:output><soap:body use="literal"/></wsdl:output>
</wsdl:operation>

The document/literal approach to constructing a Web Service is more straightforward and solves many interoperability issues since it simply relies on XML Schema to describe exactly what the message looks like when delivered. Also, document/literal is WS-I (Web Services Interoperability) compliant. The request and response messages are defined below:

<xs:element name="findDroid" type="provisioning:findDroid"/>
<xs:complexType name="findDroid">
    ...
</xs:complexType>
<xs:element name="findDroidResponse" type="provisioning:findDroidResponse"/>
<xs:complexType name="findDroidResponse">
    ...
</xs:complexType>

By using a combination of XMLBeans (one of the many XML binding mechanisms supported by XFire), XFire, and our WSDL we can use separate tasks in Maven to generate everything needed to build a Web Service. There's an execution step defined in our maven-antrun-plugin in Listing 5.

All of the Web Service code generation is done in the generate-sources phase of the Maven build lifecycle. This lets us generate all of the messaging objects we rely on before our implementation code needs to compile against them. Since all of our messaging objects have been generated we can now implement our provisioning Web Service. XFire creates an implementation class based on the WSDL provided. That same class will be used to implement all of the business logic needed by our system.

The provisioning service is injected with the core service and data access service defined and implemented in earlier modules. The code in Listing 6 shows the provisioning service using the two services it's dependent on to look up android information.

The only thing left to do is wire up our provisioning Web Service. An important thing to note is that the provisioning service is a POJO. We could easily inject it into a different transport protocol implementation. XFire is used in this instance. We define our provisioning service as a service bean in XFire's service factory and are off and running.

<serviceFactory>org.codehaus.xfire.xmlbeans.XmlBeansServiceFactory</serviceFactory>
     <serviceBean>#provisioningServiceImpl</serviceBean>
   </service>

   <bean id="provisioningServiceImpl" class="com.examples.droid.ws.provisioning.ProvisioningServiceImpl">
     <property name="coreService" ref="coreService"/>
     <property name="provisioningDao" ref="provisioningDaoImpl"/>
   </bean>

XFire takes care of the Web servlet, marshaling/unmarshaling of the SOAP messages, and determining which service and which operation needs to be executed. If our requirements dictate that we need a composite service comprised of the provisioning service and some other service we could just create a higher-level module and inject the services that have already been built. The provisioning service would then be just a POJO as opposed to a formal Web Service.

Empire Building
The example demonstrates how Maven can be leveraged to create an entire framework that developers can work in. If the infrastructure is set up properly developers can leverage and reuse many tasks through project inheritance and common plug-ins. Consistency goes a long way in creating large enterprise applications. Adopting a "convention over configuration" approach will let developers build a general framework that will scale to large projects.

The Saga Continues
I encourage you to dive deeper into the Maven application management tool and think about how it can really drive and enable a more modular service-based vision for your architecture. I also encourage you to look into using Maven with the other open source frameworks listed in this article. The build system is truly a reflection of your application's health in terms of maintainability and the ability to bolt on new modules in a timely manner. This article demonstrated at a conceptual level how many different open source frameworks could be glued together to create an extremely flexible layered architecture able to expose modules as services. These services can be reused in other parts of an application by merely injecting them into horizontal or upstream modules.

Acknowledgements
I would like to thank Steve Meyer and Chris Swift for invaluable editing comments and ideas.

References
• Cargo: http://cargo.codehaus.org/
• Dependency Injection: www.martinfowler.com/articles/injection.html
• Hibernate: www.hibernate.org/
• Maven: http://maven.apache.org/
• Spring: www.springframework.org/
• Star Wars: http://en.wikipedia.org/wiki/Star_Wars
• XMLBeans: http://xmlbeans.apache.org/
• XFire: http://xfire.codehaus.org/