Service-Oriented Architecture (SOA) is a widely used - and misused - phrase in IT, having evolved to have different meanings to different people.

For some it is no more than a re-branding of an architectural approach used for decades on large scale enterprise applications. Examples include CORBA Services in the 1990s, RMI from Java 1.1 onwards and DCOM.

For others, SOA is a new nirvana; a place where where corporate services are exposed via Web Services to be discovered and consumed by a multitude of clients (using any technology), the end-result being rich and productive new systems built from standard building blocks. To quote Wikipedia :

"SOAs build applications out of software services. Services are relatively large, intrinsically unassociated units of functionality, which have no calls to each other embedded in them."

Whatever the merits of the two camps, when designing and building large corporate systems there is no doubt that this design practice is a good thing. Without it, systems would not scale, applications would constantly be re-inventing the same wheel, and things would very quickly devolve into a maintenance nightmare.

What has changed with SOA in recent times is the technology - much of which is now freely available. In the past, a decision on SOA typically involved hundreds of thousands of licensing dollars. This is no longer necessarily the case. Furthermore, solutions are now quicker and easier to assemble, with systems increasingly being built upon standard well-known building blocks. Examples of this include HTTP-based protocols and standard application containers like Tomcat.

In parallel to the rise of affordable SOAs, new web-based technologies have matured to provide a new path for building feature rich Web 2.0 Ajax-styled user interfaces. Coming from an open source and Java background, two in particular have been on our radar, namely Ruby on Rails (RoR) and the Google Web Toolkit (GWT). They both have radically different approaches to solving the issue of Web 2.0 development.

While RoR delivers a complete end-to-end solution from the database to the user interface (and also happens to use a relatively new language), GWT is purely a web-tier solution where all development is done in Java. This point of difference - that GWT can leverage existing Java-based services and is only concerned as a web tier solution - makes it ideally placed to be used in a mature corporate IT environment.

This article will show how to build a SOA-based system using Spring Services, a GWT client to talk to those services, and Maven 2 as a build tool to hold it altogether. There is also an associated reference project, created here at Shine Technologies and now open-sourced on Google Code using the Apache 2 License. Full project details, including fully downloadable source (including Eclipse projects) are available at http://shine-reference.googlecode.com.

This project can be used to easily navigate and run the following examples, and could potentially be used as a basis for quickly getting your own project up-and-running. What's more, the project will be maintained and updated as feedback and enhancements arrive both from teams within Shine and the IT community at large.

This article will start by covering the setup of a build environment using Maven. Then we'll start working through each of the layers in sequence, beginning with getting up-and-running with a compatible Spring Service layer. Next we'll add a bridge between GWT and the Spring Services. Finally, we'll introduce a GWT client that can attach to the bridging layer and thus communicate with the Spring services.