 | Level: Intermediate Christina Lau (clau@ca.ibm.com), Senior Technical Staff Member, IBM Software Group
Murray Beaton (beatonm@ca.ibm.com), Advisory Software Developer, IBM Software Group
22 Oct 2004 This article examines a number of patterns that you can follow to design and implement your business processes. Using a business scenario, it illustrates how to choreograph intra-enterprises and inter-enterprises services. Business rules are used in the context of the business process so that you can make changes dynamically without affecting the application.
Introduction
Part 3 in this series focuses on the Business Process Choreography Services that were outlined in the On Demand Operating Environment in Part 1. This article explores how to use BPEL to model a long-running business process that involves integrating services that a bank provides, as well as services that external providers supply. To download the code used in this article, see the download table under the Resources section.
Personal loan scenario
odFinance customers use the personal loan application when they want to request a loan. Through the bank portal, the customer fills in a form and submits a loan request. Later, the customer can log in to the bank portal to query the status of the loan request.
Behind the scenes, the process choreography pattern builds this business process. This business process invokes services the bank provides, as well as services such as credit checks that external providers offer. A mediator pattern aggregates various credit check providers and supplies the automation such that when a primary credit check provider is unavailable, it automatically switches to a secondary credit check provider.
Process choreography
Business process management is the methodology of understanding, coding, automating, and improving the way a company does business. Business process is important for the On Demand Operating Environment because it improves the way your business runs and therefore makes you more competitive. The Business Process Execution Language for Web Services (BPEL4WS, see Resources) offers a new standards-based approach to building flexible business processes by composing multiple Web services.
BPEL is a language that specifies how to create complex processes by wiring together different activities that can perform Web services invocations, manage state data between invocations, invoke compensation, correlate messages, throw faults, and terminate processes. These activities can be specified to run in sequence or in parallel, and they can also be nested. Similar to JDBC, which provides a standard way of talking to a database, BPEL now provides a standard way for aggregating Web services together using a common language.
IBM® WebSphere® Business Integration Server Foundation V5.1 (see Resources) and WebSphere Studio Application Developer Integration Edition V5.1 (see Resources) together provide an integrated development environment that you can use to create, test, and deploy BPEL-based business processes. This environment supports standard BPEL elements such as Receive, Reply, Invoke, Pick, Empty, Terminate, Assign, Wait, Throw, Flow, Sequence, While, Link, Switch, and Scope. In addition, the BPEL4WS language supports the following extensions:
- Human interaction as steps in the business process
- Inline invocation of Java code through the Java snippet
- Invocation of another process, called the Subprocess
Creating the personal loan business process
To create a new personal loan business process in WSAD-IE, use the Business Process wizard that Figure 1 shows. When you hit the Finish button, the visual BPEL editor will automatically be opened. Use drag and drop to add the BPEL elements that define the activities and control links into your process flow.
Figure 1. Creating a new business process
The personal loan business process is a multi-step operation that involves the following main activities (see also Figure 2):
- validateInput -- receives a loan request and validates the input fields
- createApplication -- verifies that the client applying for the loan is a valid odFinance customer. This involves making a service call to get the customer profile information that is stored in the legacy system, as described in the customer enrollment scenario. If the client is valid, initiate a new loan application.
- doCreditCheck -- performs a credit check on the client to ensure that the client has a good credit history with other financial institutions. This step illustrates a mediation pattern.
- autoApprove -- automatically approves the loan application for certain qualified customers. Otherwise, a loan officer must review the application before approving (approveLoan) or rejecting (rejectLoan) the loan request. This step illustrates a strategy pattern.
Figure 2. Personal loan business process
The mediation pattern: Virtualizing services
On demand companies focus on their core competencies. They want to free up their scarce internal resources to focus on the core and outsource the rest to the best providers that can supply the expertise and technologies that they do not have in house. Since credit checking is not a core bank competency, odFinance decides to outsource this function to external providers. To ensure that the business process will not be affected by an unexpected outage of a single provider, multiple providers are contracted. The credit checking service must be integrated in a seamless fashion. Credit checking is required on each loan applicant, but the bank doesn't care which particular provider is used.
To virtualize these credit checking services, you can use the Service Domain technology (see Resources). It provides a service grid whereby multiple related Web services can be aggregated and switched automatically based on policies defined on the Service Domain. These policies can be based on built-in rules such as round-robin or location proximity, as well as rules that are customized for the specific business. The Service Domain can also dynamically assemble a set of services and dispatch to the best available instance to satisfy the requestor needs.
The Service Domain provides a common service entry point that the doCreditCheck activity can invoke in the personal loan business process. This service entry point is described by a WSDL file and it can therefore be integrated into the BPEL process just like any other service, as Figure 3 shows.
Figure 3. Virtualizing credit check services using Service Domain
The strategy pattern: Customization using business rules
On demand companies are capable of sensing changes in the environment and responding dynamically to unpredictable fluctuations in supply or demand, emerging customer needs, or unexpected moves by their competition. For example, a rival bank might offer a 24-hour turn-around loan service for gold-level customers requesting a loan that is less than US$10,000. The odFinance business processes must be designed in such a way that it can adapt and respond quickly. It can use the Business Rules Beans (BRBeans) framework to achieve this.
Instead of burying all the logic inside an application, business rules encapsulate the chunks of business logic that are subject to change. For example, the loan amount for automatic qualification can change based on changing economic conditions. Moving these checks into business rules enables the rules to be changed independently from the application. Hence the bank can respond more rapidly by fine tuning the business processes without requiring redeployment on every code change. Figure 4 shows the interaction between the business objects and the BRBeans framework. A set of tools are provided for defining, executing, and managing the business rules.
Figure 4. Using Business Rules Beans framework
Managing and testing the business process
Once you have completed the development of your BPEL-based business process, you can generate the deploy code and unit test using the embedded Integration Test Environment. Figure 5 shows the Business Process Choreography Web Client that you can launch to start and administer the process instances. Use the generated user interface to quickly test your business process, including staff-approving activities. A graphical BPEL process debugger is also available so that you can single-step through your process, set breakpoints, and change the value of variables, as well as step into the Java source code.
Figure 5. Business Process Choreography Web Client
Conclusion
This article described a number of patterns that you can follow to design and implement your business processes. However, an on demand application is capable of anticipating and responding to customer needs and can continuously improve. Therefore, you need to analyze and model the business process, monitor its performance against historical trends and future objectives, as well as reallocate resources to optimize the execution. Future articles will discuss the best practices for these topics.
Download | Name | Size | Download method |
|---|
| i-odoebp3code.zip | 951KB | HTTP |
Resources
About the authors | 
| | Christina Lau is a Senior Technical Staff Member at IBM. Christina is an architect on the On Demand Development team focusing on next-generation technologies for the IBM On Demand Operating Environment. You can reach Christina at clau@ca.ibm.com. |
| | | Murray Beaton is currently working in On Demand Development and Incubation at the IBM Toronto Laboratory. Murray comes from a technical background, with his previous role being a Technical Team Lead with Websphere Studio Application Developer. He can be reached at beatonm@ca.ibm.com. |
Rate this page
| |
