Introduction

Part 1 of the series "Building SOA composite business services," (see Resources) describes a composite application called Jivaro, which is also the name of a fictitious bank. In this article, using the Jivaro banking application as an example, you'll learn how to use selectors and business rules to achieve dynamicity and configurability. Mediation modules in WebSphere Enterprise Service Bus (ESB) and dynamic service mediation using WebSphere Business Services Fabric (WBSF) are alternative options for achieving dynamicity and configurability. Upcoming articles in this series will examine ESB and WBSF.

Use cases in Jivaro

"Building SOA Composite Business Services, Part 1" identifies use cases that are initiated by a bank customer. The Apply for Loan use case invokes a BPEL business process. The business process goes through a series of steps that involve invoking services in order to process the loan application.

Back to top

Using selectors

A selector decouples the client application from a specific target implementation. At run time, based on a predefined set of criteria, the selector determines which target implementation to invoke, such as the date and time of the invocation. This allows a change of target implementations without a change to the client. Selectors also exhibit run-time dynamicity of service endpoint choices (as explained in Part 1 of this series). New target implementations can be added to a selector at run time, without requiring a restart of WebSphere Process Server (Process Server) server instance where the selector is deployed.

In the Jivaro application, the CreditCheckQueryService has multiple target implementations offered by different Jivaro partners. On a particular day of a year, the Jivaro bank needs to change to a different credit check provider of the CreditCheckQueryService. The Jivaro bank wants to avoid down time while making the change. This section shows how the requirements can be satisfied using selectors.

Overview of CreditCheckQueryServiceSelector

The CreditCheckQueryServiceSelector is realized in the SasBankWSSelectors Service Component Architecture (SCA) module, as shown in Figure 1. The default destination for this selector is CreditCheckQueryService (in the upper right of Figure 1). The alternative destination is newCreditCheckQueryService (shown below the CreditCheckQueryService). The particular days of the year when Jivaro bank would like to use the newCreditCheckQueryService are shown on the bottom half of Figure 1, where the selection time scope is from June 1, 2006 at 12:00 A.M. until Jan 1, 2007 12:00 A.M.

Scenario 1: Invoke the original CreditCheckService

This scenario uses the embedded Web service test explorer in WebSphere Integration Developer V6 (Integration Developer) to test the Web service CreditCheckQueryServiceSelectorExport exported by the CreditCheckQueryServiceSelector in the SasBankWSSelectors SCA module, as shown in Figure 2.

Because the date of the test is 05/22/2006, the Web service invocation is directed to the default service, which is the CreditCheckQueryService. This service returned a credit score of 550.

Scenario 2: Change the target implementation to the new CreditCheckService

To redirect the Web service invocation to the second service, NewCreditCheckQueryService, you need to change the selection criteria. We'll use the selector config Web tooling embedded in the Process Server 6 admin console.

Go to Application > Server1 > Selectors in the Process Server admin console, as shown in Figure 3. Click the CreditCheckQueryServiceSelector link.

Under Selector Tables, click retrieveCreditScore, as shown in Figure 4.

Click the corresponding selection criteria link, as shown in Figure 5 and Figure 6.

Click the second target in the targets list before changing the date.

You just went through the steps to reconfigure the selection criteria for the operation retrieveCreditScore and changed the start date from June 1, 2006 to January 1, 2006. The changed configuration is shown in Figure 7.

After committing the configuration change through the Process Server admin console, you can go back to the Web service test explorer in Integration Developer and rerun the test case. The return value of 619 is different from the value 550 returned by the first call, even though the same input parameter -- 001002111 -- was used (see Figure 8). The Web service invocation has been successfully redirected by the selector to the second service, NewCreditCheckQueryService, because the current time of 05/22/2006 is in the scope of the changed selection criteria (from 01/01/2006 to 01/01/2007) for the second target service.

Using business rules

In Integration Developer, the business rule logic is specified in a simple form, such as a sequence of if-test-then-actions clauses or a simple decision tree.

Business rules allow the separation of the business rule logic from the other services, applications, and processes in the system. Details of business rules can be changed frequently and dynamically.

