Part V: Building SOA (Technology and Design)

Chapter 13	Service-Oriented Design (Part I: Introduction)
Chapter 14	Service-Oriented Design (Part II: SOA Composition Guidelines)
Chapter 15	Service-Oriented Design (Part III: Service Design)
Chapter 16	Service-Oriented Design (Part IV: Business Process Design)
Chapter 17	Fundamental WS-* Extensions
Chapter 18	SOA Platforms

Time for the rubber to hit the road, as we apply the theories , concepts, and analysis results from past chapters to real world, concrete SOA designs. The remaining chapters in this book explore numerous facets of SOA technology interspersed with detailed, step-by-step process descriptions that explain how to apply this technology to realize individual services and SOA as a whole.

Chapter 13. Service-Oriented Design (Part I: Introduction)

At the beginning of Chapter 11 we stated that the service-oriented analysis phase is probably the most important part of our SOA delivery lifecycle. If this is the case, then the service-oriented design phase is a very close second. The service-level decisions made at this stage collectively will determine the quality and longevity of the resulting SOA.

Throughout the following four service-oriented design chapters, we emphasize the fact that custom design standards are a crucial part of this stage. We do this because their use and adherence will ultimately set the "potential barometer" for realizing many of the primary benefits of contemporary SOA.

How case studies are used: Both of our fictional companies face some strategic decisions during the preparatory stage of the service-oriented design process. The choices they make with regard to how they plan to shape their respective SOAs will influence the service design processes they will undergo in the following chapters.

13.1. Introduction to service-oriented design

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).

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:

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.)

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.