What's a Service

In service oriented architecture, services should align with and enforce enterprise semantics and rules instead of tangentially relate to them like applications do.

This brings me to Udi’s definition of a service.

A service is the technical authority over a specific business capability. Any piece of data or rule must be owned by only one service. – Udi Dahan

In this definition, Technical authority is intentionally strong. To be an authority means to have power of determination.

An authoritative service owns its data, its schema, and its concept of consistency. No outside force may tell a service what is true inside its boundary. For example, enforcing referential consistency across services is disallowed. This impedes on the technical authority of a service over its data.

A service also owns its business rules. To own a rule, a service must be able to change its interpretation of a rule without “issuing a memo”. Other services shouldn’t be affected by this change. This is stronger than loosely coupled – this is autonomous.

To be autonomous requires services to communicate asynchronously. We create strong temporal coupling between our services if services make synchronous calls.

A more surprising takeaway of being a technical authority: Services must own their presentation elements. This means our applications will decouple orthogonally instead of horizontally. Services must unite data, schema, business rules and presentation elements into a coherent whole.

Providing presentation elements isn’t the same as a full blown stylized UI; A separate branding service is responsible for that. Instead, services emit a small amount of HTML or JSON or own an MVC controller. This is controversial as horizontally decoupling has been beaten into our skull for so many years. But it makes sense if services have been constructed at the right level of granularity and with the right boundaries.

But with almost territorial delineation between services, what is an application? An applications is simply a mashup of loosely coupled, context aware autonomous services. The job of an application is to provide context to a set of services.

But whe does this definition use the phrase business capability instead of the more familiar business process. My guess is since business capabilities imply a level of granularity; Capabilities are like a menu in a restaurant. They describe what cuisines we might enjoy. A business process, on the other hand, defines the how. As a service consumer, I don’t need to know how the eggs are cooked so long as my omelet is timely and tasty.

Another reason to prefer capabilities over processes is that capabilities are stable over time. For our investment in services to be valuable, they too must be stable over time. The implementation can change as the environment and organizations changes, but services boundaries need not be redefined, just as the core business capabilities rarely need be redefined.

Now that we have a good idea of what we want out of our services, we can start talking about the moving parts that make this SOA machinery work.