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]

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

  1. ↑ Service Archived May 1, 2012, at the Wayback Machine
  2. 1 2 Hubbers; et al. "Ten Ways to Identify Services". CiteSeerX 10.1.1.94.5879. {{cite journal}}: Cite journal requires |journal= (help)
  3. ↑ Wojciech Cellary, Sergiusz Strykowski.E-Government Based on Cloud Computing and Service-Oriented Architecture.Date Accessed: 11 April 2010.
  4. ↑ Jon Brodkin.SOA failures traced to people, process issues. Date accessed: 8 April 2010. Archived October 13, 2012, at the Wayback Machine
  5. ↑ Gero Vermaas.Top 10 SOA Pitfalls. Date accessed: 8 April 2010. Archived February 23, 2012, at the Wayback Machine
  6. 1 2 Thomas Erl (2008)."SOA Principles of Service Design". Prentice Hall. ISBN 978-0-13-234482-1
  7. ↑ Hoijin Yoon. "A Convergence of Context-Awareness and Service-Orientation in Ubiquitous Computing". CiteSeerX 10.1.1.114.1823. {{cite journal}}: Cite journal requires |journal= (help)
  8. ↑ Michael Poulin Evolution of principles of Service Orientation, part 1.Date accessed: 12 April 2010. Archived February 25, 2012, at the Wayback Machine
  9. ↑ 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.
  10. ↑ 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
  11. ↑ SOA Goals & Benefits Archived October 19, 2012, at the Wayback Machine
  12. ↑ Sadi Melbouci.Methodology to Deliver Service Oriented Architecture.Date Accessed: 10 April 2010. Archived March 5, 2012, at the Wayback Machine
  13. ↑ 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.
  14. ↑ A solution that is based on service-orientation design paradigm and is made up of services.
  15. ↑ Erl et al, (2009)."SOA Design Patterns". Prentice Hall. ISBN 978-0-13-613516-6

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.