Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures.
Overview
The success of software development based on any particular design paradigm is never assured. Software developed under the service-oriented design paradigm carries even greater risks. This is because a service-oriented architecture usually spans multiple business areas and requires considerable initial analysis. Therefore, SOA developed without concrete guidelines is very likely to fail. To ensure that the move towards service-orientation is a positive change that delivers on its promised benefits, it is helpful to adopt a set of rules. The service-orientation design principles may be broadly categorized as follows, following Thomas Erl's, SOA Principles of Service Design:
It is the application of these design principles that create technology independent services and hence provide interoperability in the long term. These design principles serve as a guideline for identifying services.
Strategic goals
The application of these principles helps in attaining the underlying goals linked with the adoption of service-orientation in the first place. These goals are strategic in nature i.e. long term and look beyond the immediate needs of an organization. These strategic objectives could be summarized into the following seven goals & benefits:
Each of the above goals and benefits directly helps towards developing an agile organization that can quickly respond to the ever-changing market conditions with reduced efforts and time.
Characteristics
The service-orientation design principles help in distinguishing a service-oriented solution from a traditional object-oriented solution by promoting distinct design characteristics. The presence of these characteristics in a service-oriented solution greatly improves the chances of realizing the aforementioned goals and benefits. Erl has identified four service-orientation characteristics as follows:
Vendor-neutral
Business-driven
Enterprise-centric
Composition-centric
A vendor-neutral service-oriented solution helps to evolve the underlying technology architecture in response to ever changing business requirements. By not being dependent on a particular vendor, any aging infrastructure could be replaced by more efficient technologies without the need for redesigning the whole solution from scratch. This also helps in creating a heterogeneous technology environment where particular business automation requirements are fulfilled by specific technologies. Within a SOA, the development of solution logic is driven by the needs of the business and is designed in a manner that focuses on the long-term requirements of the business. As a result, the technology architecture is more aligned with the business needs. Unlike traditional silo-based application development, a SOA takes into account the requirements of either the whole of the enterprise or at least some considerable part of it. As a result, the developed services are interoperable and reusable across the different segments of the enterprise. A service-oriented solution enables to deal with new and changing requirements, within a reduced amount of time, by making use of existing services. The services are designed in a manner so that they can be recomposed i.e. become a part of different solutions.
Application
The service-orientation design principles are applied during the service-oriented analysis and design process. The extent to which each of these principles could be applied is always relative and needs to be weighed against the overall goals and objectives of an organization as well as the time constraints. One important factor that needs to be kept in mind is that it is not just the application of these design principles alone but the consistent application that guarantees the realization of the service-orientation design goals linked with the adoption of service-orientation. This is because services are an enterprise resource, i.e. giving the confidence that they conform to certain standards and could be reused within multiple solutions, so in order to remain such a resource, they must emerge from a process to which these principles have been applied consistently, as an inconsistent application would result in services that are not compatible with each other, resulting in loss of the fundamental service-orientation design characteristics.