Basic Principles of Service Orientation Architecture (SOA)

To build an SOA solution based on Web services, you need to follow the service-orientation principles when pulling the services together into an application. Here are some of the key principles of service-orientation you need to keep in mind when designing SOA solutions:

1. Loose coupling: It represents a relationship that allows the underlying logic of a service to change with minimal or no impact on the other services utilized within the same SOA. Loose coupling is the key principle of service orientation. Implementing services as loosely coupled pieces of software allows you to keep up with the other key principles of service orientation, such as service reusability, service autonomy, and service statelessness.
2. Service contract: It represents service descriptions and other documents describing how a service can be programmatically accessed. In the Binding with WSDL section earlier in this article, you saw an example of a WSDL service description document that describes a service, defining the contract for that service.
3. Abstraction of underlying logic: It means that a service publicly exposes only logic described in the service contract, hiding the implementation details from service consumers.
4. Autonomy: It means that services control only the logic they encapsulate. Dividing application logic into a set of autonomous services allows you to build flexible SOA solutions, achieving loose coupling, reusability, and composability.
5. Reusability: Reusability in service-orientation is achieved by distributing application logic among services so that each service can be potentially used by more than one service requestor. Building reusable services supports the principle of composability.
6. Composability: Composability represents the ability of services to be grouped into composite services that coordinate an exchange of data between services being aggregated. For example, using an orchestration language, such as WS-BPEL, allows you to compose fine-grained services into more coarse-grained ones.
7. Statelessness: It means that services don't maintain their state specific to an activity. Building stateless services encourage loose coupling, reusability, and composability.
8. Interoperability: Interoperability between services is easily achieved as long as the services interact with each other through interfaces that are platform- and implementation-independent.
9. Discoverability: Discoverability refers to standard mechanisms that make it possible for service descriptions describing services to be discovered by service requestors. Universal Description, Discovery, and Integration (UDDI) specification provides such a mechanism, which allows for publishing service descriptions documents in an XML-based registry, thus making them available for public use.

As you can see, most of these principles are tightly related. For example, if you bear the autonomy principle in mind when dividing application logic into services to be utilized within an SOA, you will have reusable, composable, and loosely coupled pieces of software that can be reused in future projects.

On the other hand, ignoring at least one principle of service-orientation makes it very hard to keep up with the others. For example, if you ignore the principle of statelessness when designing services, you will end up with less reusable and less composable building blocks for your SOA solutions.