In the scenario, we applied business rules to the Jivaro application to achieve configurability, flexibility, and dynamicity (see "Building SOA Composite Business Services" in Resources).

In the Apply for Loan use case, several business rules are in the process that handle the loan application. For example:

If the credit score of the applicant is less than 500, the loan application will be automatically rejected.

Because Jivaro banking is a multi-tenant environment, the parameters of a rule (for example, 500) may be different among different tenants. Thus, a tenant (the bank) ID is also included as a condition of business rules. The sample rule is changed, as follows:

If the bank ID is 001 and the credit score of the applicant is less than 500, the loan application will be automatically rejected.

The numbers in italics represent configurable parameters in the business rule, which can be changed at run time.

You can develop rules and rule templates in Integration Developer and change the configurable parameters at run time in the Process Server business rules manager application.

Developing business rules in Integration Developer

Business rule templates in Integration Developer allow analysts to change business rules without having to restart the project or application server. A template defines variables that can be modified. Using templates, similar rules can be created just by making changes to the parameters, without having to redefine the implementation.

First create a rule template called AutoRejectTemplate, as shown in Figure 9, with bank id and score number parameters that can be changed at run time.

Next, create the rule Bank1AutoReject from the template AutoRejectTemplate, as shown in Figure 10.

Change of business rules in business rules manager

Business rules manager is a Web tool provided by Process Server to allow change to business rules at run time. Figure 11 shows the Bank1AutoReject rule.

For example, a business analyst can change business rules by editing the configurable parameters, such as the bank id and the credit-score threshold shown in Figure 12.

The analyst can also create a new rule from a business rule template by filling in the parameters, as shown in Figure 13.

Back to top

Other options to consider

You can also use mediation modules in ESB and WBSF (as well as Process Server) to achieve dynamicity. Mediation modules provide the capability to transform, route, and augment a message from an external data source. You can code more complex routing logic using a mediation module rather than a selector. For example, dynamic binding to a target implementation based on the contents of the message can be achieved using mediation modules. However, this requires developing custom code. A mediation module cannot be changed as easily at run time as business rules and selectors.

WBSF provides a dynamic service selection based on context and content in message headers and policies specified as assertions. WBSF policies are extensible through ontology extensions. Service selection criteria can also be changed at run time by changing assertion metadata and by adding new endpoints. WBSF also provides governance functions over run-time changes. However, developing solutions using WBSF involves several steps to modify metadata definitions and message headers.

Selectors and business rules provide solutions for meeting simple dynamicity and configurability requirements.

Back to top

Issues and best practices

This section discusses a few issues uncovered during the development of Jivaro and some "best practice" tips.

Decision tables compared with rule sets

It's best to choose rule sets when business rules have few clauses or variables in the conditional statements, or if multiple business rules must be executed. Choose rule sets instead of decision tables when the sublevel clauses are not the same in every branch. For example, in the Apply for Loan use case, the credit score thresholds for auto-reject are different in bank 1 and bank 2, as shown in Figure 14.

If the bank ID is 001, the credit score of the applicant is less than 500, the loan application will be automatically rejected.

If the bank ID is 002, the credit score of the applicant is less than 450, the loan application will be automatically rejected.

The sub-level conditions must always be the same in every branch in decision tables, as shown in Figure 15.

Selectors and exports

A selector can reach an export in another SCA module, without requiring an import. A selector decides which targets should be invoked at run time. The choice of targets is based on:

• All components in the same SCA module with a matching interface
• All matching exports deployed to Process Server

Consequently, all exports with matching interfaces in other SCA modules can be wired to the selector. A selector does not need an explicit SCA import defined in order to reach an export in another module.

Tooling or run-time configuration support

Tooling or run-time configuration support is unavailable for nondate-range-based selectors and custom selectors. Currently there are three kinds of selectors supported by Process Server V6:

Generic date-range-based selectors

