In Udi’s 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 which works well with my preferred definition of SOA:

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

“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 .

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.

With almost territorial delineation between services, how do we build applications? Udi notes in this blog post that applications are simply mashups of autonomous services. Applications are loosely communicating context aware services. The job of applications is to provide context to services.

Udi did not cover why he chose the phrase “business capability” instead of the more familiar “business process”. My guess is since business capabilities describe what a business can do, they are at the right level of granularity; Capabilities are like the menu in a restaurant. They describe what cuisines we might enjoy. A business process, on the other hand, defines the how. 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.