Defining Business Services

Websphere Business Services Fabric v7.0
Contact us...

1. Defining Business Services (2)
1. Pre-requisites
2. Define Business Services ()
1. Guidelines for adding Business Services
2. Guidelines for adding Business Services variations
3. Guidelines for adding ing Business Services  policies
1. Business policy example
2. Credit Check default
3. Internal Credit Check by Default
4. Premium Credit Check Requirement
2. Related links

Defining Business Services (2)

The core building blocks of composite business applications are business services. Business services are also considered coarse grain Web services that represent business functions, transactions, or processes that are made available over an internal or external network. A business service represents a discrete business function and provides an abstract representation for a designer of composite business applications, while also providing a separation of concern between the business function and the implementation that supports it. A business service is not a technical service by definition and use. When you consider a technical service, such as say a Web-service, obvious characteristics are present, such as the operations that are provided, the port types that are supported, and binding information. In contrast, a business service addresses the remainder of the information that is necessary to place the service in context and apply it correctly, such as service availability, user entitlements, lines of business supported, and its relationship to other services.

A business service represents a business function that can be composed with other business services to create a solution. 

A business service encapsulates one or more process variations. A process variation represents a distinct implementation approach for a business service. Policies can then be created that define which variation to use at runtime based on the business context surrounding a given invocation of the process.

Business services are designed to be reused in more than one process. At a bank, several different processes may involve the business function of underwriting. Instead of being forced to model, assemble, deploy, and manage this function in every such process, it is possible to re-use a business service and manage business or process-specific differences in how it should function with policies.

Also, when a new way of doing business needs to be introduced, such as rolling out an automated or out-sourced approach for an inhouse human-centric function, it is easier to model, assemble, and deploy a new variation than it is to go back to the drawing board for every process to work in the new decision logic. In this chapter, we will follow Loretta as she defines the four business services that will be used for Auto Loans Origination at Better Financials. Defining a business service involves listing the known process variations, modeling the inputs and outputs of the business service using vocabulary concepts, and defining business service policies.

Pre-requisites

1. Start WID.
2. Start the server (Websphere Dynamic Process Edition Server v7.0) ().
   Right-click the server and select Start.
3. Launch Business Space ().
   After the server starts successfully, right-click the server and select Launch\Business Space.
4. Log-in window().
   After you launch the business space, a log-in window appears.  Enter your userID and password and click Login.
5. Space Manager window ().
   In the Space Manager window, click the Loans Origination Authoring Space.

Define Business Services ()

Add the following business services, variations, and policies using the guidelines below.

Business Service Name/Description	Input/Output Name/Business Concept	Business Service Variations	Business Service Policies WHEN (No conditions, click to add), THEN (No results, click to add)
Check Credit - Automated Credit check	Input loanApplication/Loan Application Output loanApplication/Loan Application	Automated Credit Check	Name: Credit Check default  () Description:   FOR: Check Credit WHEN: THEN:Select Automated Credit Check in Check Credit Name: Internal Credit Check by Default () Description: Policy sets the internal credit check service as the default. Applications can override this to go to a third-party service FOR: Check Credit WHEN: THEN:Set Credit Check Type to Internal Name:  Premium Credit Check Requirement () Description: FOR: Check Credit WHEN:Amount of Loan is greater than 25,000 THEN:Set Premium Credit Check to True
Final Review - Review loan risk and decide whether to approve or reject the loan ()	Same as above	Automated Underwriting Human Underwriting	Name: Final Review Default () Description: FOR: Final Review WHEN: THEN:Select Human Underwriting in Final Review
Notify Customer - Notify customer of the status of the loan ()	Same as above	Automatic Notification Human Notification	Name: Notify Customer Default () Description: FOR: Notify Customer WHEN: THEN:Select Automatic Notification in Notify Customer
Review Collateral - Review collateral information to ensure coverage of the loan ()	Same as above	No Collateral Review Human Collateral Review	Name: Review Collateral  () Description: FOR: Review Collateral WHEN: THEN:Select Human Collateral Review in Review Collateral

Guidelines for adding Business Services

1. In the Getting Started window (), click Start working with business services
2. In the Business Service Browser window, click on the “Actions” button and select “New Business Service” ()
   
3. Enter the following details and click OK()
1. Name: Check Credit
2. Description: Automated Credit check
   
4. In the Business Service Browser window, click on Check Credit link to open the Business Service details page ()
   
5. In the Business Service Details window, click Edit to make changes ()
   
6. To add inputs and outputs, click the “add” link to the right of the “Business Service Inputs and Outputs” header ()
   
   The inputs and outputs of a business service are concepts from the vocabulary that represent the data flowing into and out of the business service. These settings are useful in the following ways:
   
   
1. The inputs and outputs serve as documentation about the key business domain values that will be available as input to a business service and that are available as output.
2. The inputs are used to determine the set of concepts that are available when crafting policies. Since policies only support concepts that represent a simple data value, the system will traverse the ”has” relationships of an object concept to determine the data items that will be available at runtime.

