Download directly for more content description... Spring[2] is a rather large application framework. Here we are . Java, Spring, Mule and Maven make this ap- proach easy. • Don't forget to test deployed . This paper introduces an implementation recipe, summarised in section 5.1. We are implementing a SOA system; this is the paper we wish we had read before we started. Our approach is minimal and incremental. At its core is the service's business logic, implemented in plain Java (POJOs), with an associated interface. Some services depend on others. This is inevitable. Rather than obscure this dependency, we make it explicit; dependency is expressed through a direct call to the sub–service's business interface. This allows easy verification of the system, via both compilation and integration tests. With careful design and choice of technology we can then add further functionality without influencing the core. This paper focuses particularly on messaging, but we believe that the approach is general; that one should start with the simplest system necessary, understand it, and then incrementally extend it. We use Maven v2 to manage the build process. Its rigid approach makes it easy to track dependencies between packages. We suggest using a flat logical structure, with all packages being children on a single top–level parent. Each package is then configured separately, the parent is used only to set a few global parameters and allow whole–project compilation, testing, etc. This does not mean that the packages themselves need to be in a flat directory structure. Instead, we suggest grouping by service. So the parent directory contains a sub–directory for each project; each of those contains further directories for each package (interface, implementation, communication, deploy,etc). A further child of the parent directory contains all the libraries, etc.