Enabling SOA Using WebSphere Messaging

Chapter 1. Introduction 3

development, Component Based Design, and Enterprise Application Integration

technology to an architectural approach for IT system integration.

Services are the building blocks of SOA, providing interfaces to functions out of

which distributed systems can be built. Services can be invoked independently

by either external or internal service consumers to process simple functions, or

can be chained together to form more complex functionality and so to quickly

devise new functionality.

What a service is

A service can be defined as any discrete function that can be offered to an

external consumer. This can be an individual business function or a collection of

functions that together form a process. For example, the process of a car dealer

selling a car to a new client involves process steps like:

1. Create client.

2. Correlate car and client.

Each of these steps can be designed as an independent service. A higher-level

service could use both and bind the single process steps to one process.

A service consists of the following three parts, which together are able to deliver

usable service functionality:

򐂰 Service contract

The service contract provides the formal specification of a service and

contains information like purpose, functionality, format of request and reply,

pre-conditions and post-conditions, exception handling, quality of service, and

so on. A formal interface definition provided by IDL or WSDL can be seen as

an optional part of the service contract.

򐂰 Service interface

The service interface exposes the implementation of the functionality.

Although the description of the interface is part of the service contract, the

physical implementation is contained in the service producer and consumer.

򐂰 Service implementation

The service implementation provides the business logic that is exposed by

the service interface.

1.1.3 Design principles

To meet the requirements of the drivers, a set of design principles is needed to

refine the desired characteristics of the system. Because services are a crucial

part of SOA, the principles mostly define their behavior and interaction.

4 Enabling SOA Using WebSphere Messaging

Granularity

Services should be delivered at a level of granularity and abstraction that is

meaningful to the service requestor. Many descriptions of SOA refer to the use of

large-grained services; however, some powerful counter examples of successful,

reusable, fine-grained services exist. For example, getBalance is a very useful

service, but hardly large grained.

More realistically, there will be many useful levels of service granularity in most

SOAs. For example, all of the following are services; however, they have

different granularity. Some degree of choreography or aggregation is required

between each granularity level for them to be integrated in an SOA:

򐂰 Technical Function Services

For example, auditEvent, checkUserPassword, and checkUserAuthorization

򐂰 Business Function Services

For example, calculateDollarValueFromYen and getStockPrice

򐂰 Business Transaction Services

For example, checkOrderAvailability and createBillingRecord

򐂰 Business Process Services

For example, openAccount, createStockOrder, reconcileAccount, and

renewPolicy

A service can be any business or technical function; however, in an SOA it is

preferable that the function is genuinely reusable. It is therefore inevitable that

conventions will need to be defined for assigning services to corresponding

abstraction layers. A criteria for this definition may be the level on which a service

provides a reasonable amount of reuse.

Figure 1-1 on page 5 provides an overview of the different abstraction levels

within an SOA.

Chapter 1. Introduction 5

Figure 1-1 SOA abstraction layers

Figure 1-1 is described below:

򐂰 Functional domain

Acts as the owner of different business processes. For example, a car dealer

needs to have a process for selling cars.

򐂰 Business process

A business process typically has a state attached to it and often acts as a

controller or workflow engine by calling different lower-level services

providing parameters that reflect the actual state of the process. For example,

the selling of a car involves the credit check for a client as well.

򐂰 Business services

A business service is atomic in nature but orchestrates the invocation of

lower-level component services into a business-level process. A business

service is stateless from the view of the requestor but may hold internal state

while calling lower-level services. Business services can be called

synchronously or asynchronously. For example, a car business service

provides the functionality of checking if a specific car is reserved for a client

before it performs the selling.

򐂰 Component services