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.