The industry is buzzing with SOA being positioned as the next big thing. As with all new technological fashions SOA promises to delver better, faster, cheaper IT support than was possible before it arrived on the scene. However, all this hype seems to have resulted in a great deal of confusion around just what SOA is, and what it isn’t. Is it a new generation of middleware based on web services and the WS-* family of standards? Is it a new generation of process modelling tools based on BPEL et al? Is it something to do with enterprise architecture? Or is it just another over hyped technology?
For me, SOA is very simple idea: break your solution into a number of discrete services and then organise the services into an end-to-end solution. This might sound very similar to the component based architectures of the late 90s as it is—the main difference being that SOA takes a more coarse-grained view of functionality.
The most contentious point has been defining just what a service is; it’s nearly impossible to get any two “experts” to agree on a single definition. Are they stateful or stateless? Do they support synchronous or asynchronous interfaces? Is WS-* mandatory? What makes them loosely coupled? I think that it’s pointless attempting to create such a detailed definition since it is usually quite easy to find an exception invalidating it. For example, a data service (responsible for CRUD operations to persist a business object) can be considered either stateful or stateless depending on your point of view. The data service appears stateful to clients using it, as it allows them to persist objects and then retrieve them; the service’s state is the objects that are persisted. However, an implementer might create the service with an object-relational mapping tool making the implementation essentially stateless, as it simply passes all data through to an underlying database. Is the service stateful or stateless? It depends. It’s more productive to stick with a rather abstract definition.
I typically use something like the following:
A service is a coherent block of functionality that represents a distinct function or activity within the business.
A service-oriented architecture is then an architecture created by arranging a set of services. Rather than representing our solution as application layers—where each layer covers the full width of the solution—we break the problem into a number of distinct services. Typically these services come on two flavours:
Business Services. Containing implemented business logic (processes and rules).
Technical Services. Supporting technical functionality required to ensure the smooth operation of the overall solution. This might include data services (for persisting business objects), services for authentication or identification, or even services that provide online access to catalogues of other services.
While it’s fairly obvious what technical services are required (typically one for each technical function we need to support) a major challenge in developing an SOA can be deciding on what business services we need to create. The answer is surprisingly simple: create a business service for each business function or activity we need to support.
Since the 80s the business community has expended significant effort developing activity-based models of business (those of us with MBAs should be familiar with Michael Porter‘s work) which break business into a number of discrete activities based on the idea of a value-chain. Rather than reinvent the wheel, us technologists can leverage this work to simplify the creation of our service-oriented architectures, with the added bonus that the resulting architecture will be meaningful for the business.
Once we’ve discovered the business services (creating a business service architecture, as it were) the processes of identifying the required technical services becomes fairly straight forward. A business service that wants to persist business objects needs a technical data service. A business service connected to external partners requires a B2B gateway. Any user represented in a business process will require a user interface. And so on.
This is the approach taken in the OASIS SOA methodology. The methodology is definitely worth a read, as it explains the ideas behind the approach as well as the approach itself. Couple this with the recent work at OASIS on a SOA reference model and we might just have something that we can all live with.