Architecting on demand solutions, Part 17: Build a Hello World SOA application

Living the (SOA) life cycle -- model, assemble, deploy, and manage

Christina Lau (clau@ca.ibm.com), Senior Technical Staff Member, IBM Software Group

Christina Lau is a Senior Technical Staff Member at IBM. Christina is an architect on the On Demand Development team focusing on the next generation technologies for the On Demand Operating Environment. You can reach Christina at clau@ca.ibm.com.

Jim Bonanno (bonanno@us.ibm.com), Senior Programmer, IBM, Software Group

Jim Bonanno is a Senior Programmer working for the On Demand Development team. Jim was previously responsible for integrating the Jakarta Struts framework with the WebSphere Portal product. You can reach Jim at bonanno@us.ibm.com.

Summary: IT architects and developers are taking a life-cycle approach to Service-Oriented Architecture (SOA). IBM offers several enhanced products to support every stage of the SOA life cycle and to strengthen the SOA Foundation. But what are the practical steps you need to get started? In this article, the 17th in our series, you'll learn how to build your first Hello World SOA application.

View more content in this series

Tag this!

Date: 30 Jan 2006
Level: Introductory
Activity: 3936 views

Introduction

This 17th part in our series focuses on new products that let you implement a Service-Oriented Architecture (SOA) life cycle, shown in Figure 1. (See Resources for information on SOA.)

In the model phase, IBM WebSphere® Business Modeler (Modeler) is used to design and optimize the desired business processes through simulation. After the business process is designed, it is implemented by combining new and existing services using WebSphere Integration Developer (Integration Developer). The process is then deployed into WebSphere Process Server (Process Server). After deployment, you can manage the application from a business perspective using WebSphere Business Monitor (Monitor). Information gathered during the manage phase helps you gain real-time insight into business processes, enabling better business decisions and feeding information back into the life cycle for continuous process improvement.

Note: We've included a download containing the simple claim model that you can import into WebSphere Business Modeler. The download also contains the project interchange for WebSphere Integration Developer and the simple claim EAR file that can be deployed to the WebSphere Process Server. Click the Sample code icon to download these files.

Figure 1. The SOA life cycle
The SOA Lifecycle

Create the insurance claim process model

To illustrate the end-to-end SOA life cycle, we use a simple insurance claim scenario that shows the steps and highlights the touch points between the four products. A client submits an insurance claim request. Based on the estimated amount of the claim, the request is processed with either an express claim process or a high-touch process. The express claim process was explained in Part 16 of this series. The high-touch claim process is an old, manual process in operation for a long time.

First, you need to create the insurance claim process model. To create a process in WebSphere Business Modeler:

Create a business item that will contain the document for this process.
Use the New Business Item wizard to create a new ClaimData business item. You'll then add several attributes, as shown in Figure 2.

Figure 2. Create ClaimData business item
Create a SimpleClaim process.
From the Modeling Mode menu, select WebSphere Process Server. Drag a few local tasks onto the process model editor and connect them, as shown in Figure 3. Associate the ClaimData business item with each connection by using the Associate Data pop-up menu on the connection.

Figure 3. SimpleClaim process model

Define a branch condition

The Express process is used when the insurance estimate is less than $1,000. A simple condition is used in this process model to determine whether the insurance estimate will be more than $1,000. To specify the probability for each branch:

Select the decision element and scroll down to the Output branches tab in the Attributes window. Select the first branch, lowEstimate, as shown in Figure 4.
Figure 4. Define the probability of each branch
Enter the probability of the particular branch. For example, 30% is the current estimate for requests that are qualified for the express process. These probabilities are used by the process simulations in the Modeler. The transition condition is also used by the runtime. The Monitor calculates the probability percentage of the decision branch and feeds those data back to the Modeler for optimization.
At the bottom of the pane, select Edit to invoke the Expression Builder, shown in Figure 5. In the Expression Builder, select the attribute estimatedCost, the operator is less than, and enter the value 1000 as the numeric value to compare the estimatedCost to. Click OK to save this expression for the lowEstimate branch.
Figure 5. Use the Expression Builder to define the test condition

If you select the high estimate condition, notice that a default expression negating the low estimate condition is automatically generated for you.

Create business measures

To use WebSphere Business Monitor to monitor the performance of the business process, you must create a business measure model for the process. The business measure model defines the measurements that are used to access business performance and the expected targets. It also captures events that will trigger specific actions when the process runs.

To create a business measures model, select the Create Business Measures pop-up from the SimpleClaim process and create the business measures for each element. A SimpleClaim business measure model will be generated and a new object will be added under the SimpleClaim process in the Project Tree. You can open the Business Measures Editor on this model to add KPIs and aggregated metrics.

Create a metric and trigger

A metric is a measurement for a process or process element. Metrics can be created as an instance metric for each instance created or as an aggregate metric that can operate on all the instance artifacts (like metrics, counters, and stopwatches). This example will create an instance metric that is set to 1 when the instance is started. We can then define an aggregate metric that will total all of these instance metrics for the total count of express claims.

In the Attributes window, select the Metric tab and add a new ExpressClaimMetric metric, as shown in Figure 6.

Figure 6. Define a metric ExpressClaimMetric and add a trigger
define metric

Add a trigger, as shown in Figure 7, to this metric so that it is set to 1 when the ExpressClaim activity is started.

Figure 7. Define a trigger when ExpressClaim activity is started
define trigger

Create an aggregate metric

The SimpleClaim example requires an aggregate metric that will be used to define a key performance indicator (KPI). The instance metric ExpressClaimsMetric is set to 1 each time a new instance is created. In the KPIs and Aggregate Metrics panel, shown in Figure 8, add an aggregate metric NumberOfExpressClaims that uses the Total Aggregation function to sum up the instance metrics to produce the total number of express claims.

Figure 8. Add an Aggregate Metric: NumberOfExpressClaims
Add Aggregate Metric

Create KPI

The last step is to add a KPI that will track the percentage of express claims. We'll add a new KPI, Percentage of Express Claims, as shown in Figure 9. The KPI defines your target with a lower and upper margin. To calculate the percentage of express claims, the total number of claims is also needed. Select a User Defined Aggregation function and invoke the Expression Builder to build such a calculation.

Figure 9. Add a KPI: Percentage of Express Claims
Add KPI

Figure 10 shows the user defined expression. The predefined expression SimpleClaim.Completed and Terminated process instances provides the total number of claim processes. To calculate the percentage of express claims, we need to multiply the NumberOfExpressClaims by 100 before dividing by the total number of claims. If the division is first, the result will always be 0.

Figure 10. User defined expression to calculate percentage

Create a business measures event

A business measures event is defined to send a situation event in response to a significant occurrence. The business measures event is created by selecting the New > Event Definition pop-up under the Events folder, as shown in Figure 11.

Figure 11. Creating a new Event Definition

We'll create a new event called SimpleClaim and add an attribute ClaimNumber to the event, as shown in Figure 12. The SimpleClaim event has the parent template BusinessSituationEvent, where it inherits the rest of the required attributes.

Figure 12. SimpleClaim event definition with a new attribute

Create a trigger for a situation event

In this example, we will send the situation event each time a claim is received. The event can be used to create an alert or send an e-mail. The trigger is created as an instance trigger, and therefore requires you to:

Open the SimpleClaim Business measures model.
Select the Diagram tab, then the Trigger tab.
Create the trigger by selecting Add.
Change the name to ClaimOpened.
Set the Source category to Inputs and outputs, which allows copying data from the business object into the event. The source will be the SimpleClaim_InputCriterion.

When a claim is opened, we want a situation event to be sent. Scroll down to the Situation events section and add an event. The SimpleClaim event extends the BusinessSituationEvent template, and therefore has the BusinessSituationName attribute. The value of the BusinessSituationName will be used when creating the situation event binding in the Adaptive Action Manager. The BusinessSituationName is set to ClaimOpened, and the attribute ClaimNumber will have a value set using the expression builder. The completed trigger is shown in Figure 13.

Figure 13. ClaimOpened trigger

Export the insurance claim process model

We're now ready to export the process model to Integration Developer to add the implementation, and export the business measures model to WebSphere Business Monitor for monitoring.

To prepare for the export, create a workspace using Integration Developer. In this example, the workspace is E:\projects\simpleEndToEnd\processImpl.
Select the Export menu to invoke the Export wizard. Select WebSphere Business Monitor and development tool, as shown in Figure 14.
Figure 14. Export to Integration Developer and WebSphere Business Monitor
Select the Integration Developer workspace location that was described earlier. Make sure you enter SimpleClaimModule as the module name, as shown in Figure 15. When you click Finish, the artifacts will be generated into the Integration Developer workspace.
Figure 15. Select WID Workspace location

Import the project into Integration Developer

To import the project, start Integration Developer in the same workspace. Select File > Import and choose Existing project into Workspace. In the wizard, select the project SimpleClaimModule that is in the workspace, as shown in Figure 16. Click Finish to import the artifacts into the Integration Developer project.

Figure 16. Select the SimpleClaimModule project
Import

After the workspace has finished building, the Business Integration Perspective will show the module structure as shown in Figure 17.

Figure 17. SimpleClaimModule imported into Integration Developer
Business Integration

You can double-click and open the SimpleClaim BPEL process that is exported from your process model, shown in Figure 18. The names of the local tasks in the process model are used as the BPEL activity names.

Figure 18. SimpleClaim BPEL process
Bpel

A number of warning messages are added to the Problems View, shown in Figure 19. They indicate that the three components ReceiveClaim, ExpressClaim, and HighTouchClaim have not been implemented. We will now add the implementation for these components.

Figure 19. Problems View shows some warnings

Adding Java implementation

Double-click on SimpleClaimModule to open the Assembly Editor, as shown in Figure 20. Select the ReceiveClaim interface and choose to generate a Java™ implementation. Repeat for the ExpressClaim and HighTouchClaim interfaces.

Figure 20. Generate Java implementation
Generate Implementation

You can locate the Java implementation under the Java folder. For example, you might want to customize the InputCriterion method for the ReceiveClaim implementation, as follows.

Listing 1. Customizing ReceiveClaim operation

public DataObject InputCriterion(DataObject input) {
   System.out.println(input.getString("name") + " " +
                      input.getString("id") + " " + 
                      input.getInt("estimatedCost"));
   return input;
}

Deploy to WebSphere Process Server

As soon as the module has been implemented in Integration Developer and unit tested, it can be exported as an enterprise archive (EAR) and deployed on WebSphere Process Server. The Business Process Container (BPC) Explorer can be used to create instances of the process. You can invoke the BPC Explorer using a URL similar to http://<wpshostname>:9080/bpc.

Figure 21 shows the SimpleClaim process template. Click on Start Instance to create a new instance. The amount entered in the estimatedCost field will determine whether or not the process instance will go through the ExpressClaim or HighTouchClaim task.

Figure 21. BPC Explorer for testing the SimpleClaim process

Deploy to WebSphere Business Monitor

Monitor.zip

There are two Monitor.zip files. Modeler exports the file Monitor.zip, which is an input to the schema generation. The schema generation also creates a file Monitor.zip for the Monitor's model import.

In the workspace, where we exported the artifacts from the Modeler, there is a Monitor.zip file that must be deployed to the Monitor server. This zip file contains the KPIs that are captured in the Business Measures model. Use the WebSphere Application Server administration console to configure the Monitor server to monitor the SimpleClaim process. There are four main steps.

Generate the schema.
First you need to configure the schema generation using three panels. The first panel lets you specify the location of the Monitor.zip file and the location where the artifacts are to be created. The next two panels control the frequency of replicating the data from the State database to the Runtime database, and the Runtime database to the History database. The default for the Runtime to History database population interval is 1440, or 24 hours. For testing, it is suggested that you use a faster frequency, such as 10 minutes. See Figure 22 for an example.

Figure 22. Schema generation, configuration through Application Server admin
Configure the database.
After the Schema Generator configuration has been updated and saved, the schema can now be generated.
Start the replication manager scripts.
The Schema Generator will create the Data Definition Languages (DDLs) to create tables for the business measures and the scripts for the Replication Manager. The SimpleClaim example ships .bat files that execute the DDLs, unzip the generated DS_setup.zip files, and start the replication manager.
Import the model.
Once the DDL and replication manager setup is complete, the Model needs to be imported using the WebSphere Business Monitor administration in the Application Server admin console, as shown in Figure 23. The model to import is in the schemagen directory created in the generate step of the schema generation, and the file name is Monitor.zip.

Figure 23. Import model into Monitor

Configure the Adaptive Action Manager

The Adaptive Action Manager lets you define the desired behavior for a monitored application when a business measures event is created. In this article, the model is configured to create a SimpleClaim event each time a claim is opened. The SimpleClaim event had a BusinessSituationName of ClaimOpened. The Adaptive Action Manager allows the creation of configurations for type of notifications desired from the situation events.

The global configurations for the Adaptive Action Manager should be set up first, which includes configuring Lightweight Directory Access Protocol (LDAP) server information. The notification templates use an LDAP query for determining the users that should be notified of an event.

The notification template lets you specify the service type. The Action service types are Alert, Cell Phone, Email and Pager. We'll create a notification type of Alert to generate an alert that can be displayed in the dashboard. The users that are able to view this alert are configured in the notification template through the LDAP query. Figure 24 shows the notification template configuration for an Alert that will be sent to all users configured in the LDAP server.The LDAP search string of (&(objectclass=top)(objectClass=inetOrgPerson)) is used to return all users.

Figure 24. Notification Template List for Adaptive Action Manager

The next step is to bind the notification template with the Situation Event. The Business measures event created through the modeler is a SimpleClaim event. The binding between events is through the name assigned to the BusinessSituationEvent attribute of the event. The name configured in the Modeler is ClaimOpened. Use Add to add the ClaimOpened template to the Situation Event binding, as shown in Figure 25.

Figure 25. Completed Situation Event Binding

Configure the Monitor dashboard

The Monitor dashboard requires some configuration for the example in this article. The schema generation step in Deploy to WebSphere Business Monitor also creates the cube model. The model_cv.xml file from the schema generation step must be imported into the History database through the IBM DB2® online analytical processing (OLAP) center. DB2 AlphaBlox also needs to be configured, which includes creating the HISTORY and HISTORY_CUBE data sources, and creating the cubes.

WebSphere Business Monitor dashboard portlets

WebSphere Business Monitor ships several portlets that you can use to build a dashboard. You can use these portlets to put together different dashboards based on user roles. For example, the VP of claims might be interested in the KPIs, Gauges, and Reports portlets to get a high-level view of the performance data. The business analyst may be interested in the Dimensions, Active Instances, and Process portlets to get more details. This section discusses several of the portlets for our scenario.

KPIs portlet

The KPIs portlet displays key performance indicators. Configure the KPIs portlet by selecting the KPIs that you want to display. In our example we have only one KPI, Percentage of Express Claims. Select it as shown in Figure 26.

Figure 26. Selecting KPI to display
KPI configuration

Figure 27 shows our KPI displayed in the KPIs portlet.

Figure 27. KPIs portlet
KPI portlet

Alerts portlet

The Alerts portlet displays alerts created from the Notification template defined earlier. Because we defined an LDAP query that returns all users, we know the alerts will be available for this user. Figure 28 shows the Alerts portlet.

Figure 28. Alerts Portlet

The alert can be opened by clicking the link in the subject column. Figure 29 shows the details of one alert.

Figure 29. Alerts Details portlet

Gauges portlet

The Gauges portlet displays the KPI using dials. The KPI can be configured to use either the KPI's limits or targets. Figure 30 shows the Gauges portlet for our SimpleClaim.

Figure 30. Gauges Portlet

Process portlet

This Process portlet displays the business process diagram in the portal, and lets user drill down to see subprocesses, as shown in Figure 31.

Figure 31. Process portlet

Reports portlet

The Reports portlet can be used to create reports on the historical data. Figure 32 is a simple example that shows the trend line for the creation of claims.

Figure 32. Reports portlet

Conclusion

In this article, you saw how the SOA life cycle is realized through a new generation of WebSphere Business Integration products. A simple claim process illustrated this the approach. To summarize, Table 1 shows the four phases in the SOA life cycle.

Table 1. Phases in the SOA life cycle

Model	Use WebSphere Business Modeler to model your business process and to specify your business performance objectives.
Assemble	Use WebSphere Integration Developer to assemble existing services, implement new services, and to test each component.
Deploy	Deploy the business processes into WebSphere Process Server, the business measures model into WebSphere Business Monitor, and configure the performance warehouse.
Manage	Use WebSphere Business Monitor to monitor the actual performance of the business process and to take action when the objectives are not met.

Figure 33 shows the overall topology and the artifacts that flow through these products. Continuous process improvement is also supported by exporting actual values from the WebSphere Business Monitor into Modeler so that the analysts can improve the process by running simulations based on real data.

Figure 33. Products for SOA process automation scenarios

Acknowledgements

The authors want to thank Raymond Kong for his assistance with the example in this article.

Download

Description	Name	Size	Download method
Simple claim model	i-odoebp17code.zip	869KB	HTTP \| Download Director

Information about download methods

Resources

Learn

Series overview: Link to previous articles and read about this series, which demonstrates to business analysts, solution designers, and architects how to design and implement on demand solutions using the thirteen capabilities of the IBM On Demand Operating Environment.
Service-Oriented Architecture: Read an overview, success stories, news, documentation, information specifically for business and IT leaders, and much more.
WebSphere Process Server: Provides an overview, features, benefits, system requirements, and more.
WebSphere Integration Developer: Learn about WebSphere Integration Developer and related software.
WebSphere Business Modeler: Read all about WebSphere Business Modeler Basic, WebSphere Business Modeler Advanced, and WebSphere Business Modeler Publishing Server.
WebSphere Business Monitor: Get more information about WebSphere Business Monitor and related software.
Browse for books on these and other technical topics.

Discuss

developerWorks blogs: Get involved in the developerWorks community.

About the authors

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=Sample IT projects, WebSphere, Architecture

ArticleID=102857

ArticleTitle=Architecting on demand solutions, Part 17: Build a Hello World SOA application

publish-date=01302006

author1-email=clau@ca.ibm.com

author1-email-cc=

author2-email=bonanno@us.ibm.com

author2-email-cc=