The service reusability principle is a design principle, applied within the service-orientation design paradigm, to create services[1] that can be reused across a business.[2] These reusable services are designed so that their solution logic is independent of any particular business process or technology.

Purpose

Service reusability is typically measured by how much extra functionality a service contains that could be reused in future, and how much of the service’s functionality goes beyond the current requirements. This encourages services that contain extra capabilities built around possible future service usage scenarios. However, little is done in designing the service logic in a manner that it could be reused to automate multiple business processes. This results in more focus on equipping services with extra functionality than concentrating on making the core service logic reusable, leading to gold-plated services whose development require increased time and efforts. This additional functionality may not even fall within the original functional context[note 1] of the service and might not even be used at all, as it was built without establishing its needs. The resulting SOA would not be able to provide true service reusability as promised.

Another misconception about service reuse is that the reuse relates to the frequency of its usage. Contrary to this, the actual reuse relates to when the service is used to automate multiple business processes. This is the true service reuse as such a service eliminates the need for creating altogether a new service and becomes a part of multiple business processes without being part of any particular business process.

The service reusability principle addresses these misconceptions by providing a set of guidelines that help to design services containing logic which is not linked to any particular business process and hence could be reused across the enterprise for automating multiple business processes. This further helps in achieving increased ROI.[3]

The compound application of service reusability, service abstraction and service loose coupling principles help developing composable services.[4]

Application

This design principle advocates developing services based on the commercial product design principles that dictate developing a software product with the right type and correct quantity of logic. So the focus here is on the quality of the logic packed within the software program. By concentrating on quality, the reuse potential of the software program is automatically increased. In order to concentrate on the quality of the logic, the service reusability requires exploring the business domain as well as the current technologies in use. Some of the considerations that help in designing services with reusable logic include:

  • What are the long term objectives of the organization?
  • Analysing the functional contexts of the current services.
  • Current legacy systems and any future plans of decommissioning such legacy systems.
  • What are the current requirements that the service is required to address?
  • Details about the corresponding business domain(s).

By conducting this analysis, we can arrive at the right type of reusable logic that needs to be included within the service. Also because the other services are analyzed as well, the chances of logic duplication are minimised. It is beneficial for the application of this principle to have a service inventory blueprint[5] (a set of candidate services) as then the identification of agnostic logic [note 2] becomes rather easier. This requires performing [6] via the Service-oriented analysis and design process. The application of this principle before the finalisation of service capabilities provides an opportunity for fine tuning and refactoring the logic in support of making it reusable. This also gives a chance to equip the services with additional capabilities that could be reused by other business processes, apart from the one that is currently being automated, when it comes to automating such processes.

An important concept related to the application of this principle is logic centralization. With the passage of time, as different service delivery projects are undertaken, the chances of services containing duplicate logic increases. This can only be avoided if there exists an enterprise wide standard that dictates analyzing the current services when it comes to appending services with new reusable logic. If a service already exists with a functional context that fits the new reusable logic, then instead of creating a new service such a logic should become part of the existing service. This not only helps in avoiding duplication but also increases the reusability level of the service as now the reusable logic sits within the correct context and hence stands a better chance of reuse. This is exactly what is advocated by the logic centralization pattern.

Considerations

The application of this design principle requires performing a top-down service-oriented analysis process[7] in order to arrive at a complete set of candidate services. This clearly requires increased resources both in the form of time and efforts. The application of the Logic Centralisation design pattern may introduce cultural issues e.g. service developers showing reluctance in reusing other’s services, project managers not willing to incorporate use of existing services as it might need solution design adaptation, etc.

By emphasizing service reuse, the reliability of the reusable services becomes an important issue as multiple service consumers depend on the same service. Other design principles like service autonomy principle and service statelessness principle provide guidance in order to deal with reliability and availability related issues.

Notes

  1. ↑ The type of the functionality that a service encloses e.g. an Invoice service will have a functional context that deals with invoice related processing but will not deal with processing Purchase Orders
  2. ↑ Logic that is not linked to a single business process i.e. independent of any particular context and hence can be used to automate multiple business processes.

References

  1. ↑ Services
  2. ↑ Thomas Erl, Herbjörn Wilhelmsen SOA Pattern of the Week (#4): Service Normalization[Online]. Date accessed: 14 April 2010.
  3. ↑ Hariharan.Common mistake while adopting SOA[Online]. Date accessed: 14 April 2010.
  4. ↑ Kjell-Sverre Jerijærvi.SOA Contract Maturity Model[Online]. Date accessed: 14 April 2010.
  5. ↑ Service Inventory Blueprint Archived 2010-05-11 at the Wayback Machine
  6. ↑ Service Modeling
  7. ↑ Top-down service-oriented analysis process Archived 2010-05-09 at the Wayback Machine

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.