When imported into Modeler, vocabulary concepts are converted into Business Items that are represented as the business inputs and outputs for the process flows that are created to represent each process variation. If the Modeler export to WID is used, these business items will ultimately be converted to the service interfaces available in that environment.

To keep things simple, we will use our Loan Application object concept that we already created as the input and output of every business service we will create for the loans origination process.


7. Fill in the Values for the Business Service Inputs and Outputs ()

1. Click and set the values as shown:
   

   Input/Output Name (Click to set a name for this input or output)	Business Concept (Click to choose a business concept)	Input/Output
   loanApplication	Loan Application	input
   loanApplication	Loan Application	output

2. Click on Click to choose a business concept, select Loan Application in the “Select Input or Output Type” dialog box and then click “OK” ().
3. Click Save to save your work.
   
4. The completed Input and Outputs should look like this ().

Guidelines for adding Business Services variations

A business service encapsulates one or more process variations. A process variation represents a distinct implementation approach for a business service. Policies can then be created that define which variation to use at runtime based on the business context surrounding a given invocation of the process.

For example, in our scenario, underwriting is one of the high-level steps that make up the process for auto loans origination. Based on the loan amount for a given loan application, we want to select between an automated fast-track underwriting or more expensive manual processing. Instead of hard-coding the branching logic in our loans origination process, we represent this step in our application flow simply as an underwriting task and define the logic about which variation to use with policies.

1. Add a service variation ()
   For the Check Credit business service, we will only create a single variation to represent an automated credit check. Add a variation by clicking the “add” link next to “Business Service Variations”.
2. In the Create New Business Service Variation window, enter "Automated Credit Check" (Name) and click OK ()
   
3. Service variation created ()
   

Guidelines for adding ing Business Services  policies

From a technical perspective, policies are required to determine which process variation to use at runtime.  Thus, if a business service only has a single process variation, then policies are not required.  However, you can still set up policies to provide values to be used by a process variation.

Policies define the business requirements that have to be met when a consumer requests a service. 

A policy is a set of assertions that represent requirements, constraints or capabilities for a business service. For example, "A Business Service must use HTTP or HTTPS as a medium of communication" is the example of a policy.

A policy consists of three sections (review Getting Started with IBM WebSphere Business Services Fabric V6.1 for further details)

1. The context of service request
   Describes the operating context of the CBA or business service, such as which role is instantiating the request, over which channel, at what time of day, or day of year, and so on.
   
2. The request itself
   Describes information that is available in the data objects that are particular to this instantiation, for instance, if the Loan Application CBA were invoked, it would be important to know if the request was for a home loan or an automobile loan. The content of the invocation messages typically contain this data.
   
3. The requirements that have to be met
   Describes the capabilities, restrictions, and preferences for a CBA or business service. The contract is defined at runtime and is a combination of the metadata and policies that are relevant for the particular circumstances.
   

In this section we'll create our first Business Service Policy to establish a default process variation for the Credit Check business service. Policies have a “FOR – WHEN—THEN” syntax.

The FOR clause, or scoping statement, associates or scopes the policy to an element of our loans process. In this case, “FOR Check Credit” says that this policy will be considered whenever the Check Credit business service is invoked. Note that the scoping statement does not restrict the policy to any given application. Policies created at the business service level will be considered wherever the business service is used. In the next chapter, we'll discuss application-scoped policies which will be specific to our Loans Origination process.

The “WHEN” clause (optional) expresses the business situation in which a policy should apply. The policy editor lets the user construct a Boolean expression expressed in terms of vocabulary concepts. These concepts will be limited to those that are represented as inputs of the business service indicated in the scoping statement.  The WHEN clause does not have to contain any condition, in which case the THEN clause is always done.

The “THEN” clause represents what should happen when the condition represented by the “WHEN” clause is satisfied. There are two different kinds of results that can be specified. First, a result can determine which process variation should be selected. Second, a value for a vocabulary concept can be established as a business parameter that controls how the selected variation should behave.

Each time a business service is invoked, the system will determine all of the policies that apply and merge them into a single composite policy. This policy is then used to establish which variation of the business service to select and what business parameters are established for that invocation of the business service. These parameters are designed to be consumed by the technical implementation of a variation to affect the behavior of the business service.

Business policy example

Review Getting Started with IBM WebSphere Business Services Fabric V6.1 for further details.

Let us examine a few example policies so that we can clearly see how they would be represented and applied within Fabric. Earlier, we used the example of a Loan Rating Service, and we articulated a simple business policy that all home loan applications that are greater than or equal to 500k are considered Luxury loan products, and loans less than 500k are standard loan products. Our scenario has two loan rating services, one for standard loans and one for luxury loans.

This business policy looks like:

1.   PolicyName - LuxuryLoan
1.     Context - Loan application
2.     Content - Loan application amount greater than or equal to 500k, and loan type is Home
3.     Contract - Loan product is Luxury
2.   PolicyName - StandardLoan
1.     Context - Loan application
2.     Content - Loan application amount is less than 500k, and loan type is Home
3.     Contract - Loan product is Standard

This model easily articulates the business policies that are necessary to describe a Luxury and a Standard loan, effectively and declaratively expressing the business intent.

Another example we used was the XtraBigLoan, where the business made a decision to outsource the underwriting of home loans over 900k to a third party. These loans are considered XtraBigLoan Products.

This business policy looks like:

1.   PolicyName - XtraBigLoan
1.     Context - Loan Application
2.     Content - Loan application amount greater than 900k, and loan type is home
3.     Contract - Loan product is XtraBig

The business could decide that certain customer loans will remain in house regardless of the loan amount. The policy might state that all premium customers use standard or luxury loan products.

Two business policies would easily represent this business policy:

1.   PolicyName - Preferred Customer Standard Loan
1.     Context - Loan Application and Customer are Preferred
2.     Content - Loan application amount less than 500k, and loan type is Home
3.     Contract - Loan product is Standard
2.   PolicyName - Preferred Customer Luxury Loan
1.     Context - Loan Application and Customer are Preferred
2.     Content - Loan application amount greater than or equal to 500k, and loan type is Home
3.     Contract - Loan product is Luxury

Additional metadata can also become associated with a business policy, such as an effective date or expiration date, for instance, say the use of third-party provider XtraBigLoan is not effective until January 1st, 2010. The policy effective date of 01/01/2010 is updated, and now this policy is not considered until the specified date.

This XtraBigLoan policy now looks like:

1.   PolicyName - XtraBigLoan
1.     Context - Loan Application and calendar date greater than or equal to 01/01/2001
2.     Content - Loan application amount greater than 900k, and loan type is Home
3.     Contract - Loan product is XtraBigloan

The following are the detailed steps you may use to add the above policies:

Credit Check default

1. Add a new policy by clicking the “add” link to the right of the “Business Service Policies” header ()
   
2. Fill-in Policy details () and click OK.
   Name: Credit Check default
   Description: None. 
   
3. Edit the policy by clicking the Edit button at the top of the details area ()
   
4. Add a Then clause by clicking the “(No results, click to add)” link ()
   
5. Create Result ()
   In the Create Result window, Select the Select a process variation radio button, and make sure the “Automated Credit Check” variation is selected in the dropdown. Click “OK” to create the result.
   
   This policy says that whenever the check credit business service is invoked, it should use the “Automated Credit Check” variation. Since this is the only variation in existence, the policy is not strictly necessary, but it is a good practice to define a default variation for a business service.
   
6. This is the completed policy ()
   
7. Click Save to save the new policy ()
   

Internal Credit Check by Default

The business wants to use policies to control whether a given request will perform a credit check by utilizing an internal backend service that takes advantage of the banks internal customer credit records, or whether it should spend the money to utilize a third—party service from one of the credit agencies. In the last chapter, the Credit Check Type concept was introduced to represent that the concept of INTERNAL vs. THIRD-PARTY credit checks.

Let's assume that there is a higher cost associated with using one of the credit agencies, but it is known for providing higher quality credit reports. The business wants to optimize their use of the more expensive, yet higher quality service. The Premium Credit Check concept was introduced so that it could also be used as a parameter to influence the behavior of the Automated Credit Check variation.

1. Create a new policy
   Name: Internal Credit Check by Default
   Description: Policy sets the internal credit check service as the default. Applications can override this to go to a third-party service
2. Edit the policy and fill in the following THEN clause ()
1. Select Assign a value to a concept radio button
   
2. In the Concept Search, select Credit Check Type and click on the Select Concept button
3. In the Value drop-down list, select Internal as the Value.
   
4. Click Ok.
5. Click Save.
3. This is the completed policy ()
   

Premium Credit Check Requirement

Let's create another policy that establishes when to flag a request for a Premium Credit Check. The business decides that the loan amounts greater than $25,000 warrant the added scrutiny.

1. Create a new policy
   Name: Premium Credit Check Requirement
   Description: Not applicable
2. Add a “When” clause by clicking the “(No conditions, click to add)” link ().
   In the Create Condition window, fill-in the following details and then click Ok ():
   Field Name:  Amount of Loan
   Comparator: is greater than
   Value:          25,000
3. Fill in the Then clause Results ()
   
1. Select Assign a value to a concept radio button
   
2. In the Concept Search, select Premium Credit Check and click on the Select Concept button
3. In the Value drop-down list, select True as the Value.
   
4. Click Ok.
5. Click Save.
4. This is the completed policy ()

Related links

1. Previous: Author a Vocabulary Next: Define Application and Policies
2. Modeling, developing, assembling, deploying and managing an application
3. Working with the Fabric templates in Business Space
4. Business Space Information Center
5. Getting Started with IBM WebSphere Business Services Fabric V6.1

6. IBM WBS Fabric Learning Resources