Introduction to service-oriented design

2017-11-03 09:05:05

Service-oriented design is the process by which concrete physical service designs are derived from logical service candidates and then assembled into abstract compositions that implement a business process.

13.1.1. Objectives of service-oriented design

The primary questions answered by this phase are:

How can physical service interface definitions be derived from the service candidates modeled during the service-oriented analysis phase?

What SOA characteristics do we want to realize and support?

What industry standards and extensions will be required by our SOA to implement the planned service designs and SOA characteristics?

To address these questions, the design process actually involves further analysis. This time our focus is on environmental factors and design standards that will shape our services.

The overall goals of performing a service-oriented design are as follows:

Determine the core set of architectural extensions.

Set the boundaries of the architecture.

Identify required design standards.

Define abstract service interface designs.

Identify potential service compositions.

Assess support for service-orientation principles.

Explore support for characteristics of contemporary SOA.

13.1.2. "Design standards" versus "Industry standards"

The term "standards" is used frequently in this chapter. It is easy to confuse its context, so we often qualify it. Design standards represent custom standards created by an organization to ensure that services and SOAs are built according to a set of consistent conventions. Industry standards are provided by standards organizations and are published in Web services and XML specifications (as explained in the "Standards" vs. "Specifications" vs. "Extensions" section of Chapter 4).

13.1.3. The service-oriented design process

As with the service-oriented analysis, we first establish a parent process that begins with some preparatory work. This leads to a series of iterative processes that govern the creation of different types of service designs and, ultimately, the design of the overall solution workflow (Figure 13.1).

Figure 13.1. A high-level service-oriented design process.

Step 1: Compose SOA

A fundamental quality of SOA is that each instance of a service-oriented architecture is uniquely composable. Although most SOAs will implement a common set of shared technologies based on key XML and first-generation Web services specifications, the modular nature of the WS-* specification landscape allows for extensions to this core architecture to be added as required.

This step consists of the following three further steps that are explained in Chapter 14:

Choose service layers.

Position core SOA standards.

Choose SOA extensions.

Steps 2 to 4: Design services

These steps are represented by the following three separate processes provided in Chapter 15:

Entity-centric business service design process.

Application service design process.

Task-centric business service design process.

Our primary input for each of these service design processes is the corresponding service candidates we produced in the service modeling process during the service-oriented analysis.

Step 5: Design service-oriented business process

Upon establishing an inventory of service designs, we proceed to create our orchestration layerthe glue that binds our services with business process logic. This step results in the formal, executable definition of workflow logic, which translates into the creation of a WS-BPEL process definition (as explained in Chapter 16).

13.1.4. Prerequisites

Before we get into the details of the service-oriented design process, we should make sure that we have a sufficient understanding of key parts of the languages required to design services.

In Chapter 5 we described concepts related to WSDL and SOAP. In the next few sections, we supply introductory descriptions of the primary elements provided by these two markup languages, in addition to a handful of key elements from the XML Schema Definition Language. (Figure 13.2 re-establishes how these three specifications relate to each other.)

Figure 13.2. Three core specifications associated with service design.

These introductions are by no means a substitute for proper tutorials. The purpose of these sections is to provide you with enough background information so that you can better understand the following parts of the service-oriented design chapters:

The references made to specific parts of a language in the upcoming SOA Composition Guidelines chapter and the service design process descriptions in Chapter 15.

The markup code samples provided in the many case study examples interspersed throughout the three service design process descriptions in Chapter 15.

Note

If you already are comfortable with WSDL, SOAP, and XML Schema, feel free to skip ahead to the next chapter.

SUMMARY OF KEY POINTS
Before designing services, key decision points surrounding service layers and the set of industry specifications from which SOA will be composed need to be addressed. Chapter 14 covers this step. The main focus of the service-oriented design phase is to transform previously modeled service candidates into physical service designs. Step-by-step service design processes are provided in Chapter 15. An implementation agnostic workflow definition then is required to tie all of our service designs together into a cohesive unit of process logic. Chapter 16 demonstrates the use of WS-BPEL for this purpose.

SUMMARY OF KEY POINTS

Before designing services, key decision points surrounding service layers and the set of industry specifications from which SOA will be composed need to be addressed. Chapter 14 covers this step.

The main focus of the service-oriented design phase is to transform previously modeled service candidates into physical service designs. Step-by-step service design processes are provided in Chapter 15.

An implementation agnostic workflow definition then is required to tie all of our service designs together into a cohesive unit of process logic. Chapter 16 demonstrates the use of WS-BPEL for this purpose.

Категории