1.
Standardized Service
Contracts
Description
Services express their purpose and capabilities via a service
contract. A great deal of emphasis is
placed on specific aspects of contract design, including the manner in which
services express functionality, how data types and data models are defined, and
how policies are asserted and attached.
Rationale
The Standardized Service Contract design principle is perhaps
the most fundamental part of service-orientation in that it essentially
requires that specific considerations be taken into account when designing a
service's public technical interface and assessing the nature and quantity of
content that will be published as part of a service's official contract.
There is a constant focus on ensuring that service contracts
are both optimized, appropriately granular, and standardized to ensure that the
endpoints established by services are consistent, reliable, and governable.
Implications
Creation standards and/or the adoption of open industry standards
to maximize interoperability for describing service functionality, data types,
models and policy application must be performed.
2.
Service Loose Coupling
Description
This principle promotes the independent design and evolution
of a service's logic and implementation while still guaranteeing baseline
interoperability with consumers that have come to rely on the service's
capabilities.
This principle advocates the creation of a specific type of
relationship within and outside of service boundaries, with a constant emphasis
on reducing ("loosening") dependencies between the service contract,
its implementation, and its service consumers.
Rationale
Service consumers should not be coupled to the service
implementation, instead they should have a dependency on the service contract. With coupling only to the service contract,
the service implementation is capable of evolving without impacting the service
consumer, thus the coupling is “loose”.
Additionally, by having the service implementation only
dependent on the service contract to which it adheres, the implementation does
not have any implicit coupling to service consumers.
Implications
Services should follow contract first design methodologies to
prevent any coupling of a consumer to an implementation, or vice-versa.
3.
Service Abstraction
Description
On a fundamental level, this principle emphasizes the need to
hide as much of the underlying details of a service as possible. Doing so
directly enables and preserves the previously described loosely coupled relationship.
Rationale
Having an appropriate level of abstraction, and hiding away
implementation details, allows for greater productivity of all of the service
consumers, because they only need to know a simplified and ideal interface.
Taking the effort to hide legacy integrations, proprietary
technologies, and other service implementations once, with a highly specialized
group of developers, allows for greater scalability in an organization. The technology components and strategies may
also evolve independent of the SOA Services functionality.
Implications
Service contract design should not leak any information about
the underlying implementation – no datatypes, no data structures.
4.
Service Reusability
Description
Service Reusability emphasizes the positioning of services as
enterprise resources with many functional contexts. Numerous design
considerations are raised to ensure that individual service capabilities are
appropriately defined in relation to a business-neutral service context, and to
guarantee that they can facilitate the necessary reuse requirements.
Rationale
The service design and implementation process takes
considerable work effort, and the desire to maximize the value of that effort
is embodied by this principle. Many
common elements exist across software solutions, and the service development
effort can often be shared across solutions.
Though some services are not reusable, the intent of
developing those services must be to support another principle.
Implications
Service contracts and components should be designed to
maximize interoperability, and align to the functionality needed by the largest
number of service consumers.
5.
Service Autonomy
Description
Services are components that are independently deployed,
versioned, and managed. A suitable level
of autonomy is achieved when the service can evolve independently of the
service consumers, or underlying technology.
Rationale
This principle raises various issues that pertain to the
design of service logic as well as the service's actual implementation
environment. Isolation levels and
service normalization considerations are taken into account to achieve a
suitable measure of autonomy, especially for reusable services that are
frequently shared.
For services to carry out their capabilities consistently and
reliably, their underlying solution logic needs to have a significant degree of
control over its environment and resources.
Implications
Services must be architected and designed so that the
endpoint location, and the service contract, is the only known element of the
service.
Services should be deployed independently of the systems in
which they are consumed.
6.
Service Statelessness
Description
Applying this principle requires that measures of
realistically attainable statelessness be assessed, based on the adequacy of
the surrounding technology architecture to provide state management delegation
and deferral options.
Rationale
The management of excessive state information can compromise
the availability of a service and undermine its scalability potential (our
Operational Assurance Technology Policy v1.1 of January 2015 states the
horizontal scalability goals). Services are therefore ideally designed to remain
stateful only when required.
Furthermore, if a single instance of a service holds the
state for the service consumer, or the state of the various intermediaries
between the originating consumer and the service, when the service fails, the
state is lost and an unrecoverable error will occur for the service consumers.
Implications
The service and all components of the service must be
implemented in a stateless manner.
When a fully stateless implementation cannot be achieved,
explicit choices and decisions about the state that needs to be present in the
service must be articulated for purposes of architectural exceptions.
Partial state deferral, or full state deferral, must be
implemented in alternate solutions than the service.
7.
Service Discoverability
Description
The application of this design principle results in the
improvement of a service's discoverability and interpretability as a result of
increasing the communications quality of all published service meta
information.
Rationale
Aligned to the principle of Reusability, in order for a
service to be reusable, it must be discoverable. For services to be positioned as IT assets
with repeatable ROI, they need to be easily identified and understood when
opportunities for reuse present themselves.
Implications
Creation and maintenance of a Service Catalog is
required. Other assets like a service
registry and service repository are recommended.
The service design needs to take the "communications
quality" of the service and its individual capabilities into account,
regardless of whether a discovery mechanism (such as a service registry) is an
immediate part of the environment.
8.
Service Composability
Description
Services are expected to be capable of participating as
effective composition members, regardless of whether they need to be
immediately enlisted in a composition.
Rationale
As the sophistication of service-oriented solutions continues
to grow, so does the complexity of underlying service composition
configurations. The ability to effectively compose services is a critical
requirement for achieving some of the most fundamental goals of
service-oriented computing.
Complex service compositions place demands on service design
that need to be anticipated to avoid massive retro-fitting efforts.
The Service Composability principle helps determine how to
carry out a separation of concerns in support of service-orientation. The
services that result from the illustrated decomposition of solution logic are
assembled to solve any specific problem. However, the ultimate, strategic
benefit comes with the ability to continually recompose these services to help
solve additional problems in the future.
Implications
Having a specific vision for a service, and a clear
identification of the purpose and its responsibility in the environment is
required.
To facilitate composability, the service must also adhere to
Discoverability, and the following two principles: Service-Orientation and
Interoperability plus Explicit Boundaries.
Service inventories will be built out with named services
fulfilling specific capabilities, and service inventories may be divided by
business domain, or responsibility within the domains.
9.
Service-Orientation and
Interoperability
Description
Services in a Service Oriented Architecture must be
interoperable by design, and adhere to open standards that support automation
and tooling for facilitating and easing intersystem communications.
Interoperability is the ability of different information
technology systems and software applications to communicate, exchange data, and
use the information that has been exchanged.
Rationale
Interoperability refers to the sharing of data. The more
interoperable software programs are, the easier it is for them to exchange
information. Software programs that are not interoperable need to be
integrated. Therefore, integration can be seen as a process that enables
interoperability.
A goal of service-orientation is to establish native
interoperability within services in order to reduce the need for integration
effort.
Implications
Interoperability is specifically fostered through the
consistent application of design principles and design standards. This
establishes an environment wherein services produced by different projects at
different times can be repeatedly assembled together into a variety of
composition configurations to help automate a range of business tasks.
Interoperability is fundamental to the first eight principles
listed.
A fundamental goal of applying service-orientation is for
interoperability to become a natural by-product, ideally to the extent that a
level of intrinsic interoperability is established as a common and expected
service design characteristic.
10.
Explicit Boundaries
Description
Implicit in several principles documented previously,
services need explicit boundaries.
Messages containing all of the information required for proper service
operation should be passed when the service is invoked, and all behaviors of
the service should be documented for the publicly exposed interface.
Rationale
The Service should not have hidden behaviors, or unexpected
side-effects caused by a service consumer sending data or data fields to the
service that are not covered by documented contracts, or by having partial data
delivery cause other side-effects.
Without well documented service functional boundaries,
service reuse is compromised, or during the maintenance of a service,
additional un-related service functionality may be added.
Implications
During service candidate evaluation, the ability to
specifically create logical and functional boundaries for services must be a
consideration before deciding to approve a new service for inclusion in the
portfolio.
Documenting the intended purpose of a service as part of the
service metadata is required.
No comments:
Post a Comment