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 completely 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 in a database across services is disallowed; This impedes on the technical authority of the 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 as discussed in this blog post requires services to communicate asynchronously. If services make synchronous calls we have created strong temporal coupling between our services.
A more surprising takeaway of being a technical authority is that services must own their presentation elements. This means our applications will decouple orthogonally instead of horizontally as services will bundles data, schema, business rules and presentation elements together.
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 didn’t cover why he chose the specific language of business capability instead of the more familiar business process. Business capabilities describe what a business does – the functions that a business performs (use cases at a high level). Processes, on the other hand, define how a business operates and are anchored in today’s thinking about the business. For example, a business capability might be “Generate Bill”. The specifics of how a bill is generated – whether we create a PDF or generate an email, is the process.
Sounds great, but if we don’t create code that actually does Print PDFs or send emails, nothing gets implemented. So why capabilities? Because they maps well to services. A capability is at the right level of granularity to be represented with a service. Capabilities are black boxes that encapsulate the processes they perform. Services are the same, sharing minimally and to observers (if constructed correctly) autonomous black boxes of functionality. 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 all of this SOA machinery work.