Service-Oriented Design (Service Contract)

The Service-Oriented Design phase represents a service delivery lifecycle stage dedicated to producing service contracts in support of the well-established “contract-first” approach to software development.

The typical starting point for the Service-Oriented Design process is a service candidate that was produced as a result of completing all required iterations of the Service-Oriented Analysis process (Figure 1). Service-Oriented Design subjects this service candidate to additional considerations that shape it into a technical service contract in alignment with other service contracts being produced for the same service inventory. Different approaches are used during this stage for the design of REST services, as these types of services share a common universal contract.

As a precursor to the Service Logic Design stage, Service-Oriented Design is comprised of a process that steps Service Architects through a series of considerations to ensure that the service contract being produced fulfills business requirements while representing a normalized functional context that further adheres to service-orientation principles.

Part of this process further includes the authoring of the SLA, which may be especially of significance for cloud-based services being offered to a broader consumer base via the SaaS cloud delivery model.

Figure 1 – When a given service is deemed to have received sufficient analysis effort, it is subjected to the Service-Oriented Design process that produces a physical service contract.

Figure 2 – Unlike the popular process of deriving Web service contracts from existing components, SOA advocates a specific approach that encourages us to postpone development until after a custom designed, standardized contract is in place.

Service-Oriented Design Processes

All of the effort put into the analysis and service modeling processes results in a collection
of service candidates that establishes the starting point for service design. Every
candidate definition can be used as input for a service-oriented design process. A different
process exists for each of the four primary service models, but all are shaped and
structured around the application of service-orientation design principles. Unlike the
service modeling process where only a subset of the principles come into play, all eight
principles are fully applied during service design.

Figure 3 – Common service-oriented design processes.

Design Processes and Service Models

As shown in the previous figure, there is a suggested sequence in which services can be designed,
based on their respective service models. Entity services have the most independence
because they derive their functional
context from predefined business
entities. Prior service modeling
efforts will have ideally established
refined and balanced entity service
candidates with appropriate levels of
service and capability granularity.

Utility services are typically designed
next. Even though they don’t have
the benefit of pre-defined functional
contexts and are therefore more difficult
to create, they still can be delivered
independently due to the fact
that they typically encapsulate agnostic
functionality.

A further benefit to designing and
even delivering entity and utility
services first is that they can be tested
independently as generic, reusable
resources. When task-centric services
are delivered thereafter, they can
immediately be designed to bind to
the agnostic service contracts to finalize
the required composition logic.

This sequence is only suggested
and not required. There may be
circumstances during which it makes
more sense to change the order in
which services are designed or to
design and deliver a group of services
simultaneously.

During service design, many specific considerations are taken into account, shaping a service contract in support
of standards, principles, and practical constraints.

When building services as Web services, these processes essentially advocate defining
the required XML schema complex types first to ensure consistency with other service
contracts that may be using the same set of standardized schemas. An abstract WSDL
definition is then built around the complex types and further adjusted and optimized by
the application of service-orientation principles and design standards.

For agnostic services, these processes raise special considerations associated with the
extension of planned service logic in support of increased reusability potential. Finally,
other services required to carry out the defined Web service operations are also identified,
as per previously modeled composition candidates.

Each service model has unique design requirements, which is why each deserves its
own design process. Task-centric service design processes have less emphasis on exploring
reusability and are more concentrated on the service’s role as parent controller.
Design processes for orchestrated task services tend to be distinct in that they generally
require the design of service-oriented business processes which, in the Web services
world, usually involves the creation of WS-BPEL process definitions.

Service Design Processes and Service-Orientation

The design of services is carried out in two specific phases. The service contract design
process represents the first stage during which the technical contract is created, standardized,
and finalized. This stage may involve the delivery of a series of contracts or
just one, depending on the scope of the service delivery project and the overall methodology
being used. At some point thereafter, the actual service logic is designed and then
developed in support of the contract. The figure illustrates this simple but important
sequence and also reminds us that service-orientation applies to both stages of service
design.

Figure 4 – An example of how the design of an entity service is partitioned into contract and logic design stages, both of
which are shaped by service-orientation design principles.