Creating service-oriented flexible business solutions with WebSphere Business Services Fabric (2)

This article supporting source code

Introduction

Part 2nd of this series describes the requirements that we will build and deploy in the WebSphere Process Server V6.1 to interact with the WebSphere Business Services fabric (hereinafter called fabric). This application simulates a car loan acquisition system that accepts user information and responds with approval or rejection of a loan request. You will learn how to build an ontology extension to capture volatile points in business processes and support dynamic binding, in which service endpoints are discovered dynamically during service invocation.

Fabric eliminates the need for hard-coded static service bindings and provides late-service binding to support a more generalized process model. With fabric, you can define abstract business processes and capture process variability points in business policies that control run-time behavior and isolate processes from changes. Fabric makes it possible to dynamically change the behavior of business processes in order to effectively respond to changing business requirements.

Prerequisite

To complete the steps in this article, you need the following:

Rational®software Architect V7 with the following features installed:

Scalability features (all features except reusable asset specification (reusable ASSET specification)

WSDL and XSD Modeling and transformation

Ibm®business Services Fabric Modeling Tool

Fabric Business Glossary and Fabric Ontology Overview (available in the modeling folder of the fabric V6.1 Tool Pack)

Fabric Core stubs (available in the modeling folder of the fabric V6.1 Tool Pack)

About use Cases

In subsequent sections of this series, you will develop a portfolio business application that simulates the car loan acquisition process. When a user submits a loan request, the system processes the request and performs the following tasks:

Credit verification

License verification

Loan Supply

Table 1 describes the main elements of the use case:

Table 1. Car loan Acquisition System use case element

Use case elements	Describe
Car Loan Acquisition System	Process a user's loan request
Use case description	The user submits a loan request to buy a car.
Key participants	Any user
Basic flow	Credit verification and license verification were successful, and loans with uncertain interest rates were approved.
Alternate stream	Credit verification or license verification failed. Refuse a loan request.

Realizing the process of automobile loan

Figure 1 shows the flow of the car loan acquisition system.

Figure 1. Flow Chart of auto loan acquisition system

As shown in Figure 1, the car loan process needs to be integrated with the various Third-party service providers, such as Licenseverificationservice and Loanproviderservice. Third-party service providers expose their functionality as WEB services.

When implementing a car loan acquisition process, you typically use a variety of if...else conditions in your business process, as shown in Figure 1, and hard-code your service bindings, making your processes inflexible and less adaptable to change. A study of the car loan acquisition business process in Figure 1 can be seen in the process involving various variable points:

Depending on the time of day, a different endpoint (Creditcheckservice Dayep or creditcheckservicenightep) needs to be invoked to provide a credit authentication service.

Depending on the location of the customer (California or Texas), different endpoints (LICENSEVERIFICATIONCAEP or LICENSEVERIFICATIONNONCAEP) need to be invoked to provide license verification services.

Depending on the customer type (gold or silver customer), different endpoints (LOANPROVIDERGOLDEP or loanprovidersilverep) need to be invoked to provide loans to the customer at different response times.

As the number of service and process variability points begins to increase, using these methods to manage business processes becomes cumbersome and less flexible. To consolidate changes into the process, developers need to update and redeploy business processes. For example, suppose that the car loan business process now requires that you provide services to the new customer category, such as platinum customers, and that the response time for platinum customers should be faster than the existing gold and silver customers. To consolidate this change, another if...else construct is needed in the business process to invoke a particular endpoint, such as LOANPROVIDERPLATINUMEP, to meet that requirement, which requires changing the business process and redeploying it. It is difficult to determine how this change affects business processes without preparing the appropriate governance process.