Service Reusability Principle
   HOME

TheInfoList



OR:

The service reusability principle is a design principle, applied within the
service-orientation Service-orientation is a design paradigm for computer software in the form of Service (Systems Architecture), services. The principles of service-oriented design stress the separation of concerns in the software. Applying service-orientation resul ...
design paradigm, to create servicesServices
/ref> that can be reused across a business. Thomas Erl, Herbjörn Wilhelmse
SOA Pattern of the Week (#4): Service Normalization
Online]. Date accessed: 14 April 2010.
These reusable services are designed so that their solution logic is independent of any particular
business process A business process, business method, or business function is a collection of related, structured activities or tasks performed by people or equipment in which a specific sequence produces a service or product (that serves a particular business g ...
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 Gold plating is a method of depositing a thin layer of gold onto the surface of another metal, most often copper or silver (to make silver-gilt), by a chemical or electrochemical (electroplating) process. Plating refers to modern coating met ...
services whose development require increased time and efforts. This additional functionality may not even fall within the original functional contextThe 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 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.Harihara
Common mistake while adopting SOA
Online]. Date accessed: 14 April 2010.
The compound application of service reusability, service abstraction and service loose coupling principles help developing composable services.Kjell-Sverre Jerijærv
SOA Contract Maturity Model
Online]. Date accessed: 14 April 2010.


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 blueprintService Modeling
/ref> via the service-oriented modeling, 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