Last time we looked at events, notable changes in state, that can be used to notify other systems who may be interested in the event.  We ended with some pseudo code showing examples of how it might look and finally with some thoughts on coupling, which is where we slide into part two.

What is an autonomous service?  Firstly, let’s define autonomous – via Bing:

- self-governing: politically independent and self-governing
- able to choose: able to make decisions and act on them as a free and independent moral agent
- self-sufficient: existing, reacting, or developing as an independent, self-regulating organism

When we talk about autonomous services, what we mean are services that are self-governing, self-sufficient, and able to choose.  Autonomous services are the gate-keepers to systems of record and exist on their own.  Back to our pizza example we could feasibly have a kitchen service that exists on it’s own, independent of any specific order service.  To put it Vegas style, “What happens in the Kitchen Management Service, stays in the Kitchen Management Service” (except when it’s an event we want people to know about…more on that later).

Autonomous services will be focused to a particular set of related tasks such as our Kitchen Management Service which monitors orders in being cooked and stock levels of products.  I lean towards looking at a service through a single responsibility lens.  The more focused you keep that service, the cleaner the abstraction remains and the easier it will be to integrate in an environment of collaborating services.

Autonomous services are self-contained and therefore internal implementations can change as needed.  By keeping services focused and isolated we can reduce the coupling between other collaborating services or systems.  The only thing an autonomous service must do is fulfill it’s contract.  The contract is the definition of the abstraction the service is representing.  Typically this is a WSDL in the web service world along with the accompanying schemas.  But what we’re talking about here aren’t request-response services, so how does the contract apply in an event driven world?

This question opens the door to what we will explore in Part 3 of Service Oriented, Event Driven: Collaborating Services.  Stay tuned!