Part 3 of this series, Using selectors and business rules for dynamicity, describes an approach for enabling points of variability (POV) in composite business services (CBS) by using business rules and selectors. Although that approach can improve flexibility, there are some drawbacks. For example, you can add new targets to a selector at runtime using the WebSphere Process Server administrative console or the corresponding scripting interface, but the following additional capabilities are needed:
- Add new selector targets programmatically at runtime (see Part 1, "Choosing the right implementation)."
- Add new selector targets regardless of the underlying invocation model
(synchronous or asynchronous) or the implementation protocol.
For example, you could realize this capability by dynamically switching between a synchronous SOAP/HTTP and an asynchronous SOAP/Java™ Message Service (JMS)-based service.
This article provides a solution to the technical limitations just described using an SCA mediation module in WebSphere Enterprise Service Bus (ESB) 6.0.1. WebSphere Process Server (Process Server) includes ESB, so everything in this article applies to Process Server as well. You get step-by-step examples for implementing a Service Component Architecture (SCA) mediation module in ESB and you learn the portlet and Business Process Execution Language (BPEL) process implementation details to support POV in the scenario.
Use case for funds transfer services
The solution in this article is based on a funds transfer scenario with two fictional banks: First Bank of North America (1st bank) and Second Canada Bank (2nd bank). The 1st bank wants to implement an SOA composite business service for funds transfer. The implementation for the service must support several features:
- Expose functions using a portlet-based user interface (UI).
- Handle internal bank funds transfer (from one account to another within the same bank) by relying on an existing legacy implementation that is exposed as a SOAP/HTTP Web service.
- Handle external bank funds transfer (from an account in a bank to another account in an external bank) by relying on an existing batch transfer implementation that is exposed as a SOAP/JMS Web service.
- Expose a common UI to the customer for funds transfers from one account to another, regardless of whether one of the accounts is an external bank account.
In the use case, Bob Clark is a bank customer of the 1st bank who logs on to the bank's portal and navigates to the Funds Transfer portlet.
If Bob makes a transfer to another account in the 1st bank, the transfer is executed synchronously. It is validated by the CBS to ensure that sufficient funds exist in the source account. If the validation business logic passes, the funds transfer is executed and a response with the success notification message is returned to the customer. The amounts on both source and target accounts are updated to reflect the transfer.
If Bob makes a transfer to an external account at 2nd bank, the transfer is executed asynchronously:
- The money is debited from the customer's 1st bank account.
- A funds transfer request message is submitted to a batch service that handles cross-bank transfers.
- The customer is notified with a message that the transfer has been submitted, and funds may take time to arrive at the 2nd bank account.
- Once the batch cross-bank service handles the transfer of funds, Bob Clark can log in to the 2nd bank's portal and verify that the funds transfer went through successfully.
In the remainder of this article you learn how to implement the use case using an ESB mediation module.
Part of the implementation of the use case involves two Web services: the Internal Bank Funds Transfer Service and the External Bank Funds Transfer Service. The services use different underlying message protocols, but implement the same SCA interface.
The Internal Bank Funds Transfer Service has a SOAP over HTTP binding and provides a synchronous response within hundreds of milliseconds. The External Bank Funds Transfer Service uses SOAP over JMS and provides an asynchronous response that can return in a range from minutes to hours. The interface for funds transfer, called AccountTransferService shown in Figure 1, exposes the services for an account.
Figure 1. AccountTransferService interface
The Internal Bank Funds Transfer Service is generated from
a stateless session Enterprise JavaBeans (EJB) component. Upon an invocation, the specified amount of money (input
variable: amount) is debited from an account (input
variable: fromAccId), and
immediately credited to another account (input variable: toAccId) in the same bank
(precondition: fromBankId == toBankId). To ensure atomicity, a component-managed
EJB transaction is used to execute the makeTransfer method in a single transaction
scope.
The External Bank Funds Transfer Service is also generated from a stateless
session bean. Upon invocation, the specified amount (input variable: amount) of
money is debited from an account (input variable: fromAccId) in a bank (input
variable: fromBankId), followed by an invocation of the
existing batch transfer service called Batch Interbank Funds
Transfer Service. Since the batch service may take an indeterminate amount of time,
it is invoked asynchronously. In this case, a bean-managed transaction is used.
Asynchronous invocation SCA wrapper component
By default, the invocation of an imported Web service in an SCA module is synchronous, so you need to create an asynchronous invocation wrapper for the External Bank Funds Transfer Service.
- Create an SCA module and import the External Bank Funds Transfer Service into this module using a Web service binding.
- Create a new interface named AsyncAccountTransferInterface containing a
one-way invocation, as shown in Figure 2. The one-way method is nearly the same as the
makeTransfermethod, except it contains no responses or faults and includes an additional parameter called endpoint.
Figure 2. AsyncAccountTransferInterface
- Create a BPEL component with the interface AsyncAccountTransferInterface, as shown in Figure 3.
Figure 3. Implementation of AsycService
Add a snippet activity to perform dynamic binding to the imported Web service using the endpoint address from the parameter
Endpoint, as shown in Listing 1.
Listing 1. Perform dynamic binding to imported Web service
com.ibm.websphere.sca.addressing.EndpointReference eRef =
com.ibm.websphere.sca.addressing.EndpointReferenceFactory.INSTANCE.
createEndpointReference();
eRef.setAddress(Endpoint);
com.ibm.websphere.sca.Service echoService = (com.ibm.websphere.sca.Service)
com.ibm.websphere.sca.ServiceManager.INSTANCE.
getService("AccountTransferServicePartner", eRef);
commonj.sdo.DataObject response =
(commonj.sdo.DataObject)echoService.invoke("makeTransfer",serviceRequestObj);
|
Figure 4. Assembly diagram
Mediation module for funds transfer
A mediation module is created to dynamically route a funds transfer request to either the Internal Funds Transfer Service or the External Funds Transfer Service, depending on whether the funds transfer has an internal or external destination.
The mediation module exposes an interface, as shown in Figure 5. The input parameters contain all the input parameters of the AccountTransferService. There are two string parameters with values for the endpoint addresses of the two fund transfer services.
Figure 5. Mediation module interface
Figure 6 shows the assembly diagram. The component AccountTransfer is a Web service binding import that is exported by the Internal Funds Transfer Service. The component AsycAccountTransfer is a Web service binding import that is exported by the asynchronous wrapper of the External Funds Transfer Service. The two import components are wired to the mediation flow component called Mediation1. This component is exported with a Web service binding (Mediation1Export, shown here).
Figure 6. Mediation assembly diagram
The mediation logic for funds transfers are in the flow shown in Figure 7.
Figure 7. Mediation flow
A data type BankContext, shown in
Figure 8, is set as the transient context, which contains the variable
ifInternalBank to show whether the request is an internal transfer request or
not. ifInternalBank is an XSL transformation primitive.
Figure 8. Transient context object
An XSL function, shown in Figure 9, is used to compare whether fromBankId is the same as toBankId, and set the result to the transient context variable.
Figure 9. XSLT function
Filter, a message filter primitive shown in Figure 10, implements the following logic:
- If the transient context variable is
false, the request is an external transfer request. The message will be routed to AsycAccountTransfer, which will dynamically bind to the External Funds Transfer Service and asynchronously invoke it. - Otherwise, the request will be routed to a custom mediation primitive to dynamically invoke the Internal Funds Transfer Service.
Figure 10. Details of filter
CustomMediation is a custom mediation primitive. It has an execute method,
which implements the custom mediate logic. In this method, the Internal Funds Transfer Service is dynamically bound to an address that is passed to the mediation
module as parameter interEndpoint and synchronously invoked. Listing 2 shows the code snippet.
Listing 2. Code snippet of custom mediation primitive
public DataObject execute(DataObject input1) {
BOFactory boFactory = (BOFactory) ServiceManager.INSTANCE.
locateService("com/ibm/websphere/bo/BOFactory");
// (1) Create endpoint reference
EndpointReference eRef = EndpointReferenceFactory.INSTANCE.
createEndpointReference();
String address = input1.getString("interEndpoint");
eRef.setAddress(address);
// (2) invoke service and extract response payload
Service echoService = (Service)
ServiceManager.INSTANCE.getService("AccountTransferServicePartner", eRef);
// (3) Prepare input parameter to invoke partner service
DataObject requestMsg = boFactory.
createByMessage("http://accounttransferservice","makeCrossBankTransferRequest");
DataObject requestEle = boFactory.
createByElement("http://accounttransferservice","makeCrossBankTransfer");
requestEle.setString("fromBankId",input1.getString("fromBankId"));
requestEle.setString("fromAccId",input1.getString("fromAccId"));
requestEle.setString("toBankId",input1.getString("toBankId"));
requestEle.setString("toAccId",input1.getString("toAccId"));
requestEle.setString("amount",input1.getString("amount"));
requestMsg.setDataObject("parameters",requestEle);
// (4) Invoke service synchronously
DataObject responseMsg =
(DataObject) echoService.invoke("makeCrossBankTransfer",requestEle);
return null;
} |
After custom mediation is implemented, the assembly diagram will be changed as reflected in Figure 11. An additional Java component called CustomMediation implements the logic of custom mediation.
Figure 11. CustomMediationLogic component
Portlets and configuration for the mediation module
A portlet called the SaaSBankTransferCustomerPortlet is created to provide a UI for fund transfer service, as shown in Figure 12.
Figure 12. Portlet
You can configure the endpoint addresses of the Internal Bank Funds Transfer service, the External Bank Funds Transfer service, and the mediation module (Account Transfer Services Endpoint) through the config mode of the portlet, as shown in Figure 13. When the user clicks the Transfer Funds button in this portlet, the mediation module is invoked with the two endpoint address of internal and external bank funds transfer service as parameters.
Figure 13. Portlet Configuration Page
In this article you examined how to enable points of variability in CBS with ESB mediation modules. You also learned how mediation modules allow programmatic routing across multiple endpoints using different underlying messaging protocols. Understanding the banking transfer scenario implementation details, which uses Web services, SCA modules, a mediation module, and a portlet, should be helpful as you develop your own solutions. Ultimately, this approach will help your solution be more flexible to adapt to continually changing requirements.
Learn
-
Read the other parts in this series:
- Part 1, "Choosing the right implementation," gives an overview of the different options for designing and developing composite business services to cope with change, and describes the features and capabilities in IBM WebSphere software that can help you enable points of variability.
- Part 2, "Using dynamic service mediation in WebSphere Business Services Fabric," explains how to bind, at run time, a service invocation in a Business Process Execution Language (BPEL) process to one of several related endpoints by using ontology extensions and the WebSphere Business Services Fabric Dynamic Service Assembler.
- Part 3, "Using selectors and business rules for dynamicity," discusses using selectors and business rules in WebSphere Process Server to incorporate dynamicity and configurability for business processes in a composite business service (CBS). Issues when using selectors and business rules, criteria for choosing selectors to implement dynamic binding, and implementation best practices are also covered.
- IBM WebSphere Business Process Management Version 6.0 information center has all of the information that you need to install, maintain, and use WebSphere Business Process Management software.
- Rational Application Developer 6.0.1 information center has information that introduces the Rational Application Developer tool and the underlying workbench technology, and explains how to use this integrated development environment to achieve your software development goals.
-
"Dynamic routing at runtime in WebSphere Enterprise Service Bus" (developerWorks, Apr 2006) explains how to implement dynamic routing at runtime for Web services (SOAP/HTTP and SOAP/JMS) in WebSphere Enterprise Service Bus Version 6.0.1.
-
"Developing custom mediations for WebSphere Enterprise Service Bus" (developerWorks, Jan 2006) introduces the use of custom mediations using the WebSphere Integration Developer V6 environment for WebSphere Enterprise Service Bus V6, and walks you through the development of three types of custom mediations in a simple scenario.
-
"Getting started with WebSphere Enterprise Service Bus and WebSphere Integration Developer" (developerWorks, Jan 2006) introduces you to the WebSphere Enterprise Service Bus server and its accompanying tooling, WebSphere Integration Developer.
-
A guided tour of WebSphere Integration Developer: Part 6: Becoming more on-demand using dynamic business rules.
- View On demand demos to learn about various software
products and technologies from IBM.
-
A guided tour of WebSphere Integration Developer: Part 8: Dynamically invoking a component using selectors.
- In the
Architecture area on developerWorks, get the resources you need
to advance your skills in the IT architecture arena.
-
Browse the technology bookstore for books on these and other technical topics.
- Stay current with
developerWorks technical events and webcasts.
- RSS feed for this series. (Find out more about RSS.)
Get products and technologies
-
Get started now! Download more IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere.
Discuss
- Participate in the discussion forum.
-
Check out developerWorks
blogs and get involved in the developerWorks community.
Carl Osipov is an experienced software architect with the Strategy and Technology organization in IBM Software Group. His skills are in the area of distributed computing, speech application development, and computational natural language understanding. He has published and presented on Service-Oriented Architecture and conversational dialog management to peers in the industry and academia. His current focus is on design of reuse techniques for composite business services.
