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.
In order to complete the steps in this article, you'll need the following:
- Rational® Software Architect V7 with the following features
- 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 element||Description|
|Auto loan procurement system||Processes loan request for user|
|Use case description||The user submits a loan request to purchase an automobile.|
|Primary actor||Any user|
|Basic flow||Credit verification and license verification is successful, loan is approved with varying interest rates.|
|Alternate flows||Credit 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
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
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:
- 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
- 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
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:
- Select File => New => Project => UML Project to create a new UML modeling project.
- In the UML Modeling Project dialog, specify
AutoLoanExtensionsas 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
- In the Create a New UML Model dialog, shown in Figure 5, specify
AutoLoanExtensionsModelas the File name of the model, uncheck Create a default diagram in the new model and click Finish?.
Figure 5. Create the UML model
- Open the project and select the Details tab. Click Add in the Applied Profiles section.
- 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
- To create a package called glossary, which will hold the required extensions, right-click AutoLoanExtensionsModel and select Add UML => Package.
- Open the Main diagram by double-clicking Main under Glossary.
- Right-click on Main diagram and select Add UML => Class, and create a new class called StateBasedEnumeration.
- 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
- Check Glossary Term, then click OK, as shown in Figure
Figure 8. Apply stereotypes to the glossary package (2)
- In the same way, create a new class called
CustomerTypeEnumerationand apply the Glossary Term stereotype.
Creating the ontology model
To create the ontology model, complete the following steps:
- As in the previous section, create a new UML project called
AutoLoanOntologythat contains a UML model called
AutoLoanOntologyModel. Make sure to uncheck the Create a default diagram in the new model option.
- Open the project and select the Details tab.
- In the Applied Profiles section, click Add.
- 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
- Click Add in the Model Libraries section.
- Select XSDDataTypes as the Deployed Library, and click
OK, as shown in Figure 10.
Figure 10. Add the XSD data type model library
- Select AutoLoanExtensionsModel and select Add UML => Package, then create a package called ontology.
- Apply the fabricNamespace stereotype to this package. as shown
in Figure 11.
Figure 11. Apply stereotypes to the ontology package
- In the stereotype properties, as shown in Figure 12, specify
autoloan-assertionsas the directory, and as
http://www.ibm.com/autoloan/assertionsas 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:
- Select Modeling =>Transform => New Configuration,
as shown in Figure 13.
Figure 13. Create new glossary transform
- Select Fabric Transformations => Glossary Transformation.
AutoLoanGlossaryTransformas the name, select AutoLoanOntology as the Configuration file destination, and click Next, as shown in Figure 14.
Figure 14. Specify glossary transformation information
- 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
ontologyas the Target Package, as shown in Figure 16, and click Finish.
Figure 16. Specify the target package
- 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
Modeling the ontology
Now you're ready to start building the ontology for the assertions.
- Open the Main diagram for the AutoLoanOntologyModel.
- Drag the StateBasedEnumeration and CustomerTypeEnumeration OWL classes from the ontology package onto the Main diagram
- Select Fabric - Model -Stubs => Models => Core Ontology.
- Drag the Enumerated Value class onto the Main diagram.
- Create a Generalization directed from StateBasedEnumeration to EnumeratedValue.
- Create a Generalization directed from CustomerTypeEnumeration to EnumeratedValue.
- Create Instances for the following OWL classes:
We'll use these OWL class definitions to create our assertions.
OWL Class Enumeration Instance Enumeration Instance Value StateBasedEnumeration StateBasedEnumerationInstance:CA CA StateBasedEnumeration StateBasedEnumerationInstance:TX TX CustomerTypeEnumeration CustomerTypeEnumerationInstance:Gold Gold CustomerTypeEnumeration CustomerTypeEnumerationInstance:Silver Silver
- Create a class called
StateBasedAssertion. Apply the following stereotypes to this class. as shown in Figure 18:
rdfs:labelas State Based Assertion.
Figure 18. Apply stereotypes to the StateBasedAssertion
- 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
- Create a generalization directed from StateBasedAssertion to ContentBasedAssertion.
- Add an attribute to the StateBasedAssertion class called
- Apply the following stereotypes to the
stateattribute, as shown in Figure 20:
Figure 20. Apply stereotypes to the state attribute
- Scroll to the Stereotype Properties section and specify the
following. as shown in Figure 21:
- controlWidget :
Figure 21. Specify the stereotype properties for the state attribute
- Create a directed association from the StateBasedAssertion to StateBasedEnumeration. Provide the label as state , and apply the fabricEnumeratedProperty stereotype to it.
- Repeat steps 6-11 to create a CustomerTypeAssertion. Specify
Customer Type Assertionas the label for the assertions. Add the
customerTypeattribute to the class, with the rdfs:label property as
Figure 22 and 23 show the completed modeling diagram:
Figure 22. Completed ontology model
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:
- Select Modelling => Transform =gt; New Configuration.
- Select Fabric Transformations => OWL Transformation.
AutoLoanOntologyTransformas the name, select OWL Transformation, and specify
/AutoLoanOntoloytas the Configuration file destination, then click Finish, as shown in Figure 24.
Figure 24. Configure ontology transformation
- 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
- 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
Figure 26. The generated OWL file
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.
|Project containing the model||AutoLoanModel.zip||95KB|
|Fabric content archive containing the assertions||AutoLoanAssertionsFCA.zip||4KB|
- 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.
Dig deeper into Business process management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.