Patterns: Implementing Self-Service in an SOA Environment

234 Patterns: Implementing Self-Service in an SOA Environment

Application pattern selection

The activity diagram makes the requirements of the application a little clearer. At

this stage, we can see that several application patterns might be appropriate.

򐂰 Directly Integrated Single Channel

There is one service provider for the credit check action and one for the

e-mail action. These services will be accessed using a direct connection.

򐂰 Router

The customer will have the opportunity to select the product and delivery type

in which they are interested. The application will examine the choice selected

by the customer and route the request to the appropriate application. The

application will assign an account number to the new customer.

򐂰 Decomposition

In the event that the customer selects multiple types, the application will send

that request to each selected business division and collect the account

numbers before responding to the client.

8.3.2 Sequence diagram

ITSOMart next used a sequence diagram to illustrate the chronological sequence

of messages between objects in an interaction. The sequence diagram for the

customer registration scenario is shown in Figure 8-3 on page 235.

Chapter 8. Business scenario and design 235

Figure 8-3 Sequence diagram of ITSOMart application

The flow of the ITSOMart application is as follows:

1) A customer accesses the Web site and clicks a button requesting to

register. The request is processed by a JSP, which provides a form

for user information.

2) The customer enters the requested data and clicks a Submit button.

JSF is used to validate the data on the client-side. The data includes

customer data and the type of account requested. One or more

account types can be selected.

3.1.1) The JSP stores the data input by the customer into a DB2 database

using CMP’s.

3.1.3) Next, it places a message on a queue containing the primary key of

the record stored in the database.

1: Cust Entry Page

2: Cust Entry Page

<<return>>

3.1: process details

3.1.1: Store User Details

<<return>>

3.1.2: Store User Details

3.1.3: Put PK of DB in MQ Q

<<return>>

User: View: Model/Controller: Local DB2 DB: JMS: MDB/Processor Module: ESB: Credit Check WS: Services:

Interaction1

View: Model/Controller: Local DB2 DB: JMS: MDB/Processor Module: ESB:

Services:

User:

JMS can be

a standalone

WebSphere MQ

or ESB

WS stands for

Web Service

[Good Credit]

3.1.3.2: Send Email

3.1.3.1: process details

3: Page Submit

<<return>>

3.1.3.1.1: Page Submit

<<return>>

3.1.3.1.2: Retrieve PK details

<<return>>

3.1.3.1.3: Retrieve PK details

3.1.3.1.5: Get Cust details from DB using PK

3.1.3.1.6: Get Credit Rating

3.1.3.1.6.1: Get Credit

3.1.3.1.6.2: Get Credit

<<return>>

3.1.3.1.7: Get Credit Rating

alt-a

3.1.3.1.4: Get Cust details from DB using PK

<<return>>

3.1: Get Message and send Email

3.2: Get Message and send Email

<<return>>

1: Delete User from Local DB

<<return>>

2: Delete User from Local DB

[Bad Credit]

3: Put Rejection Email

alt-b

Credit Check

3.1: Get Message and send Email

3.2: Get Message and send Email

<<return>>

3: Put Acceptance Email

E-mail

Account

21: Calls WS to get account number

2.2: Calls WS to get account number

<<return>>

2: Get account number

1: Put customer details in CRM

Customer

CRM

1.1: Calls JCA WS to put customer details in CRM

1.2: Calls JCA WS to put customer details in CRM

<<return>>

E-mail