Creating flexible service-oriented business solutions with WebSphere Business Services Fabric, Part 2: Extending the ontology models

Learn how you can leverage the features of WebSphere® Business Services Fabric to build composite business applications that support dynamic binding and orchestration. In Part 2, you'll learn how to model the variability points in the business process as ontology extensions using the Fabric Modeling Tool.

Share:

Naveen Balani (banaveen@in.ibm.com), Development Manager, IBM

Naveen Balani photoNaveen 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.


developerWorks Master author level
        3

Rohit Sardesai (rohitsardesai@in.ibm.com), Software Engineer, IBM

Rohit Sardesai photoRohit 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 (viraviku@in.ibm.com), Software Engineer, IBM

Ravi Vishwakarma           photoRavikumar 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.



Manojkumar Pal (palmanojkumar@in.ibm.com), Software Engineer, IBM

Manojkumar Pal photoManoj 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 (msanchez@us.ibm.com), Senior Technical Staff Member, IBM

Matt Sanchez photoMatt 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.



25 June 2008

Also available in Chinese

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:

Table 1. Auto loan procurement system use case elements
Use case elementDescription
Auto loan procurement systemProcesses loan request for user
Use case descriptionThe user submits a loan request to purchase an automobile.
Primary actorAny user
Basic flowCredit verification and license verification is successful, loan is approved with varying interest rates.
Alternate flowsCredit verification or license verification fails. The loan request is rejected.

Implementing the auto loan process

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

Figure 1. Flow chart for the auto loan procurement system
Flow chart 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.

Figure 2. A business process enabled with dynamic binding and orchestration
A business process enabled with dynamic binding and orchestration

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:

Figure 3. Simplified business process
Simplified business process

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
    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
    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
    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
    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)
    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
    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
    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
    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
    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
    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
    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
    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
    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
    Figure 17. Run the glossary transformation

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 ClassEnumeration InstanceEnumeration Instance Value
    StateBasedEnumeration StateBasedEnumerationInstance:CACA
    StateBasedEnumeration StateBasedEnumerationInstance:TXTX
    CustomerTypeEnumerationCustomerTypeEnumerationInstance:GoldGold
    CustomerTypeEnumerationCustomerTypeEnumerationInstance:SilverSilver
    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
    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
    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
    Figure 20. Apply stereotypes to the state attributee
  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
    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:

Figure 22. Completed ontology model
Figure 22. Completed ontology model
Figure 23. Completed ontology model (2)
Figure 23. Completed ontology model (2)

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
    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
    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
    Figure 26. The generated OWL file

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.


Downloads

DescriptionNameSize
Project containing the modelAutoLoanModel.zip95KB
Fabric content archive containing the assertionsAutoLoanAssertionsFCA.zip4KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere, SOA and web services
ArticleID=315851
ArticleTitle=Creating flexible service-oriented business solutions with WebSphere Business Services Fabric, Part 2: Extending the ontology models
publish-date=06252008