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. [1] This results in greater reliability, since services can operate with less dependence on resources over which there is little or no control.
The service-orientation design paradigm emphasizes service reuse as dictated by the service reusability design principle. Under this paradigm of a heavily reused services, reliability becomes critical to ensure service longevity. In turn, service reliability depends on the service's operational control of service logic and underlying implementation resources to reduce dependence on external resources over which it has little or no control such as shared service logic or a shared database, which may not be available when required by the service.
Traditional component-based software development also faces the same autonomy requirements, the provisioning of autonomy and reliability, in such circumstances, is left to the actual run-time environment e.g. by providing fail-over support or by deploying a solution on dedicated servers. However, within service-orientation, the stakes are even higher as a service-oriented solution can be composed of services [2] that exist outside of the organizational boundary. So in this case, it's the design of the service itself that matters and the service needs to be designed in a way that it exercises maximum control over how it fulfills its functionality. The service autonomy principle attempts to provide guidelines for designing autonomous services so that the resulting services are more predictable and reliable.
The application of service autonomy involves two types of autonomy that allow an increase the overall autonomy of the service, design time autonomy and run time autonomy.
Design-time autonomy refers to the independence with which the services could be evolved without impacting their service consumers. This type of autonomy is required as the service's underlying legacy resources might need an overhaul or the service's logic might need refactoring in order to make it more efficient.
The application of the service loose coupling and the service abstraction principles helps in attaining design-time autonomy as their application results in services whose contracts are shielded from their logic and implementation and hence, the services could be redesigned without affecting their service consumers.
Run-time autonomy refers to the extent of the control that a service has over the way its solution logic [3] is processed by the run-time environment. The more control a service has over its run-time environment, the more predictable is its behavior. Run-time autonomy is achieved by providing dedicated processing resources to the service. For example, if the service logic performs memory intensive tasks then the service could be deployed to a server with reserved or conserved resources. Similarly, by providing locally cached copies of data, where applicable, the service's dependency on a remote shared database can be reduced. As a result, the overall autonomy of the service is increased...
There is a direct relationship between run-time autonomy and the design-time autonomy. Increasing the design-time autonomy automatically increases the ability to evolve service's implementation environment.
Although increasing service autonomy to the maximum extent is always desirable, it is not always possible to design each and every service with maximum design-time and run-time autonomy. As a result, the services need to be prioritized so that their autonomy could be addressed according to their value for business. This could be done by having a look at the functional context of the service. Services whose functional contexts are independent of any particular business process, e.g. entity [4] and utility [5] services, are good candidates for increasing their autonomy. This is because they offer functionality that is of interest to different types of consumers. On the other hand, business process specific services, e.g. task [6] and orchestrated task services, are less reusable and are dependent upon the individual autonomy of their composed services.
The provisioning of service autonomy may require additional infrastructure and needs to be applied on a per-need, prioritized basis. On some occasions, services may need to be isolated and deployed in a customized and dedicated environment, with emphasis on designing the correct functional context since making fundamental changes to such a service is likely to be difficult.
The autonomy of services that encapsulate legacy resources may be hard to predict and increase. This may require additional analysis on part of utility services, as the level of autonomy depends upon the functionality provided by the service.
Procedural programming is a programming paradigm, derived from imperative programming, based on the concept of the procedure call. Procedures simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program's execution, including by other procedures or itself. The first major procedural programming languages appeared circa 1957–1964, including Fortran, ALGOL, COBOL, PL/I and BASIC. Pascal and C were published circa 1970–1972.
Autonomic computing (AC) is distributed computing resources with self-managing characteristics, adapting to unpredictable changes while hiding intrinsic complexity to operators and users. Initiated by IBM in 2001, this initiative ultimately aimed to develop computer systems capable of self-management, to overcome the rapidly growing complexity of computing systems management, and to reduce the barrier that complexity poses to further growth.
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.
Representational state transfer (REST) is a software architectural style that describes a uniform interface between physically separate components, often across the Internet in a client-server architecture. REST defines four interface constraints:
In software engineering, inversion of control (IoC) is a design pattern in which custom-written portions of a computer program receive the flow of control from a generic framework. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code.
A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.
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.
The service reusability principle is a design principle, applied within the service-orientation design paradigm, to create services that can be reused across a business. These reusable services are designed so that their solution logic is independent of any particular business process or technology.
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.
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.
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.
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code. The data is in the form of fields, and the code is in the form of procedures.