Introduction

Part 2 of this series describes the requirements of the application that we're going to build and deploy in WebSphere Process Server V6.1 to interact with WebSphere Business Services Fabric (hereafter called Fabric). The application simulates an auto loan procurement system that accepts user information and responds with approval or rejection of the loan request. You'll learn how to build ontology extensions to capture the points of variability in a business process and enable dynamic binding, in which the service endpoint is discovered dynamically at service invocation.

Fabric eliminates the need for hard-coded static binding of services and provides late binding of services to enable more generalized process models. With Fabric, you can define an abstract business process and capture the process variability points in business policies that govern the run-time behavior and insulate process from changes. Fabric makes it possible to dynamically change the behavior of business processes in order to respond effectively to changing business needs.

Prerequisites

In order to complete the steps in this article, you'll need the following:

• Rational® Software Architect V7 with the following features installed:
  • Extensibility features (all features except the Reusable Asset Specification)
  • WSDL and XSD modeling and transformations
• IBM® Business Services Fabric Modeling Tool
• Fabric Business Glossary and Fabric Ontology Profiles (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 the use case

In future parts in this series, you'll develop a composite business application that simulates an auto loan procurement process. When a user submits a request for loan, it will be processed by the system, which will perform the following tasks:

• Credit verification
• License verification
• Loan provisioning

Table 1 describes the key elements of the use case:

Implementing the auto loan process

Figure 1 illustrates the flow for the auto loan procurement system.

As illustrated in Figure 1, the auto loan process needs to integrate with various third-party service providers, like LicenseVerificationService and LoanProviderService. The third-party service providers expose their functions as Web services.

As you implement the auto loan procurement process, you would typically use various if...else conditions in your business process, as shown in Figure 1, and hard-code the services bindings, which would make your process rigid and less adaptable to change. If you look at the auto loan procurement business process in Figure 1, you can see that there are various points of variability involved in the process:

• Depending on the time of day, different endpoints (CreditCheckService DayEP or CreditCheckServiceNightEP) need to be invoked to provide the credit verification service.
• Depending on a customer's location (California or Texas), different endpoints(LicenseVerificationCAEP or LicenseVerificationNonCAEP) need to be invoked to provide the license verification service.
• Depending upon the customer type (Gold or Silver), different endpoints (LoanProviderGoldEP or LoanProviderSilverEP) need to be invoked to provide the loan to the customer with different response times.

As the number of service and process variability points starts to grow, managing your business process using the approach described above becomes tedious and reduces flexibility. Incorporating changes into the process requires the developer to update and redeploy the business process. For instance, suppose the auto loan business process now requires that you need to serve a new category of customer, say Platinum, and that the response time to serve the platinum customer should be faster than the existing Gold and Silver customers. Incorporating this change requires another if...else construct in the business process to invoke a particular endpoint, say LoanProviderPlatinumEP, to satisfy the requirement, which requires changing the business process and redeploying it. Without a proper governance process in place, it's difficult to identify how this change might impact your business process.

Extending the Fabric core ontology model

In order to capture the points of variability in business policies and provide the context information for a business service, Fabric allows you to add capabilities (in the form of assertions) to service endpoints through extensions to the core ontology model. For instance, in the auto loan process, one of the aspects of context information for customer type would be Gold, Silver or Platinum. Fabric enables you to model your own extensions, load this context information into Fabric, and create business policies to deliver dynamic capabilities for your business service.

This rest of this article explains how to extend the core Fabric Model and incorporate these capabilities. Figure 2 summarizes explains how various Fabric modules interact with each other and with the business process.

Back to top

Creating new assertions

Assertions are characteristics that describe the capabilities of an endpoint. You can extend the industry ontology to add assertions that are custom to your enterprise IT environment. At run-time, the WebSphere Business Services Dynamic Assembler (hereafter called Dynamic Assembler) uses these assertions to find the best-suited endpoint or service realization for a consumer based on their business requirements. For more information about assertions, refer to the Websphere Business Services Fabric Version 6.1 Information Center.

To implement the auto loan process, we'll extend the content-based assertions defined in the Business Service Model, and build the following two new assertions:

CustomerTypeAssertion

• Description: Asserts the customer type that is supplied as part of the loan request.
• Point of variability : Customer type (Gold / Silver)
• Assertion Type: Fabric => Assertions => ContentBasedAssertion
• Use Case: Used by the Dynamic Assembler for endpoint selection. Supplied as a part of the context, this assertion drives the Dynamic Assembler to choose a particular loan provider service based on the customer type.
• Referenced Taxonomy: N/A

StateBasedAssertion

• Description: Asserts a location that is supplied as part of the loan request.
• Point of variability : Customer's location (California or Texas).
• Assertion Type: Fabric => Assertions => ContentBasedAssertion
• Use Case: Used by the Dynamic Assembler for endpoint selection. Supplied as a part of the context, this assertion drives the Dynamic Assembler to choose a particular license verification service implementation based on the customer's location.
• Referenced Taxonomy:N/A

We'll also use the Hours of Operation assertion, defined in the Fabric core ontology model, which is used by the Dynamic Assembler to select different endpoints depending on the time of the day. This assertion takes care of the Time of day point of variability in our business process. Depending on the time of the day , the appropriate endpoint for credit verification will be invoked by the Dynamic Assembler.

As you can see, you can handle all the points of variability in the auto loan process by leveraging the features of Fabric. Figure 3 shows the simplified business process:

Back to top

Building the ontology extensions

Now let's look at how to model the assertions that we identified above using the IBM Business Services Fabric Modeling Tool. The modeling tool is available as a plug-in to Rational Software Architect, and is used for extending the ontology.

Creating the glossary model

To create the glossary model, complete the following steps:

1. Select File => New => Project => UML Project to create a new UML modeling project.
2. In the UML Modeling Project dialog, specify AutoLoanExtensions as the Project name, check Use default location, and check Create new UML model in the project, as shown in Figure 4, then click Next.
   
   Figure 4. Create the modeling project
   
   
   
3. In the Create a New UML Model dialog, shown in Figure 5, specify AutoLoanExtensionsModel as the File name of the model, uncheck Create a default diagram in the new model and click Finish?.
   
   Figure 5. Create the UML model
   
   
   
4. Open the project and select the Details tab. Click Add in the Applied Profiles section.
5. In the Select Profile dialog, shown in Figure 6, select Profile in Workspace and click Browse, then select WBSFBusinessGlossaryProfile.epx, and click OK.
   
   Figure 6. Add the business blossary profile
   
   
   
6. To create a package called glossary, which will hold the required extensions, right-click AutoLoanExtensionsModel and select Add UML => Package.
7. Open the Main diagram by double-clicking Main under Glossary.
8. Right-click on Main diagram and select Add UML => Class, and create a new class called StateBasedEnumeration.
9. Open the Properties view for the StateBasedEnumeration class, and select Stereotypes, then click Apply Stereotypes, as shown in Figure 7.
   
   Figure 7. Apply stereotypes to the glossary package
   
   
   
10. Check Glossary Term, then click OK, as shown in Figure 8.
    
    Figure 8. Apply stereotypes to the glossary package (2)
    
    
    
11. In the same way, create a new class called CustomerTypeEnumeration and apply the Glossary Term stereotype.

Creating the ontology model

To create the ontology model, complete the following steps:

1. As in the previous section, create a new UML project called AutoLoanOntology that contains a UML model called AutoLoanOntologyModel. Make sure to uncheck the Create a default diagram in the new model option.
2. Open the project and select the Details tab.
3. In the Applied Profiles section, click Add.
4. In the Select Profile dialog, shown in Figure 9, select Profile in Workspace and click Browse, then select WBSFOntologyProfile.epx, and click OK.
   
   Figure 9. Add the ontology profile
   
   
   
5. Click Add in the Model Libraries section.
6. Select XSDDataTypes as the Deployed Library, and click OK, as shown in Figure 10.
   
   Figure 10. Add the XSD data type model library
   
   
   
7. Select AutoLoanExtensionsModel and select Add UML => Package, then create a package called ontology.
8. Apply the fabricNamespace stereotype to this package. as shown in Figure 11.
   
   Figure 11. Apply stereotypes to the ontology package
   
   
   
9. In the stereotype properties, as shown in Figure 12, specify autoloan-assertions as the directory, and as http://www.ibm.com/autoloan/assertions as the uri.
   
   Figure 12. Specify stereotype properties
   
   
   

Transforming the glossary terms

Next you need to transform the glossary terms you created, so that they can be used as OWL classes in the ontology model. To do this, you need to create a new glossary transformation configuration by completing the following steps:

1. Select Modeling =>Transform => New Configuration, as shown in Figure 13.
   
   Figure 13. Create new glossary transform
   
   
   
2. Select Fabric Transformations => Glossary Transformation.
3. Specify AutoLoanGlossaryTransform as the name, select AutoLoanOntology as the Configuration file destination, and click Next, as shown in Figure 14.
   
   Figure 14. Specify glossary transformation information
   
   
   
4. Select AutoLoanExtensionsModel as the source and AutoLoanOntologyModel as the target, as shown in Figure 15, then click Next.
   
   Figure 15. Select the source and target models
   
   
   
5. Specify ontology as the Target Package, as shown in Figure 16, and click Finish.
   
   Figure 16. Specify the target package
   
   
   
6. Run the transformation by selecting the transform icon as shown in Figure 17. Notice the OWL class definitions created in the AutoLoanOntologyModel project under the ontology package.
   
   Figure 17. Run the glossary transformation
   
   
   

Back to top

Modeling the ontology

Now you're ready to start building the ontology for the assertions.

1. Open the Main diagram for the AutoLoanOntologyModel.
2. Drag the StateBasedEnumeration and CustomerTypeEnumeration OWL classes from the ontology package onto the Main diagram
3. Select Fabric - Model -Stubs => Models => Core Ontology.
4. Drag the Enumerated Value class onto the Main diagram.
5. Create a Generalization directed from StateBasedEnumeration to EnumeratedValue.
6. Create a Generalization directed from CustomerTypeEnumeration to EnumeratedValue.
7. Create Instances for the following OWL classes:
   
   

   OWL Class	Enumeration Instance	Enumeration Instance Value
   StateBasedEnumeration	StateBasedEnumerationInstance:CA	CA
   StateBasedEnumeration	StateBasedEnumerationInstance:TX	TX
   CustomerTypeEnumeration	CustomerTypeEnumerationInstance:Gold	Gold
   CustomerTypeEnumeration	CustomerTypeEnumerationInstance:Silver	Silver

   
   
   We'll use these OWL class definitions to create our assertions.
8. Create a class called StateBasedAssertion. Apply the following stereotypes to this class. as shown in Figure 18:
   • fabricAssertion
   • owlClass
   • rdfs:label
   Specify the rdfs:label as State Based Assertion.
   
   Figure 18. Apply stereotypes to the StateBasedAssertion
   
   
   
9. Expand the Fabric-Model-Stubs project and drag the ContentBasedAssertion owlClass from the Policy Assertion Ontology onto the Main diagram, as shown in Figure 19.
   
   Figure 19. The ContentBasedAssertion defined in the PolicyAssertionOntology
   
   
   
10. Create a generalization directed from StateBasedAssertion to ContentBasedAssertion.
11. Add an attribute to the StateBasedAssertion class called state of type xsd:string.
12. Apply the following stereotypes to the state attribute, as shown in Figure 20:
    • fabricAssertedProperty
    • owl:DatatypeProperty
    • owl:FunctionalProperty
    • rdfs:label
    
    
    Figure 20. Apply stereotypes to the state attribute
    
    
    
13. Scroll to the Stereotype Properties section and specify the following. as shown in Figure 21:
    • assertionPropertyComparator: EqualsComparator
    • controlWidget : ReferenceSelect
    • label: State
    
    
    Figure 21. Specify the stereotype properties for the state attribute
    
    
    
14. Create a directed association from the StateBasedAssertion to StateBasedEnumeration. Provide the label as state , and apply the fabricEnumeratedProperty stereotype to it.
15. Repeat steps 6-11 to create a CustomerTypeAssertion. Specify Customer Type Assertion as the label for the assertions. Add the customerType attribute to the class, with the rdfs:label property as Customer Type.

Figure 22 and 23 show the completed modeling diagram:

Transform the ontology model

Now you need to transform the ontology model that you created into the actual OWL files by doing the following:

1. Select Modelling => Transform =gt; New Configuration.
2. Select Fabric Transformations => OWL Transformation.
3. Specify AutoLoanOntologyTransform as the name, select OWL Transformation, and specify /AutoLoanOntoloyt as the Configuration file destination, then click Finish, as shown in Figure 24.
   
   Figure 24. Configure ontology transformation
   
   
   
4. Select Auto Loan Ontology Model as both the source and target, as shown in Figure 25, then click Finish.
   
   Figure 25. Specify the source and target models
   
   
   
5. Run the transformation. The OWL transformation configuration runs the transformation logic to produce the necessary OWL constructs. The generated OWL file, shown in Figure 26, can be bundled as a Fabric Content Pack archive, or FCA file, and imported into the Fabric Governance Manager.
   
   Figure 26. The generated OWL file
   
   
   

Back to top

Summary

This article described the use case and requirements of the composite business process that you'll implement in the subsequent parts. You learned about the business process's variability points and modeled those variability points as ontology extensions to the IBM Business Service Fabric Model using the Fabric Modeling tool. You now have a set of metadata defining the points of variability in the business process. Fabric can use this metadata for dynamic endpoint selection.

Back to top

Downloads

Information about download methods

Resources

• Creating flexible service-oriented business solutions with WebSphere Business Services Fabric, Part 1: Overview (developerWorks 2007): Part 1 of this series describes the concepts of business services and composite business services and how Business Services Fabric provides an SOA platform to model, assemble, deploy, manage and govern composite business services.
  
  
• WebSphere business process management zone: Get the latest technical resources for WebSphere BPM solutions, including articles, tutorials, events, downloads, and more.
  
  
• Business Process Management enabled by SOA: Get complete product information on IBM BPM software, including features and benefits, downloads, and more.
  
  
• The future of the Web is Semantic (developerWorks 2005): Learn how organizations can leverage ontology-based development.
  
  
• OWL: Get more information on Web Ontology Language.
  
  
• WebSphere Business Services Fabric product information: Get product information, including features and prerequisites.
  
  
• Service Component Architecture (SCA): Get information and the specification for SCA, a technology that simplifies application development and implementation in an SOA.
  
  
• WebSphere Business Process Management Version 6.1 information center: Get complete product documentation for WebSphere BPM products.
  
  
• Getting Started with IBM WebSphere Business Services Fabric V6.1: This IBM Redbook provides a complete overview of Fabric, from an architectural introduction, to an installation guide, and a step-by-step scenario that describes how to model, assemble, deploy, and manage composite business applications.
  
  

About the authors

Naveen Balani works as an Software Architect on WebSphere Business Services Fabric. He likes to research upcoming technologies and is a regular contributor to IBM developerWorks, covering such topics as Web services, ESB, JMS, SOA, architectures, open-source frameworks, semantic Web, J2ME™, persuasive computing, the Spring series, AJAX, and various IBM products. He is also a co-author of Beginning Spring Framework 2 (Wiley, 2008) and the IBM Redbook Getting Started with IBM WebSphere Business Services Fabric V6.1.

You can reach Naveen at naveenbalani@rediffmail.com.

Rohit Sardesai works as a software engineer in the IBM India Software Lab, in Mumbai. He is part of the IBM WebSphere Business Services Fabric team. You can reach Rohit at rohitsardesai@in.ibm.com.

Ravikumar Vishwakarma is a software engineer in the IBM India Software Lab, in Mumbai. He is part of the IBM Websphere Business Services Fabric team. You can reach Ravikumar at viraviku@in.ibm.com.

Manoj Pal is a software engineer in the IBM India Software Lab, in Mumbai. He is part of the IBM Websphere Business Services Fabric. You can reach Manoj at palmanojkumar@in.ibm.com.

Matt Sanchez is an IBM Senior Technical Staff Member and Chief Architect for WebSphere Business Services Fabric. Matt is responsible for the architecture and technical direction of IBM’s industry SOA accelerators, including WebSphere Business Services Fabric and the Industry Content Packs. He works closely with technical leaders across IBM and with clients to help shape the future of IBM's SOA products and solutions.

You can reach Matt at msanchez@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Creating new assertions
• Building the ontology extensions
• Modeling the ontology
• Summary
• Downloads
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers