A good architecture should follow fundamental architectural rules and principles. While general best practices apply to SOA-based system design, SOA also has specific principles due to its unique nature. The characteristics of SOA necessitate special design considerations, alongside basic architectural principles.
Service Contract
A service should implement a standard interface, which acts as a contract between the service provider and consumers. One of the key goals of SOA is reusability across an organization, and another is integration. Since services may have multiple consumers within and beyond the organization, they must adhere to a defined contract. Without a consistent contract, service consumers will not be able to reliably use the service. Thus, conformance to a service contract is a fundamental SOA design principle.
Loose Coupling
Service contracts should be designed to promote loose coupling between the provider and the consumer. Since service providers and consumers may be managed by different entities in various locations, tight coupling can lead to cascading failures whenever an internal change occurs in the service provider. To minimize this risk, services should expose a coarse-grained interface, which improves loose coupling and reduces dependencies.
Abstraction
Another key SOA design principle is abstraction. A service contract should expose only essential information, hiding unnecessary implementation details. This ensures flexibility and reduces dependencies on the underlying logic.
Reusability
A well-designed service should be reusable across multiple applications. This principle is essential to SOA because high reusability leads to better return on investment (ROI). While general architectural principles emphasize loose coupling and cohesion, SOA specifically promotes service reuse. Two key SOA design patterns that support reusability are:
- Logic Centralization – Consolidating business logic to eliminate redundancy.
- Contract Centralization – Standardizing service contracts to maximize reuse.
Applying these patterns results in standardized and normalized services that fully support reusability.
Autonomy
Service autonomy is one of the most debated SOA design principles. There is no universal definition of SOA, and the concept of autonomy has been interpreted in various ways.
Bruce Johnson discusses this in his blog, stating:
"A service has a life outside of the calling application. If the calling application dies while the service is running, the service should continue functioning properly. One of the guarantees of autonomy is the ability for a service to be called asynchronously with no expected return value."
He further argues that a service should be self-healing. While these are valuable design considerations, the term "autonomy" may not be the best choice. A composite service, for example, depends on other services to complete its task, making complete autonomy impractical. Instead, Johnson suggests "sovereign" as a more appropriate term, though this remains debatable.
Some define service autonomy as:
"A service should have a high level of control over its runtime environment."
This definition is vague and potentially misleading. A better approach is to design services with location neutrality, standardized contracts, and loose coupling—principles that already contribute to an independent, reliable service design.
Statelessness
A service should not maintain long-lived relationships between consumers and providers. Each operation invocation should be independent of previous ones. Maintaining state within a service can negatively impact availability and scalability. By designing stateless services, system performance can be significantly improved.
Discoverability
Services should be easily identifiable and understandable to maximize reuse opportunities. A well-designed service should have a clear, well-documented contract that promotes discoverability, regardless of whether an explicit discovery mechanism, such as a service registry, is in place.
Composability
Services should be designed to support composition, allowing them to be combined into larger solutions. SOA's promise of reusability relies on the ability to rapidly build new business capabilities by assembling existing services. Achieving high composability requires careful design to ensure services are modular, loosely coupled, and interoperable.
Comments
Post a Comment