Services in SOA need to fit within the 4 tenets of SOA:
- Services are autonomous
- Services have explicit boundaries
- Services share contract & schema, not class or type or databases
- Service interaction is controlled by policy
This means that services should not rely on each other. They should be able to operate alone without any assistance from other services or other outside sources. There should be a clear border around a service defining the business logic, data, classes, types, etc. that belong to it. No other service should have a say or influence over the resources of another service. When services do share something it should only be the schemas and contracts necessary for sending communications. It should never share any of its resources. And services should have a strict policy in place for how each service will physically move communications from one service to another.
Communication is important in Service Oriented architecture
For a service to be autonomous and have explicit boundaries we need to pay really close attention to how they communicate with other services. If the logic or data in one service can influence the resources and/or behavior in another service it will undermine the autonomy and boundaries.
So how do they communicate? Never! Absolutely never ever. We want to strive to have no communication between our services. That being said we will never be able to reach absolute zero communication and nor would we want to. Doing so would diminish the usefulness or our system. So when we do need to communicate it should be in a very controlled fashion and indirectly. The best architectural style that can help us to achieve that is the Bus pattern. In short it provides dumb pipes for sending messages in the form of events. Each service can then make use of pub/sub to subscribe to events from other services. This allows for services to remain autonomous and retain their explicit boundaries by avoiding temporal coupling. But we still have to be extremely careful that we are not using the messages to transfer/duplicate data across services.
We achieve tenets 3 and 4 through messaging. The messages in our system become the contracts and schemas we share between our services and then our physical transport and formatting of those messages becomes our policy.
Autonomy and Boundaries are also important in SOA
Udi Dahan, one of the world’s foremost experts on Service-Oriented Architecture, defines services a little further with this definition:
- A service is the technical authority for a specific business capability
- All data and business rules reside within the service
- Nothing is “left over” after identifying services
- Everything must be in some service
These rules drive home the idea that a service has a boundary and everything inside of the boundary belongs solely to that service. To be autonomous you can’t have outside influences affecting what you control. And to define what you control you need to have a boundary.
On a bit of a side note…. I often come across comments that associate autonomy with being independently deployable. When we think about how to deploy a service it puts us in the wrong frame of mind. Autonomy is more about encapsulation and being self governing. Mr. Dahan tells us that services are artifacts of the logical view. So when we start talking about services being independently deployable we are no longer in the realm of talking about how we logically organize things (see the 4+1 architectural view model for more information).
Services stretch across systems and processes
We need a special IT/Ops Service
I briefly want to touch upon the fact that we will inevitably need a way for our services to do something that may violate one of our tenets. For example we may need to communicate with third parties outside of our control or services in different systems who have a different policy for communication. To avoid coupling our services directly to these outside systems we make use of the IT/Ops Service. This abstracts away any of the coupling or dirty deeds we have to do. The IT/Ops Service can be useful in other situations as well and it is meant to handle all of the odd jobs that don’t fit in exactly with other services that are aligned with business capabilities.
View of SOA
So without further ado lets take a look at a generic view of services in SOA. I have tried to capture the ideas we have discussed as well as included some we have not. Try to keep in mind this is more of a logical view and that it doesnt fully represent how we might deploy the services.
Things that services are not
I don’t want to go to far down the rabbit trail but I thought it would be worth mentioning that Mr. Dahan has a few examples of what services are not and you can learn a little more about them in his talk he gave at the London NDC titled “Finding Service Boundaries – illustrated in healthcare.” Fast forward to about 14:28 to see what they are. In fact I recommend going back and watching the whole video (or at least the first 40 minutes) after reading this blog post to get Mr. Dahans high level on SOA in general.
For more reading on services check out Udi Dahans article, The Known Unknowns of SOA.