In the previous articles we looked at each of the service-oriented component types that you can build with WebSphere Integration Developer, including business state machines, business processes, and human tasks. We toured the overall programming model and various supporting tools, such as visual snippets and mapping. We also explored the on-demand capabilities that WebSphere Integration Developer provides, such as how using business rules helps you make your running application dynamic and flexible so that you can handle changing business conditions without having to redeploy the application.
Simply put, you identify your key business decisions, create a business rule for the decision, and ultimately make it configurable at runtime. For example, if the client is one of your best, perhaps you want to give him or her a 20% discount. Maybe, on a particularly grumpy day, you want to lower that discount to 10%. Business rules in WebSphere Integration Developer make it easy to be grumpy, or adjust other, more pressing business needs.
The next piece of the on-demand puzzle is the selector.
A selector is a dispatch pattern you use to dynamically determine which implementation of a component to invoke at runtime. Like a rule group, a selector has date range entries, selection criteria, and a default destination. You select a destination in a selector the same as your would for a rule group. That is, when a selector is invoked, it selects a destination using the selection criteria and date range entries. A destination could be any service-oriented component.
One major difference between a selector and a rule group is that the destination of a selector can be any service component, while a destination in a rule group can be only a rule set or decision table. In other words, a selector can dynamically re-route a service call to any other component at runtime.
You can call a selector from any of your service-oriented components. The selectorâs job is to use dynamic information to determine which component should be called to do the work. The set of destination components is also configurable, allowing you to provide additional destinations at runtime. For example, imagine that at the start of the new year (after all the confetti has been cleaned up) you want to switch your application over to a new subsystem for inventory management. A selector allows you to provide two destinations and indicate that the new one takes effect on January 1.
Letâs take the following business process shown in Figure 1 as an example. This business process is for approving a loan application and has only two steps:
Step 1: Invoke a service to check for the credit rating.
Step 2: Invoke another service to determine if the loan should be approved.
Figure 1: Business process calling a partner service
The two invoke activities are hard-wired to target implementations in the assembly diagram. Letâs say the business process invokes the low cost credit-checking service that Company A provides. What happens if the service that Company A provides becomes unavailable during a certain period?
Such a situation is where selectors can help. As mentioned, selectors can decide which implementation to invoke. In the next section, you will see how using selectors can let you change the destination of the service call from Company A to another company's service which costs more, but is available 24x7.
A basic use of a selector is for simple dispatch, which
means you can dynamically reroute the destination of a
service call from one component or import to another.
Letâs make the
Invoke Credit Checking Service
activity in the business process now call a selector
instead of being statically wired to the Company A
service. It would look like the following:
Figure 2: Using a selector for simple dispatch
Invoke Credit Checking Service
activity calls a selector that will decide at runtime
which implementation to invoke. The selector uses a
selection criterion to choose a destination that is the
desired service implementation to invoke. The selection
criterion could either be a current date, an XPath
expression that gets a date from a business object, or a
Java snippet that returns a date. Just like rule groups,
each destination has an entry that specifies a range of
dates in which this destination would be applicable. If
the date returned from the selection criterion is within
the boundary of the date range entry, then the selector
will use the corresponding destination.
The date range entries are optional. If, in fact, no date range entry is supplied or if no date matches the selection criterion, the default destination will be invoked. Keep in mind that if you do not specify a default destination and no date range entry matches the selection criterion, then an exception will be thrown. Therefore, it is best to provide a default destination.
In Figure 2, the selector chooses the service implementation that Company B provides if the selection criterion is a date in October 2006. The selector will run the service that Company C provides if the selection criterion is a date in November 2006. For all other situations, the selector runs the service that Company A provides.
Figure 3: Using a selector to call a component in the same module or an export in a different module
The destination of a selector can be a component inside
the assembly diagram of the same module or an export of
another module. For example, Figure
3 shows the
component wired to the
The selector can route service calls to either the
component in Module A or the
in Module B.
Keep in mind that the
interface operations of the selector must match all of
the interface operations of the destinations. In other
words, you may not select a destination that has an
interface with a different operation name, input, or
output than the selector itself. If you try to use a
selector where the operation name does not match, then
you get a
ServiceRuntimeException saying the
operation name cannot be resolved. If the input or
output does not match (for example, if the destination
interface has a different input name or a different
input type), then you get a
saying the component does not support the operation.
If you cannot match the interface of the selector with the interfaces of the destinations, you can use a selector with an interface map, which we described in the seventh article in this series, to convert from one interface to another by using the interface map as a destination in the selector. Then the selector can invoke the interface map that, in turn, calls the actual service implementation.
Figure 4 shows a selector that can
choose from two Web service imports, each having a
different interface. To reconcile the differences
between each interface, the selector sets the
corresponding interface maps as destinations, rather
than setting the imports as destinations. Then the
LoanApplicationProcess component can make credit-check
service calls using the
CreditCheck interface without
worrying about which import will be used, or the
interface of the import.
Figure 4: Using interface maps with selectors
We have covered how you can use a selector in a simple dispatch scenario. What if your company were to terminate the contract with Company A and replace it with a contract with Company B? Selectors can also help in this situation.
You can update or modify the destinations of a selector and their corresponding date ranges at runtime without redeploying the original application. This means that in the previous example, you would not have to redeploy the business process to modify the components you want to dispatch to through the selector.
Using the WebSphere Process Server administrative console, you can replace an existing service implementation with another one, add a new destination with complete date range information, or remove a destination.
Figure 5 shows an example of the actions that you can perform through the administrative console at runtime, including
- Replace an existing component (Company Z as the new default)
- Change the date range (Company B moves to December)
- Add a new component (Company X in October)
Figure 5: Using a selector to dynamically alter destinations
After updating the selector in the runtime, you can optionally export the changes back to the development workbench using the export function in the administrative console. The export function exports the module project that contains the selector into a project interchange file, which you can then import into the WebSphere Integration Developer workbench.
Later in the article, you will try this out by creating a selector that performs a simple dispatch. Then you will update the destination of the selector using the administrative console. After that, you will deploy a new module project and use the selector to invoke a service in the new module.
This section describes the high-level steps involved in creating a selector. In the next section, you will get a chance to actually build one yourself.
Creating a selector is similar to creating any other component in WebSphere Integration Developer. You start by choosing the interface that your selector will support. Often, you choose the interface based on the destinations that the selector dispatches to. Remember, the interface operations of your selector must match exactly the interface operations of the destinations. This includes the parameters, whose types must match exactly.
When you first create a selector, it opens in a graphical editor, as Figure 6 shows, in which you can specify more information.
Figure 6: Creating a selector
The first thing that you do is decide which of the following three selection criteria to use:
- Current date
- XPath expression
- Visual snippet or Java expression.
If you choose the current date criteria, then the selector selects a destination when the current date falls within the start date and end date of the destination. If you choose the XPath criteria, then you need to further specify the XPath expression that returns a date from the input variable. If you choose the Java expression criteria, you need to provide the Java code, which can be a visual snippet, that returns a Date object from the input variable.
After you decide which selection criteria to use, you can add destinations. Figure 7 shows the selection of a default destination. As previously mentioned, it is a good practice to always supply a default destination. When you click the default destination cell, it displays a list of available destinations to choose from. The list includes the components in the same module or exports from other modules.
Figure 7: Selecting a default destination
The last step is to provide destinations that apply only to a specific date range. Optionally, you can leave this section empty during development and modify it in the administrative console after deployment. You can also alter the default destination at runtime.
After adding a date selection entry, you can select the destination from the list of available destinations, as Figure 8 shows. There is no limit to how many rows you can add to the date selection table.
Figure 8: Adding additional destinations
Unlike other components on the assembly diagram, you donât wire selectors to other components or imports. Because the destinations in the selector are not statically bound, and because they might have destinations in other modules, there is no need to wire the selector to any component.
Weâve covered the theory, now it's time to learn how to build a selector. In this section, you add a selector to an existing application. As Figure 9 shows, the application consists of a loan processing module that calls a credit-check service. We provide the skeleton of the application in the download file, complete with the interfaces and business objects you need, so that you can focus on the material covered in this article. The existing application invokes a static service implementation, so you will make the application more flexible by introducing a selector.
After you download and import the application into the
workbench, you see four modules and one library.
LoanProcess business process, shown in Figure 9, resides in
which makes a static call to the
Company A service. The
other modules are destinations for the selector you will
Figure 9: The existing LoanProcess module
In the first section of the exercise, you remove the static wire, which allows service calls to Company A, and replace it with a selector that will route calls to Company A, B, or C based on an XPath selection criteria, as shown in Figure 10:
Figure 10: The updated LoanProcess module
In the second section of the exercise, you explore the selector features in the administrative console. You learn how to replace an existing destination and add a new destination without needing to redeploy the original LoanProcess application.
Before you start the exercise, you need to download and import the project interchange file that contains the sample application.
beginningnodules.zipfile from the Downloads section at the end of this article.
- In the workbench, select File - Import - Project Interchange, and then click Next.
Browse to the
beginningnodules.zipfile that you just downloaded, and then click Open.
Select All, and then click
The imported modules open in the Business
Integration view and, as the modules build, you see
Building workspacemessage in the lower right corner of the workbench. Wait for the workspace to finish building.
In exercise 1, you will create a selector that has one default destination and two date range destinations. Then you will change the invoke activity in the LoanProcess business process that originally invoked the CompanyA import to invoke the newly created selector instead. Finally, you will deploy and run the application.
In this step, you create a new module for the selector. The interface used in the module already exists in the CommonLibrary.
In the Business Integration view, right-click and
select New - Module. Name it
SelectorModule, and then click Finish.
- Double-click the SelectorModule that you just created. The dependency editor opens so that you can specify which libraries you want to include with your module.
- Click Add, select CommonLibrary from the list, and then click OK.
- Save the dependency editor, and then close it.
The interface that the selector uses is already in the
CommonLibrary. The interface has one operation,
checkCredit, and an input and output of type
LoanData, as Figure 11 shows:
Figure 11: The selector interface
- In the Business Integration view, expand SelectorModule. Under Business Logic, right-click Selectors, and then select New - Selector.
For the name of the new selector, enter
CreditSelector, and then click Next.
- Select SelectorInterface from the interface list.
- Click Finish. The selector editor opens.
Now, you can define the selector so that the service
call gets routed to the correct component. In the
next steps, you specify the selection criteria,
which is the value of the
- In the selector editor, select checkCredit in the Interfaces section on the left panel.
- In the Selection Criteria cell, click Current date, and then select XPath from the list of available selection criteria.
- In the Parameter cell, click Enter Parameter, and then select input1 from the list of available parameters (there is only one in this example).
- In the XPath cell, click Enter Parameter, and then select applyDate as the XPath expression.
The selection criteria should now appear as it does in
Figure 12. In the following steps,
you specify the destinations to be used, depending
on the value of the
applyDate XPath as specified in the previous steps.
- In the Default Destination cell, click Enter SCA Destination and select Company_A_Component_Export from the list of destinations.
- To add a date selection entry, click the Add Date Selection Entry button (). The destination list displays s new destination.
of the destination to
Oct 1, 2006and the End Date to
Oct 31, 2006. Note that you can type the date or you can click the date selection button () to the left of the cell to select a date from the calendar.
- Click Enter SCA Destination, and select Company_B_ComponentRG_Export.
Following the same steps you just followed, create
another destination with a
Start Date of
Nov 1, 2006and an End Date of
Nov 30, 2006. For the destination, select Company_C_ComponentExport.
- Save the file. The final selector should appear as it does in Figure 12.
Figure 12: The selector definition
To use the selector you just created, you need to add it to the assembly diagram of the selector module. Then, to make the selector available to other modules, you need to create an export. You give the export an SCA binding because only other modules of your application will invoke it, not external clients.
- Open the SelectorModule assembly diagram by expanding SelectorModule and double-clicking SelectorModule in the Business Integration view.
- Drag CreditSelector from the BusinessLogic - Selectors category in the Business Integration view to the assembly diagram.
- Right-click the CreditSelector component in the assembly diagram, and select Export - SCA Binding.
- Save the assembly diagram contents.
Figure 13: The selector module
When you open the assembly diagram of the
LoanProcess_Module in the steps below, you will see that
LoanProcess is wired to an import that connects to
Company Aâs export through an SCA binding. If you open
the LoanProcess business process (double-click it) and
select the Invoke Credit Checking Service invoke
activity, you see that the invoke activity contains
a partner link with Company Aâs interface.
In this section, you make the application more flexible by modifying the invoke activity of the business process so that it calls the selector, rather than a specific component.
LoanProcess_Moduleassembly editor by expanding LoanProcess_Module and double-clicking LoanProcess_module.
LoanProcessbusiness process by double-clicking the LoanProcess component in the LoanProcess_Module assembly diagram.
- On the right palette, select Partner, and then switch to the Properties view and select the Details tab.
- Click Browse, select SelectorInterface from the list of interfaces, and then click OK.
- In the business process editor, select the Invoke Credit Checking Service activity, and then, in the Details tab of the Properties view, select checkCredit for the operation.
Set the input1
Output1, respectively. Your business process should now look like Figure 14:
- Save the file.
Figure 14: The updated business process
The property details for the Invoke Credit Checking Service should now appear as they do in Figure 14. Notice that there is a red âxâ in the Business Integration view next to the LoanProcess_Module. Because you changed the partner interface in the business process, you need to change the corresponding component reference in the assembly editor by following these steps:
Open the LoanProcess_Module assembly diagram, and
then select the component reference of the
(Tip: The component reference will also have a red âxâ until you complete these steps.) Figure 15 shows the reference being selected.
Figure 15: The LoanProcess_Module assembly diagram
- In the Details tab of the Properties view, expand References - Partner - CompanyA_Interface.
Next to Interface, click
Change and select
from the list of interfaces.
Tip: The previous interface might be selected as the filter in the Change Interface dialog box, so you might need to clear that from the filter to see the other interfaces in the list.
Delete the wire from the
- Right-click LoanProcess and select Wire References to New - Imports. A Partner import is created.
- Right-click the Partner import and select Generate Binding - SCA Binding.
- In the Binding tab of the Properties view for the Partner import, click Browse and select CreditSelectorExport.
- Click OK and the save the assembly diagram.
Because the component reference and the process partner match, the error markers disappear. Your module assembly will appear as it does in Figure 15. Now you are ready to test your new selector.
In this step, you use the integration test client
to invoke the
checkCredit operation of the
component. The test client starts the server if
necessary, and deploys the modules to the server. But
first, letâs step back a bit and investigate more
features of the test client that are handy here.
Typically, you would test a module by right-clicking the module in the Business Integration view, or by right-clicking the module assembly diagram and selecting Test Module. However, in this case the module we're testing is going to make service calls to other modules,so the other modules must be deployed to the server first.
You can right-click your server in the Servers view and use the Add and remove projects menu to select which modules to deploy. You can also control which modules to deploy using the test client. Use the test client to deploy when you want to emulate or monitor service calls in the other modules. To do so, in the Business Integration view, select each of the modules you want to test (hold down Ctrl as you select each module), then right-click any selected module and select Test - Test Module. Now when you start a test, it deploys each selected module to the server and monitors service calls as other modules are invoked. You also see each module in the Configurations tab of the test client, which means that you can add emulators or enable or disable monitors.
Letâs get on with testing now:
Hold down Ctrl and select
SelectorModule, as Figure 16 shows.
Figure 16: Modules to be tested
- Right-click a selected module and select Test - Test Module.
In the test client that opens, ensure
LoanProcess_Module is selected for the module, and
that LoanProcess is selected for the Component, as
Figure 17 shows:
Figure 17: Testing the LoanProcess component
2006-10-09for applyDate, anything for name, and
- Click Continue, and then in the Deployment Location dialog that opens, click Finish.
- Wait for the server to start and for the modules to deploy.
The selector uses
applyDate to decide which
component to run. Because the date is within the start
and end dates that you specified (Oct 1, 2006 and Oct
31, 2006), the Company_B_Component is called.
Figure 18: Testing results
Now letâs try a different date. How about 2006-11-9? In this case, the selector calls Company Câs service.
Suppose that your business environment has evolved and
you need to change the default destination for
CreditSelector. In exercise 2, you use the
administrative console to alter the default destination
of the selector. After you commit the change, you
test the LoanProcess again.
- You can change selector criteria using the administrative console. In the Servers view, right-click the server and select Run administrative console.
- In the Log in page, you have to specify a user name to change anything in the selector, even if you have not enabled security. Type any user name and log in.
- In the navigation section, expand Servers, click Application servers, and then click server1.
- In the server1 editor page, scroll down to the Business Integration section and click the Selectors link, as shown in Figure 19:
Figure 19: Changing selector properties at runtime
In the Selectors page, you see all the
selectors currently in the system. Click
shown in Figure 20, which is
the one that you created earlier:
Figure 20: Selecting CreditSelector
Click the checkCredit
link. You see the date entry for this selector,
as Figure 21 shows:
Figure 21: Properties for CreditSelector
- To modify the selector, click the default link.
In the Target Components list, select
Exported Target: Company_B_Module
and click OK.
Figure 22: Changing the default destination for the selector
- To commit the change, select the check box next to the default selector, and then click Commit. You see a message at the top of the administrative console reminding you to select commit to make the changes take effect.
Now letâs run the
LoanProcess again. To invoke the
default destination, use an applyDate of
As Figure 23 shows, you will see
that the service from Company B is invoked.
Figure 23: Testing the default destination change
Now letâs suppose that your business environment has
evolved further and you need to change the default
destination from Company A to Company X. However, you
havenât deployed the module for Company X to the server.
In this step, you deploy a new module, Company X,
to the server, and then use the administrative
console to specify when this new module should be used
as the destination. After you commit the change, you
will test the
- Right-click the server and select Add and remove projects.
- In the Add and Remove Projects dialog box, select Company_X_ModuleApp from the list of available projects, and then click Add.
- Click Finish and wait for the module to deploy.
- Following the steps in the previous section, navigate to CreditSelector in the administrative console, and then click checkCredit.
- To create a new date selection entry, click New.
Modify the start date to
December 1, 2006and end date to
December 31, 2006.
- Change the Target Components to Exported Target: Company_X_Module CompanyX_Component_Export.
- The form should now look like Figure 24.
Figure 24: Adding a new destination
Select the checkbox beside the first date entry, and
click Commit, as Figure 25 shows:
Figure 25: Committing a new selector destination
If you run LoanProcess again, this time using an
2006-12-03, you will see the result shown in Figure 26.
Figure 26: Results of a new destination being selected
This concludes the Guided Tour of WebSphere Integration Developer series. Throughout the series, we showed you how to get up and running by covering the basic concepts, namely the programming model, business objects, interfaces, components, and references. We also introduced you to each of the various component implementation types that WebSphere Integration Developer provides, namely business state machines, business processes, and human tasks. Plus, we looked at the various supporting tools, such as interface maps and visual snippets. We hope that this series has helped you understand how to use the tooling, and that you are now on your way to developing your own applications to make your business more on-demand.
The authors would like to thank Stephanie Parkin, Laura Gardash, Catherine Hamilton, and Donna Sutarno for their invaluable help with this series.
|MappingExample module with artifacts and utilities||beginningmodules.zip||73 KB||FTP|HTTP|
|Complete MappingExample module||completedapplication.zip||85 KB||FTP|HTTP|
A guided tour of WebSphere Integration Developer -- Part 1: Get a driver's view of the WebSphere Integration Developer landscape
A guided tour of WebSphere Integration Developer -- Part 2:
SOA development with WebSphere Integration Developer
A guided tour of WebSphere Integration Developer -- Part 3:
Building a simple service-oriented application
A guided tour of WebSphere Integration Developer -- Part 4:
Unleashing visual snippets and business state machines in your service-oriented application
A guided tour of WebSphere Integration Developer -- Part 5:
Business processes in a service-oriented world
A guided tour of WebSphere Integration Developer -- Part 6:
Becoming more on-demand using dynamic business rules
A guided tour of WebSphere Integration Developer -- Part 7:
Interface mapping, business object mapping, and human tasks
Creating WebSphere Process Server Custom Selectors with WebSphere Integration Developer
WebSphere Process Server relationship service, Part
1: Static relationships
WebSphere Process Server relationship service, Part
2: Dynamic relationships
Installing and starting Business Process
XML Path Language (XPath)
Business Process Choreographer Samples. (Select
Human Task Features)
WebSphere Process Server V6.0 Business Process
Choreographer Programming Model. (Section 6.3 Human
Business Process Execution Language for Web Services
Business Process with BPEL4WS: Understanding BPEL4WS
WebSphere Integration Developer product information
WebSphere Process Server product information
WebSphere Process Server: IBM's new foundation for
Build a Hello World SOA application
Service Component Architecture
Common Event Infrastructure
developerWorks: WebSphere Process Server and WebSphere Integration Developer resources
developerWorks: WebSphere Business Integration zone
developerWorks: WebSphere development tools zone
Meet the experts: WebSphere Integration Developer
Get products and technologies
Jane Fung is an Advisory Software Developer at IBM Canada Ltd, where she is responsible for developing the Business Process Execution Language (BPEL) and Business Rules debuggers in WebSphere Integration Developer. Prior to that, she was the team lead of the WebSphere Studio Technical Support team.
Greg Adams was the lead architect for the user interface in the award-winning Eclipse platform, and more recently, has been the lead architect and development lead in the core WebSphere Business Integration Tools, including WebSphere Studio Application Developer Integration Edition and WebSphere Integration Developer. Greg led the delivery of IBM's first complete services oriented architecture (SOA) tools stack and the first BPEL4WS standards supporting Business Process Editor; both critical deliverables in support of IBM's On Demand strategy.
Richard Gregory is a software developer at the IBM Toronto Lab on the WebSphere Integration Developer team. His responsibilities include working on the evolution and delivery of test tools for WebSphere Integration Developer.
Randy Giffen is a senior software developer is the usability lead for WebSphere Integration Developer and WebSphere Message Broker Toolkit. He was responsible for WebSphere Integration Developer's business state machine tools and the visual snippet editor. Prior to to this he was a member of user interface teams for WebSphere Studio Application Developer Integration Edition, Eclipse, and VisualAge for Java.