Nigel Bakker's SOA Soapbox

There is a growing trend amongst the developers I work with to take a “service oriented” view of what they are doing. They frequently refer to their efforts as being SOA development. I find this quite disturbing, since they are not actually engaged in SOA.

SOA, like many terms and acronyms in the world of software and computing is heavily overloaded. I thought I’d offer a few perspectives on SOA in an attempt to clarify the differences.

Let’s start by expanding the term SOA as Service Oriented Architecture. It could also be expanded as Service Oriented Applications, but I find this overload to be confusing. For the purposes of this discussion, SOA refers to Service Oriented Architecture.

Scope

First off, there is the question of scope. SOA is intended as an Enterprise Architecture approach. By definition this means that it recognises the existence of all applications and business domains. It is primarily concerned with enabling business processes across these applications and / or domains.

When using service orientation as an approach to application design, an approach I prefer to call Service Oriented Application Design (SOAD), we are generally confining ourselves to a single application, and by implication, the single business domain for which the application is intended. Obviously, some applications do cross business domain boundaries, but the fact remains that the focus is very much at the application scope.

When we apply SOA design principles at an application scope we tend to make tradeoffs that favour the application scope more than the enterprise scope. In his seminal work, SOA: Principles of Service Design, Thomas Erl classifies services in models. These models map (loosely) to layers and form a natural hierarchy. The names he uses are Task Services, Entity Services and Utility Services. Task services encapsulate business process logic. Sometimes these services cut across business domains and applications. This type of task service is often implemented using some form of orchestration technology (such as BEPL). These orchestrated task services, a.k.a. parent business process services or parent task services span application domains, and are squarely in our sights from a SOA perspective.

Service Orientation as an application design approach

If our focus is at the application level and we are applying SOA design principles, then surely we are “doing” SOA? The problem I have with this is that when using the term SOA in this context we are dragging in a bunch of enterprise architecture concepts that may not be appropriate.

Service Orientation at the application level is not new (Inversion of Control frameworks such as Spring tend to be service oriented), only today there are other, more powerful technologies (such as WCF) that make service oriented application development much simpler and more mainstream.

But is this SOA? In my view not directly – purely because the scope is at the level of the application. It does however make it much easier for a business to leverage the functionality of an application when we implement business processes that include its domain. SOAD is a means to service enable new applications from the ground up. This tends to make them first class citizens in a SOA, as opposed to typical legacy applications that may require significant effort to service enable.

Service Orientation as a business process enablement approach

In an enterprise where you have service enabled applications, it becomes common practice to begin leveraging those applications in more complex, cross domain business processes. Several things drive this, including replacing point-to-point integration, eliminating manual recapture of data and of course, supporting new or improved business processes.

At this level we are clearly in the domain of inter-application (or inter-domain) business processes, being processes that cut across more than one area of the business. This is also the domain of EA and therefore of SOA.

When working at this level, we would typically be using business process modelling to define our processes, followed by implementation of the automated sections of the process via some form of orchestration such as BPEL. This tends to result in composite services which use BPEL to implement some or all of their service logic.

Interestingly, these cross domain services tend to be less time sensitive than services within a particular application domain. In order to promote service loose coupling, these services are often implemented as business event sinks, consuming these events as subscribers, and publishing events in their own right where required.

Synchronicity

One of the observations I have made is that the lower down the hierarchy of services one goes, the more likely it is that the service is consumed in a synchronous fashion. Business task services are often not that time sensitive, since typically they involve some form of processing in response to a business event.

For example, if a customer calls into your call centre to update their address, the most likely situation is that the CRM system will be used to capture the changes. The actual process of updating the details is confined within the domain of the CRM application. Once the update is complete, this becomes a business event which other domains may care about. The billing system for example, probably cares about contact details, since it needs to be sure that the bills are sent to the right place. For this to happen, the billing application needs to be told about the change. Does this need to happen while the client is on the phone with our call centre agent? Probably not. We could simply publish the event, and let all interested applications consume and process the event at their leisure.

Within the CRM application itself, things are a little different. Assuming we have implemented CRM using a service oriented design, there would likely be an entity service responsible for managing customer data. When the agent hits the “ok” button on the screen, it’s important that he or she gets feedback immediately confirming that the update has in fact been applied. This update would need to be immediate, and clearly synchronous calls are better suited to this level of usage.

This asynchronous / synchronous differentiation has a profound effect on our overall application design, and is therefore one of the factors that influences the way in which we apply service orientation at the level of the application.

Service Oriented Application Design definitely supports and contributes to a Service Oriented Architecture, but purely on the basis of a too narrow scope, is not itself SOA. This being the case, let’s use the term SOA where it actually applies and call what we do at the application level by a different name… say SOAD?