ServiceOrientation.com

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.