Make their invocation decision based on a date range. These selectors are fully supported by the Integration Developer tooling and by the Process Server admin console. Extra ranges can be added at run time, candidate targets can be changed at run time, and the resulting modifications can be re-exported back to the tooling.

Generic non-date-range-based selectors

Do the selection based on other data types and conditions. They allow selection based on other ranges (such as integers, longs, doubles) and are based on discrete values. For example, "If the string in the business object is X, then route to the Y destination." You can achieve this function by editing an XML-based .selt file.

Custom selectors

Can be used to write custom algorithms.

For the non-date-range-based selectors and custom selectors, there is currently no tooling or run-time configuration support. A key benefit of using selectors is the ability to add, remove, and change targets at run time by using the Web-based tooling that's embedded in the Process Server admin console. A selector modified by editing the .selt file or by extension, through a custom selector, loses this ability.

To retain the ability to change targets at run time, currently the best choice is to use a custom Java code snippet to render selection logic as an expression that returns a date to be used as the selection criterion for the date-range-based selectors.

Back to top

Summary

This article explains how selectors and business rules are used in the Jivaro banking system to achieve dynamicity and configurability. The solution, when compared with WebSphere Enterprise Service Bus mediation or WebSphere Business Services Fabric, is more accessible to developers who are unfamiliar with Java. You also learned about the issues uncovered in the development of Jivaro composite business services and some suggested best practices.

Stay tuned for the next installment in this series, which will describe an approach for implementing dynamicity with WebSphere Enterprise Service Bus mediation modules. The article will explore the limitation of the selectors and business rules in respect to endpoint aliasing across different protocols (for example, SOAP/HTTP compared to SOAP/JMS), and give an example of a mediation module suitable for programmatic aliasing regardless of the underlying protocol.

Resources

Learn

• Read the other parts in this series:
  • Part 1, "Choosing the right implementation," gives an overview of the different options for designing and developing composite business services to cope with change, and describes the features and capabilities in IBM WebSphere software that can help you enable points of variability.
  • Part 2, "Using dynamic service mediation in WebSphere Business Services Fabric," explains how to bind, at run time, a service invocation in a Business Process Execution Language (BPEL) process to one of several related endpoints by using ontology extensions and the WBSF Dynamic Service Assembler.
  
  
• "Building SOA composite business services, Part 1: Develop SOA composite applications to enable business services" (developerWorks, Oct 2006) explains how to integrate existing SOA services by composing them in different ways.
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the IT architecture arena.
  
  
• Learn more about:
  • WebSphere Process Server
  • WebSphere Enterprise Service Bus
  • WebSphere Business Services Fabric
  
  
• Read the Wikipedia discussion of business rules.
  
  
• A guided tour of WebSphere Integration Developer: Part 6: Becoming more on-demand using dynamic business rules.
  
  
• A guided tour of WebSphere Integration Developer: Part 8: Dynamically invoking a component using selectors.
  
  
• "Versioning and dynamicity with WebSphere Process Server" (developerWorks, Feb 2006) introduces some of the key service-oriented concepts in the product and explains their purpose.
  
  
• Go to WebSphere Business Process Management information center for all of the information that you need to install, maintain, and use IBM WebSphere Business Process Management software.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• RSS feed for this series. (Find out more about RSS.)
  
  

Get products and technologies

• Get started now! Download more IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Ying Chun Guo works as a software engineer at the China Technology Institute, China Software Development Laboratory. She is currently working on composite business services (CBS) and Service-Oriented Architecture (SOA).

Qiang Wang works as a staff software engineer at the China Emerging Technology Institute, China Software Development Laboratory. He concentrates on IBM incubator projects and Service-Oriented Architecture (SOA)-related topics. His interests include J2EE, SOA, MDA/MDD, AOP, RUP, and project management. He is currently working on an SOA pilot called CBS (composite business services).

Dr. Germán Goldszmidt is a distinguished engineer working in the IBM Software Group, with focus on architecture of an integrated platform to deliver, customize, and deploy Service-Oriented Architecture (SOA) composite business services (CBSs).

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Using selectors
• Using business rules
• Other options to consider
• Issues and best practices
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers