IBM recently released IBM WebSphere Process Server (Process Server) V6.0, which is based on the new Service Component Architecture (SCA). In this article you'll learn to develop an integration application using the tooling piece of Process Server, WebSphere Integration Developer (Integration Developer) V6.0.
Integration Developer runs within the IBM Rational® Application Developer (RAD) or Rational Software Architect (RSA) environment. When using Integration Developer, it is important to be familiar with the Business Process Execution Language (BPEL). Like IBM WebSphere Business Integration Server Foundation 5.1.1 (Server Foundation), Process Server comes with a business process container that manages and executes BPEL processes.
It's very helpful to understand the concepts of SCA when using Integration Developer. Briefly, SCA is a Service-Oriented Architecture (SOA) development abstraction that cleanly allows you to initially define components in a technology-neutral manner, define interfaces and dependencies, and then provide implementations. Several types of components are packaged together as an SCA module.
You can use the basic top-down approach to develop your module in Integration Developer, outlined here. (Not all of these steps are covered in this article.)
- Build your components
- Create components
- Create business objects
- Define interfaces for your components
- Import interfaces from existing services
- Wire components together
- Implement your components
- Bind import components to services
- Develop your BPEL processes
- Define human tasks
- Create business rules
- Generate and test your code
- Deploy code
- Test module using WebSphere Business Process Choreographer Explorer
- Export and install your application on a production WebSphere Process Server
To illustrate these steps, we'll use a simple insurance claim scenario described in the next section.
Using the insurance claim scenario
In this article, you learn the simple business process for creating an insurance claim, where customers submit a form for a claim on an insurance policy, such as auto insurance. A complete insurance claim business process can involve many activities, such as creation of the claim record, assessing the damage, settling the claim, and so on. In this article, we focus on only one aspect: creation of the claim record after the application is submitted.
The creation of a claim record involves:
- Validating the customer information
- Validating their insurance policy
- Assigning an insurance adjuster
- Creating a claim record for this application
The record that is created is used later by downstream activities in the business process (which are not covered in this article).
Meanwhile, an e-mail notification is sent to the customer if the application is disapproved, with a message explaining the reason for the disapproval, such as
expired insurance policy.
Our scenario does not include any human task activity. This and other advanced features of Integration Developer will be discussed in a forthcoming article.
To support our scenario, there are three Web services already available:
- The CRM Web service provides services related to customer information.
- The Policy Web service provides services related to insurance policies.
- The Claim Web service provides services related to the creation and processing of a claim record.
Creating your module and components
We're ready to start writing our SCA module using Integration Developer. The first step is to create a module project in the Integration Developer Business Integration perspective. Figure 1 shows how to create the CreateClaimModule module.
Figure 1. Creation of a new module
A module is composed of elements that define both its data and behavior. After the module is created, a structure similar to the one shown in Figure 2 is displayed. It contains elements such as processes, business objects, interfaces, business rules, and so on.
Figure 2. Structure of a module
Following the top-down approach, the next step is to create the components for the module using the Assembly Diagram editor. The Assembly Diagram shown in Figure 3 lets you create components using the palette on the left side and then assemble them together. The figure is annotated with some examples of component types. Other components not shown include: Import, Export, Stand-Alone Reference, Interface Map, Selector, and Wire.
Figure 3. The Assembly Diagram and editor
To create a component, simply drag and drop an icon from the palette onto the diagram, then label it with a name. For our insurance claim scenario, we only need four types of components, shown in Figure 4:
- Process
- Allows us to implement our business logic using BPEL
- Import
- An abstraction of a service that is available outside of the SCA module we are creating (An example is our CRM Web service. In our scenario, all of the Import components are calls to our three supporting Web services.)
- Business Rule
- Allows us to express business logic using rules (more on this later)
- Stand-alone Reference
- A special component that serves as an entry point for external non-SCA clients, such as JavaServer Pages (JSP) clients to call the services provided by our SCA module
Figure 4. Labeled components used for the insurance claim scenario
Defining business objects and interfaces
Components interact and reference one another. To be able to do so, a component has to have a well-defined interface. An interface is a collection of operations with well-defined input and output parameters. An operation can be asynchronous or synchronous. An interface can be expressed either as a traditional Java™ interface or Web Services Description Language (WSDL). For our scenario, we use WSDL for all of our interfaces.
We define interfaces for non-import components such as Process or Business Rules components.
For these interfaces, some parameter data types may be non-primitive or complex. In SCA, they are called business objects.
They are extensions of Service Data Objects (SDO) and, as a result, are manipulated in the same manner as SDOs. Business objects
required for defining an interface should be created first. In Figure 5 the Business object editor is showing the business object ClaimData that we've created.
Business objects can be composed of other business objects, such as
PolicyData in ClaimData.
Figure 5. Business Object editor
Now that the business objects are available, we can proceed with creating the interfaces.
Let's create an interface for our Process component. The Interface editor in
Figure 6 shows the definition of CreateClaimInterface,
which has only one operation called doCreateClaim.
The operation is synchronous, since it has both an input parameter of type ClaimData and an output parameter of type ClaimRecord. The
ClaimRecord business object contains only the field adjuster. The Create Claim process takes information about the claim and
returns the name of the assigned adjuster if the operation is successful.
Figure 6. Interface editor
As mentioned, not all interfaces must be created. Others are imported, such as our WSDL files for the three Web services.
This results in three imported interfaces called ClaimService, CRMService, and PolicyService.
Figure 7 shows some of the contents of the ClaimService interface, which also has only one operation called createClaim.
Figure 7. Imported interface example
Setting interfaces for components
When using the following steps, it is important to know exactly which interface to assign to which component. To make the assignment, simply click the component in the assembly diagram. Two icons appear on top of the component: the Interface icon and the Reference icon. Figure 8 summarizes how to assign an interface to a component.
Figure 8. Assigning an interface to a component
Click the Interface icon and a pop-up appears, showing you all possible interfaces that you can assign to this component. Choose the appropriate interface and select OK. After all components are assigned an interface, you should see something similar to the one shown in Figure 9. The respective assignments for our scenario are shown in Table 1.
Table 1. Component interface assignments for this scenario
| Create Claim Process | CreateClaimInterface |
| Validate Customer Info | CRMService |
| Validate Insurance Policy | PolicyService |
| Assign Adjuster | AssignAdjusterInterface |
| Create Customer Record | ClaimService |
| Send Explanation | CRMService |
Wiring the components together
You're now ready to wire the components together. Wiring is the process of assembling components to establish partnerships, references, or dependencies. The direction of the wire is important because it reveals the role of the two ends (which component is dependent or which one calls the operations of the other). Figure 10 shows a completely wired diagram for our insurance claim scenario.
Figure 9. All components with assigned interfaces
The wires do not reveal anything yet about the business logic; it is only a view of which component interacts with which other component. In our insurance claim scenario, we see that only the Create Claim Process component interacts with the imported and business rule components.
Figure 10. Completely wired insurance claim module
Our components are now ready to be implemented by filling in the details of the business logic. Recall that imported components represent services that are already implemented, so we only need to implement two components: Process and Business Rule.
Another required step for the imported components is to provide the necessary bindings. Figure 11 shows how to choose the type of binding to generate for the Imported component. These bindings are familiar except for SCA Binding, which is the binding you choose if you are importing another SCA module that has been exported previously. Our three Web services are regular Simple Object Access Protocol (SOAP)/HTTP services, so we choose Web Service Binding.
Figure 11. Generating the type of binding for an imported service
After choosing the Web Service binding, we need to set the end point, port, and service information of the Web service provider. Under the Properties > Binding tab, select Browse to choose the WSDL file in the local file system, which will fill in this information. Figure 12 shows an example. You'll need to perform this step for all of the imported components.
Figure 12. Filling in binding information for an imported service
Creating business rules for assigning insurance adjusters
The next step is to implement the Business Rule component, whose main task is to assign an insurance adjuster to the claim being created.
Double-click the component to view the diagram shown in Figure 13.
Each operation in the interface should have a corresponding rule or destination. That destination can be an existing rule or a new rule that must be created using the Rule editor.
In our case, we only have one operation: assignAdjuster. Right-click Destination, as shown in Figure 13, to create our rule. Notice there is no existing rule yet that we could potentially select.
The two possible ways to express rules are using a Ruleset or Decision Table. We chose to create a Decision Table for this operation.
Figure 13. Defining business rule implementation
A pop-up appears after clicking Decision Table, where you can give a name for the rule. A new diagram will show up where the Decision Table is created.
Figure 14 shows a simple and complete Decision Table. It uses two values from the input parameter, ClaimType and Location. Depending on their values, a specific adjuster name will be assigned through the output parameter field Adjuster.
Figure 14. Creating a Decision Table to implement a rule
The output field Adjuster is also configured so the values can be changed any time later, without having to shut down the running BPEL application. A browser-based interface is provided by the framework to allow you to customize the business rules after they are deployed.
Creating the BPEL process for Create Claim Process
Finally, we implement the Process component. Right-click the component and choose Generate Implementation, which brings you to the BPEL editor where you can freely drag and drop BPEL constructs. A sample implementation is shown in Figure 15.
A discussion of the BPEL editor is beyond the scope of this article.
Using the editor, we can formulate the business logic by showing when specific services by the reference partners are called.
Reference partners are created through the component wiring we have done previously.
In Figure 15 you see that the validateCustomer activity calls the operation validateCustomer of
the Imported Web service CRMService. The expected input parameter is assigned first through assign1 using the variable SSN.
Meanwhile, the return value is assigned to the variable CustomerRecord.
Figure 15. The BPEL editor
Generating your deployable module
So far we've created and assembled all the SCA components for our insurance claim scenario. We've also implemented the components using Web services bindings, business rules, and a simple BPEL process. Now you're ready to actually deploy and generate a Java 2 Platform, Enterprise Edition (J2EE) application for the insurance claim module.
Every SCA module is mapped to a complete J2EE application package, as shown in Figure 16. You can view this by switching to the J2EE perspective. We can generate the deployment code just like any other J2EE application. The Enterprise application file can be exported from the J2EE perspective using the regular method or from the business perspective as an integration module. By default, Rational Application Developer or Rational Software Architect is set to build the projects automatically, so the artifacts shown in Figure 16 are generated as you work on your SCA module.
Figure 16. J2EE artifacts for the
CreateClaimModule
The final stage of the entire process is to test the module that we just created. We highlight the Business Process Choreographer Explorer as a convenient tool for testing your modules, but you can also use the Universal Test Client (UTC) that comes with Integration Developer. The Business Process Choreographer Explorer can be launched directly from Integration Developer, as shown in Figure 17. The Business Process Choreographer Explorer manages BPEL process templates deployed in your server environment. You can create and run instances of process templates using the tool.
Figure 17. Launching the Business Process Choreographer Explorer from Integration Developer
Notice that the test server must be running to be able to run the Business Process Choreographer Explorer. Once loaded, the Business Process Choreographer Explorer shows a menu similar to that shown in Figure 18.
Figure 18. Business Process Choreographer Explorer main interface
In Figure 18, select My Process Templates to see all the available templates in our server.
Our scenario only has the CreateClaimProcess template (since Create Claim Process is a Process component implemented in BPEL).
Choose this template and click Start Instance, and you'll see an input panel for all the input parameters required by this template.
Remember that this is defined through the interface that we assigned for the Create Claim Process component. See Figure 19 for an example.
Figure 19. Input panel for CreateClaimProcess process instance
After entering some or all of the input fields, click Submit to start the processing. A successful run should give output just like that shown in Figure 20. The output is the adjuster assigned for this applicant (implying also that the Claim record was created). Since the applicant's location is North East and the claim type is Fire, Mr. C. Rogers is assigned as the adjuster, as indicated in our Decision Table.
Figure 20. Test output
In this article, you got a brief overview of the WebSphere Integration Developer tool. You learned some of the basic facilities that are available so you can start your own simple modules. And you discovered how to use Integration Developer to import services that are already available, create your services, assemble them, and formulate your business logic using BPEL.
The next article in this series covers more capabilities of IBM WebSphere Integration Developer, including human tasks, event monitoring through Common Event Infrastructure (CEI), testing a component in UTC, multiple process components, and installing and running the generated application into an external IBM WebSphere Process Server. Stay tuned!
| Description | Name | Size | Download method |
|---|---|---|---|
| Project interchange for insurance claim scenario | i-odoebp15code.zip | 108KB |
HTTP
 |
Download Director
|
Information about download methods
Learn
-
See the
WebSphere Process Server and WebSphere Integration Developer InfoCenter
for all the information you need on WebSphere Process Server and WebSphere Integration Developer.
-
"WebSphere Process Server: IBM's new foundation for SOA" (developerWorks, 2005): Read this article to find out about the WebSphere Process Server capabilities, features, solutions, and references to other resources.
- Business Process Execution Language for Web Services Version 1.1: Read the specification for BPEL4WS, which provides a language for the formal specification of business processes and business interaction protocols.
- New to SOA and Web services: Peruse the information here if you are new to Service-Oriented Architecture and Web services.
-
"Building SOA solutions with the Service Component Architecture, Part 1" (developerworks, October 2005): Discover the new programming paradigm for building Service-Oriented Architectures (SOA) called the Service Component Architecture (SCA), a new programming model designed specifically for building and assembling business solutions in an SOA and targeted for integrating and composing services.
-
"Introduction to Service Data Objects: Next-generation data programming in the Java environment" (developerWorks, September 2004): A good starting point to learn about next-generation data programming with Service Data Objects.
Get products and technologies
-
Download a trial version of
WebSphere
Application Server Version 6.0.
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
Dr. Wilfred Jamison currently works with the IBM On Demand Software Development team and is heavily involved with many projects pertaining to business innovation, optimization, and service-oriented architecture (SOA). His expertise also includes distributed systems, performance analysis, Web services, software agents, and others. He is heavily involved in the Tonawanda project and is currently looking into DataPower to extend the capabilities of this project. Contact Dr. Jamison at wjamison@us.ibm.com.
Comments (Undergoing maintenance)
Table of contents
- Introduction
- Using the top-down approach
- Using the insurance claim scenario
- Creating your module and components
- Defining business objects and interfaces
- Setting interfaces for components
- Wiring the components together
- Implementing your components
- Creating business rules for assigning insurance adjusters
- Creating the BPEL process for Create Claim Process
- Generating your deployable module
- Testing your module
- Conclusion
- Download
- Resources
- About the authors
- Comments
Next steps from IBM
- Try: Rational Application Developer for WebSphere Software
- Demo: Build, test and deploy JAX-WS Web services
- Webcast: Webcast: Develop innovative applications efficiently using the right application foundation in today's economy
- Briefing: Software development conference
- Buy: Rational Application Developer for WebSphere Software
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags