Service design overview

The ultimate goal of these processes is to achieve a balanced service design. Typically this constitutes a Web service that accommodates real-world requirements and constraints, while still managing to:

• encapsulate the required amount of logic
• conform to service-orientation principles
• meet business requirements

You might be looking at your list of service candidates and wondering where to begin. It is good to raise this question, as there is a preferred sequence in which to create service designs. The rule of thumb is: design agnostic, reusable services first. This allows services that express logic specific to a process to compose reusable services as fixed resources (while also proving the quality of their reusability).

Given the four main types of service layers we identified previously, following is a suggested design sequence:

1. Entity-centric business services (Chapter 15)
2. Application services (Chapter 15)
3. Task-centric business services (Chapter 15)
4. Process services (Chapter 16)

This sequence is actually more of a guideline, as in reality, the service design process is not always that clear cut. For example, after creating an initial set of application service designs, you proceed to build task-centric services. Only while incorporating various operations, you realize that additional application service-level features are required to carry them out. This results in you having to revisit the application service designs to determine if you should add operations or entirely new services.

15.1.1. Design standards

It is important to note that a firm set of design standards is critical to achieving a successful SOA. Because the design we are defining as part of this phase is concrete and permanent, every service produced needs to be as consistent as possible. Otherwise, many key SOA benefits, such as reusability, composability, and especially agility, will be jeopardized. It is therefore assumed that prior to starting this phase, design standards are already in place. (The Service design guidelines section at the end of this chapter provides some recommendations that can help form the basis for standards.)

In our previous service-oriented analysis process, design standards were not as heavily emphasized (the need for standards was mentioned in a supporting guideline but was not made part of the process itself). This is primarily because service candidates can continue to be modified and refined after corresponding services have been developed and implemented, without significant impact. Standards are still relevant to service-oriented analysis, but not as much as they are integral to service-oriented design.

15.1.2. About the process descriptions

The sample processes in this section consist of generic sets of steps that highlight the primary considerations for creating service designs. This is our last chance to ensure a service properly expresses its purpose and capabilities.

As part of each abstract service description we create, the following parts are formally defined:

• definition of all service operations
• definition of each operation's input and output messages
• definition of associated XSD schema types used to represent message payloads

Note that individual service designs are composed later into a WS-BPEL process definition in Chapter 16.

15.1.3. Prerequisites

As explained in Chapter 13, our service design processes approach the creation of the service interface from a hand coding perspective. This means that many references to the WSDL and XSD schema markup languages are made throughout the process descriptions.

Further, to support our processes, numerous interspersed case study examples provide actual WSDL and XSD schema markup samples. Reading through the WSDL and XSD tutorials provided in Chapter 13 therefore is recommended to best understand the process descriptions and associated examples.

Case Study

Both of our fictional organizations have completed the service-oriented analysis phase for their respective SOAs. In doing so, each has established a set of service candidates that will form the basis for their service-oriented design. Let's review which of the service candidates we will be incorporating into the examples interspersed throughout this chapter.

The service modeling exercise performed by TLS produced the following five new service candidates that represent its new Timesheet Submission solution:

• Timesheet Submission Process (Process)
• Employee (Entity-centric)
• Timesheet (Entity-centric)
• Invoice (Entity-centric)
• Notification (Application)

Following the suggested design sequence, TLS will be subjecting the three entity-centric services to the corresponding service design process first. Next, it will design the Notification Service, along with additional application services that are required. Finally, the business process logic itself will be defined, as the Timesheet Submission Process Service is designed through a WS-BPEL process definition.

Amidst all this activity, our examples will focus on the design of the following two services:

• The Employee Service candidate will be referenced in the examples provided as part of the Entity-centric business service design process description.
• The Timesheet Submission Process Service candidate will become the basis for the workflow logic we need to establish a proper service composition for the Timesheet Submission Process. (TLS achieves this in Chapter 16.)

The service candidates modeled by RailCo consist of the following four application services and two task-centric business services.

• Invoice Processing (Task-centric)
• PO Processing (Task-centric)
• Legacy System (Application)
• Polling Notification (Application)
• Transform Accounting Documents (Application)
• Metadata Checking (Application)

The two service candidates here will be referenced in our design process description examples:

• The Transform Accounting Document Service candidate will be used to demonstrate the Application service design process description.
• The Invoice Processing Service candidate will be used as part of the Task-centric business service design section.

SUMMARY OF KEY POINTS

• The three design processes described in this chapter are based on the "WSDL first" approach.
• Design standards play a critical role in shaping the service design process and in guaranteeing a consistently standard SOA.