The standardized service contract is a software design principle [1] applied within the service-orientation design paradigm to guarantee that service contracts [2] within a service inventory [3] (enterprise or domain) adhere to the same set of design standards. [4] This facilitates standardized service contracts across the service inventory. [5]
The agility promised by a service-oriented architecture (SOA) is usually measured in terms of the reusability level of its contained services. However, this reusability relates directly to the way the service contract defines service capabilities. A service built on a potentially reusable functional context [6] but with a contract that does not convey this reusability correctly does not achieve its reusability potential.
Within service-oriented solutions, a service contract represents a fundamental artifact, as this is the only medium through which services interact with each other or other consumer programs. This creates a strong need to standardize the service contracts in order to make services reusable and recomposable as much as possible. In order to achieve this, the standardized service contract design principle needs to be applied as its application results in standardized service contracts that are based on design standards [7] as set within a service inventory.
One of its goals is to reduce the need for data transformations as two services interact with each other, which can be achieved if the service contracts use standardized data models e.g. XML schemas if the services have been implemented as web services. This also helps in making services more interoperable. Another important goal of this design pattern is to use a standardized way of expressing service capabilities so that their purpose and ability can be easily understood at design time. [8]
A technical service contract [9] is usually composed of a WSDL document, XML schema(s) and policy document(s). Consequently, this principle needs to be applied across three areas of a service contract as described below:
The service's operations need to be defined using standardized naming conventions. This would also apply to the constituent input and out message names and their corresponding type names. This helps to increase the service contract's correct interpretation, which in turn increases service’s reuse and interoperability. When service contracts clearly express their capabilities, the chance of service duplication is also reduced.
Two services exchanging messages based on the same type of data—e.g., a purchase order—might model that data according to different schemas, which requires data model transformation. This clearly adds overhead, and stands in the way of service interoperability and reuse. To avoid this transformation, the standardized service contract principle requires standardized data models, which further helps create a standardized data representation architecture that can be reused across the enterprise to define standardized service capabilities. Schema centralization directly supports the objectives of data model standardization [10] design pattern, which further supports creation of centrally governed schemas.
Service policies represent terms of use for a service. So, for a service to be reusable, its behavioral requirements must be expressed consistently using standardized policy expressions based on industry standard vocabularies. This type of standardization further promotes separation of policies from service contracts into individual policy documents, which facilitates centralized governance. In some cases, two policies, though syntactically different, might mean the same thing—therefore, design standards must dictate acceptable policy structure.
Application of this design principle depends on design standards at the service inventory level. This requires additional resources, in terms of time and effort. Secondly, to apply this design principle effectively, the actual contract must be physically isolated from the service logic and implementation so that it can be based on industry standards. This can be achieved by the application of a decoupled contract [11] design pattern. Also that the ‘contract first’ approach needs to be followed so that the underlying logic only makes use of standardized data models. Furthermore, the requirement for centralized data models may end in transmission of redundant data between services, as the actual data a service needs may be only a subset of the data defined in the standardized schema imposed on the service.
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.
In computing and systems design, a loosely coupled system is one
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.
SOA security addresses the issue of combining services in a service-oriented architecture (SOA) in a secure manner. These issues arise as an effect of the main premise of SOA, which is to erase application boundaries and technology differences. Prior to the application of SOA methodologies, security models have traditionally been hardcoded into applications, and when capabilities of an application are opened up for use by other applications, the existing built-in security models may not be good enough.
Service Component Architecture (SCA) is a software technology designed to provide a model for applications that follow service-oriented architecture principles. The technology, created by major software vendors, including IBM, Oracle Corporation and TIBCO Software, encompasses a wide range of technologies and as such is specified in independent specifications to maintain programming language and application environment neutrality. Many times it uses an enterprise service bus (ESB).
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 event-driven messaging is a design pattern, applied within the service-orientation design paradigm to enable the service consumers, which are interested in events that occur within the periphery of a service provider, to get notifications about these events as and when they occur without resorting to the traditional inefficient polling based mechanism.
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.
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.
A canonical model is a design pattern used to communicate between different data formats. Essentially: create a data model which is a superset of all the others ("canonical"), and create a "translator" module or layer to/from which all existing modules exchange data with other modules. The canonical model acts as a middleman. Each model now only needs to know how to communicate with the canonical model and dont need to know the implementation details of the other modules.