 | This article's tone or style may not reflect the encyclopedic tone used on Wikipedia.(February 2010) |
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.
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]
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:
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.
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.
In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.
SOA Governance is a set of processes used for activities related to exercising control over services in a service-oriented architecture (SOA). One viewpoint, from IBM and others, is that SOA governance is an extension (subset) of IT governance which itself is an extension of corporate governance. The implicit assumption in this view is that services created using SOA are just one more type of IT asset in need of governance, with the corollary that SOA governance does not apply to IT assets that are "not SOA". A contrasting viewpoint, expressed by blogger Dave Oliver and others, is that service orientation provides a broad organising principle for all aspects of IT in an organisation — including IT governance. Hence SOA governance is nothing but IT governance informed by SOA principles.
Event-driven SOA is a form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings. Before event-driven SOA, the typical SOA platform orchestrated services centrally, through pre-defined business processes, assuming that what should have already been triggered is defined in a business process. This older approach does not account for events that occur across, or outside of, specific business processes. Thus complex events, in which a pattern of activities—both non-scheduled and scheduled—should trigger a set of services is not accounted for in traditional SOA 1.0 architecture.
Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures (SOA).
In the domain of the service-orientation design paradigm, the Enterprise Inventory is a design pattern by Thomas Erl that answers the question, "How can services be delivered to maximize recomposition?"; the application of this pattern results in a standardized enterprise-wide service inventory that fosters repeated service composition.
Within the service-orientation design paradigm, Service Refactoring is a design pattern, which is applied to an existing service so that either the service logic or its implementation can be changed without affecting the service consumers.
The standardized service contract is a software design principle applied within the service-orientation design paradigm to guarantee that service contracts within a service inventory adhere to the same set of design standards. This facilitates standardized service contracts across the service inventory.
Service abstraction is a design principle that is applied within the service-orientation design paradigm so that the information published in a service contract is limited to what is required to effectively utilize the service The service contract should not contain any superfluous information that is not required for its invocation. Also that the information should be limited to the serviced contract only, no other document or medium should be made available to the service consumers other than the service contract that contains additional service related information.
Service autonomy is a design principle that is applied within the service-orientation design paradigm, to provide services with improved independence from their execution environments. This results in greater reliability, since services can operate with less dependence on resources over which there is little or no control.
Service statelessness is a design principle that is applied within the service-orientation design paradigm, in order to design scalable services by separating them from their state data whenever possible. This results in reduction of the resources consumed by a service as the actual state data management is delegated to an external component or to an architectural extension. By reducing resource consumption, the service can handle more requests in a reliable manner.
Discoverability is the degree to which something, especially a piece of content or information, can be found in a search of a file, database, or other information system. Discoverability is a concern in library and information science, many aspects of digital media, software and web development, and in marketing, since products and services cannot be used if people cannot find it or do not understand what it can be used for.
In computing, service composability is a design principle, applied within the service-orientation design paradigm, that encourages the design of services that can be reused in multiple solutions that are themselves made up of composed services. The ability to recompose the service is ideally independent of the size and complexity of the service composition.
Domain Inventory is a design pattern, applied within the service-orientation design paradigm, whose application enables creating pools of services, which correspond to different segments of the enterprise, instead of creating a single enterprise-wide pool of services. This design pattern is usually applied when it is not possible to create a single inventory of services for whole of the enterprise by following the same design standards across the different segments of the enterprise. The Domain Inventory Design pattern by Thomas Erl asks, "How can services be delivered to maximize recomposition when enterprise-wide standardization is not possible?" and is discussed as part of this podcast.
Service normalization is a design pattern, applied within the service-orientation design paradigm, whose application ensures that services that are part of the same service inventory do not contain any redundant functionality. This design pattern emphasizes on creating normalized services, much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.
Logic Centralization is a design pattern, applied within the service-orientation design paradigm, whose application aims to increase the reusability potential of agnostic logic by ensuring that services do not contain redundant agnostic logic and that any reusable logic should only be represented by a service that has the most suitable functional context.
Service layer is an architectural pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.
In software engineering, Canonical Schema is a design pattern, applied within the service-orientation design paradigm, which aims to reduce the need for performing data model transformation when services exchange messages that reference the same data model.
Entity abstraction is a design pattern, applied within the service-orientation design paradigm which provides guidelines for designing reusable services whose functional contexts are based on business entities.
In the context of software engineering and software architecture, service granularity is a key design concern when applying the paradigm of service-orientation for instance during service-oriented modeling. Service granularity specifies the scope of business functionality and the structure of the message payload in a service operation that is provided within a service-oriented architecture (SOA).
Business-oriented architecture is an enterprise architecture approach for designing and implementing strategically aligned business models.