Patterns: Implementing Self-Service in an SOA Environment

Chapter 1. Patterns for e-business 9

The makeup of these patterns is variable in that there will be basic patterns

present for each type. However, you can extend the Composite to meet

additional criteria. For more information about Composite patterns, refer to

Patterns for e-business: A Strategy for Reuse by Jonathan Adams, Srinivas

Koushik, Guru Vasudeva, and George Galambos (ISBN 1-931182-02-7).

1.2.2 Selecting Application patterns

After you identify the Business pattern, the next step is to define the high-level

logical components that make up the solution and how these components

interact. This is known as the

Application pattern. A Business pattern usually

has multiple possible Application patterns. An Application pattern might have

logical components that describe a presentation tier for interacting with users, an

application tier, and a back-end application tier.

Application patterns break down the application into the most basic conceptual

components that identify the goal of the application. In our example, the

application falls into the Self-Service business pattern, and the goal is to build a

simple application that allows users to access back-end information. Figure 1-4

shows the Self-Service::Directly Integrated Single Channel application pattern,

which fulfills this requirement.

Figure 1-4 Self-Service::Directly Integrated Single Channel pattern

Presentation

synchronous

Web

Application

synch/

asynch

Back-End

Application 1

Application node

containing new or

modified components

Application node containing

existing components with

no need for modification

or which cannot be changed

Read/Write data

Back-End

Application 2

10 Patterns: Implementing Self-Service in an SOA Environment

This Application pattern consists of a presentation tier that handles the request

and response to the user. The application tier represents the component that

handles access to the back-end applications and data. The multiple application

boxes on the right represent the back-end applications that contain the business

data. The type of communication is specified as synchronous (one request/one

response, then next request/response) or asynchronous (multiple requests and

responses intermixed).

Suppose that the situation is a little more complicated. Suppose that the

automobile policies and the homeowner policies are kept in two separate and

dissimilar databases. The user request actually needs data from multiple,

disparate back-end systems. In this case, there is a need to break the request

down into multiple requests (decompose the request) to be sent to the two

different back-end databases, then to gather the information that is sent back

from the requests, and put this information into the form of a response

(recompose). In this case, the Self-Service::Decomposition application pattern

(as shown in Figure 1-5) would be more appropriate.

Figure 1-5 Self-Service::Decomposition pattern

This Application pattern extends the idea of the application tier that accesses the

back-end data by adding decomposition and recomposition capabilities.

Presentation

synchronous

Decomp/

Recomp

synch/

asynch

Application node

containing new

or modified

components

Application node

containing existing

components with no need

for modification or which

cannot be changed

Read/

Write data

Transient data

- Work in progress

- Cached committed data

- Staged data (data replication

flow)

Back-End

Application 1

Back-End

Application 2