 | This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these template messages)
|
Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures (SOA). [1] [2] [3]
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]
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]
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.
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]
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.
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.
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.
Enterprise architecture (EA) is a business function concerned with the structures and behaviours of a business, especially business roles and processes that create and use business data. The international definition according to the Federation of Enterprise Architecture Professional Organizations is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."
Service-orientation is a design paradigm for computer software in the form of services. The principles of service-oriented design stress the separation of concerns in the software. Applying service-orientation results in units of software partitioned into discrete, autonomous, and network-accessible units, each designed to solve an individual concern. These units qualify as services.
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.
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.
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 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.
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.
Canonical Protocol is a design pattern, applied within the service-orientation design paradigm, which attempts to make services, within a service inventory, interoperable with each other by standardizing the communication protocols used by the services. This eliminates the need for bridging communication protocols when services use different communication protocols.
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.
Thomas Erl is a Canadian author, and public speaker known for major contributions to the field of service-oriented architecture. Author of eight books on Service Orientation, Erl defined eight widely accepted principles of service orientation.
Business-oriented architecture is an enterprise architecture approach for designing and implementing strategically aligned business models.
The Banking Industry Architecture Network e.V. (BIAN) is an independent, member owned, not-for-profit association to establish and promote a common architectural framework for enabling banking interoperability. It was established in 2008.
{{cite journal}}: Cite journal requires |journal= (help){{cite journal}}: Cite journal requires |journal= (help)