Home‎ > ‎Architecture‎ > ‎SOA & MDM‎ > ‎

SOA design principles

posted Mar 31, 2013, 8:10 AM by Jageshwar Tripathi   [ updated Apr 1, 2013, 5:27 AM ]
There are some basic architectural rules and principles which should be applied to a good architecture. All those rules , principles and best practices are also applicable to SOA based system design but there are best practices and principles which are specific to SOA because of specific nature of SOA. SOA systems have some specific features due to which design considerations should be special for SOA including basic design principles applied to any architecture.

Service Contract
Service should implement an standard interface. This interface is a contract with service consumers. One of the goal of SOA is re-usability across organization and another goal is integration. In this scenario there will be various consumers of the service across and beyond organization. If service will not adhere to a contract, service consumers will not be able to use service. One of the most important design principle of SOA is conformance to service contract.

Loose coupling
Service contracts should be designed in such a way that they should promote loose coupling between provider system and consumer system. Since consumer and provider of service may be located at various places under control of different entities tight coupling will have ripples effects which can not be handled easily in case of any internal change in service provider. As a good design principle services should have coarse grained interface to improve loose coupling.

Another good SOA design principle is abstraction. A service contract should only have limited and essential information.

A service should be reusable on its own. Here this SOA design principle is considered due to commitment of SOA to promote re-uase. In general architecture rules or principles you might not have seen specific focus on reuse. General architecture design principles advocate about loose coupling, cohesion etc but they talk less about re-usability. SOA promises high ROI so reusability has special focus in good SOA design principles. There are two SOA design patterns help here - logic centralization and contract centralization. applying these two SOA design patterns results in to standardized and normalized service which fully support and maximizes re-usability.

This is one of the most controversial claimed tenets of SOA. As there was no unanimous definition of SOA and SOA world this SOA design principle (Autonomy) also has several meanings and understandings. I have serious objections and I will start a debate on it later but for the benefit of readers I will not make it an issues at this place and would like to summarize few things
Bruce Johnson in his blog has discussed this controversial issue. He writes "A service, on the other hand, has a life outside of the calling application. If the calling application dies while the service is doing its think, the service will continue functioning properly. In fact, one of the guarantees of autonomy (in this sense) is the ability for a service to be called asynchronously with no expected return value. He further says "a service, where possible, should be self-healing". I support Bruce Johnson's views that it should not be called Autonomy. Autonomy is a wrong word chosen for expected behavior of a service mentioned by Don Box with respect to Autonomy. Autonomy means independence but what about scenario where a service will use other services to complete its task. A composite service. People have written that with loosely coupled, they are location neutral, services communicate through dynamically negotiated channels etc etc that is why services can be considered autonomous. I didn't understand why decoupling, standard contracts etc which are other design principles are used to establish this design principle (autonomy).
Yes services should be designed keeping these things in mind (location neutrality, they should not know how other is working, they should have standard interface but how does it make a service autonomous? In practice no service can be autonomous. As Bruce has written "My own personal choice would be 'sovereign'". I still don't want to call it sovereign.
Some explain service autonomy as "Service should have high level of control over its run-time environment.". This is funny? :)

There should not be long-lived relationships between consumer and provider of service. Any operation invocation should not rely implicitly on a previous invocation. Making service state full will have negative impact on availability and scalability of the services.

Services should be easily identified and understood when opportunities for reuse are present. The service design should focus on “communications quality” of the service and its individual capabilities, regardless of whether a discovery mechanism for an example service registry is there or not.

Services should be capable of participating as effective composition members. Re-usability promise of SOA requires that new capabilities, business requirements can be fulfilled with no time by composing a new application using existing services. Good design effort is required to make sure it should promote composability.