Service-orientation design principles
Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures (SOA).[1][2][3]
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.[4] 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.[5]
The service-orientation design principles may be broadly categorized as follows, following Thomas Erl's, SOA Principles of Service Design:[6][7][8]
- Standardized service contract
- Service loose coupling
- Service abstraction
- Service reusability
- Service autonomy
- Service statelessness
- Service discoverability
- Service composability
It is the application of these design principles that create technology independent services and hence provide interoperability in the long term.[9] These design principles serve as a guideline for identifying services.[2]
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[10] of an organization. These strategic objectives could be summarized into the following seven goals & benefits:[11][12]
- Increased intrinsic interoperability
- Increased federation
- Increased vendor diversification options
- Increased business and technology alignment
- Increased ROI
- Increased organizational agility
- Reduced IT burden
Each of the above goals and benefits directly helps towards developing an agile organization[13] 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[14] 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:[15]
- 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 [6] 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.
See also
References
- ↑ Service
- ↑ 2.0 2.1 Hubbers. Ten Ways to Identify Services.
- ↑ Wojciech Cellary, Sergiusz Strykowski.E-Government Based on Cloud Computing and Service-Oriented Architecture.Date Accessed: 11 April 2010.
- ↑ Jon Brodkin.SOA failures traced to people, process issues. Date accessed: 8 April 2010.
- ↑ Gero Vermaas.Top 10 SOA Pitfalls. Date accessed: 8 April 2010.
- ↑ 6.0 6.1 Thomas Erl (2008)."SOA Principles of Service Design". Prentice Hall. ISBN:978-0-13-234482-1
- ↑ Hoijin Yoon. A Convergence of Context-Awareness and Service-Orientation in Ubiquitous Computing.
- ↑ Michael Poulin Evolution of principles of Service Orientation, part 1.Date accessed: 12 April 2010.
- ↑ David Webber.Services as Web Services: "Are We There Yet?"How Web Service Technology Stacks Alone Cannot Fulfill the Goals of SOA.Date Accessed: 11 April 2010.
- ↑ The immediate needs are those that are linked with automating a particular business process e.g. invoice processing while long-term requirements are those that look beyond the current requirements and are usually spread across multiple business processes
- ↑ SOA Goals & Benefits
- ↑ Sadi Melbouci.Methodology to Deliver Service Oriented Architecture.Date Accessed: 10 April 2010.
- ↑ An agile organization within the context of IT world is one that can quickly respond to its business requirements while using much of its existing resources.
- ↑ A solution that is based on service-orientation design paradigm and is made up of services.
- ↑ Erl et al, (2009)."SOA Design Patterns". Prentice Hall. ISBN:978-0-13-613516-6
Further reading
- Mauro. et al. Service Oriented Device Integration - An Analysis of SOA Design Patterns. [Online], pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 8 April 2010.
- Dennis Wisnosky.Principles and Patterns at the U.S. Department of Defense[Online].Date Accessed: 10 April 2010.
- Ash Parikh.Service-Orientation is the New Mantra![Online].Date Accessed: 10 April 2010.
- Ertan Deniz.XML and XML Web Services[Online].Date Accessed: 10 April 2010.
- Nafise Fareghzadeh. Service Identification Approach to SOA Development[Online].Date Accessed: 10 April 2010.
- William Murray.Implications of SOA onBusiness Strategy and Organizational Design[Online].Date Accessed: 10 April 2010.
- Diaconita. et al.Two Integration Flavors in Public Institutions[Online].Date Accessed: 11 April 2010.
- Fabian Meier.Service Oriented Architecture Maturity Models:A guide to SOA Adoption?[Online].Date Accessed: 11 April 2010.
- Moosavi. et al. A Method for Service Oriented Design[Online].Date Accessed: 11 April 2010.
- Kjell-Sverre Jerijærvi.SOA Contract Maturity Model[Online].Date accessed: 12 April 2010.
- IBM Red Books.Power Systems and SOA Synergy[Online].Date accessed: 21 April 2010.
 |  |
