In Part 3 of this series, we introduced you to Service Component Architecture (SCA) imports and exports and focused on using them as a mechanism to integrate SCA modules. In Part 4, we will take this discussion a step further by showing you how to integrate SCA solutions with other systems using JMS and Web services. Integration is difficult because it involves bringing together systems written with different technologies and deployed on different platforms, plus it involves a variety of challenges in data translation, connectivity, and many other issues. Web services and JMS are two common ways of integrating heterogenous systems -- and they also enable you to solve many of these complex challenges.
We will expand the example we used in Part 3 and enhance it to call external systems. For the purpose of this article, we will assume that you have gone through the previous parts of this series. Figure 1 below illustrates the example we will use.
Figure 1. JMS and Web service integration
Keep in mind that we are mimicking various development groups, both internally and externally. In real systems, you may want to group all related SCA components into a single module for performance reasons.
IBM® WebSphere® Process Server and IBM WebSphere Enterprise Service Bus (ESB) enable imports and exports to bind to JMS. Much like any import or export, you must first define a valid SCA interface ( which, in WebSphere Process Server or WebSphere ESB, can be either a WSDL file or a Java interface), and then bind the import or export to JMS using WebSphere Information Integrator. IBM WebSphere Integration Developer provides a Properties view where you can view and change the binding values. This is where you can then provide the necessary JMS information.
For JMS imports, calling the SCA interface will translate to writing a request message to the specified JMS destination, and (optionally), if a reply is required, read from a reply queue. WebSphere Process Server and WebSphere ESB let you to write to the underlying WebSphere Messaging (sometimes referred to as the Service Integration Bus, or SIBus) or WebSphere MQ.
For JMS exports, an arrival on the bound destination will trigger an invocation of the SCA component to which the export is wired.
When using WebSphere Integration Developer, you can configure the JMS import to provide the necessary JMS information, as shown in Figure 2. In addition, when using the underlying WebSphere Messaging, WebSphere Process Server with WebSphere ESB will automatically create destinations for you when you do not provide one. We will do this later in the example.
Figure 2. JMS import binding
If the JNDI name is not provided, it will name the destination based on the module and import or export name, and create it on the SCA application bus by default. Figure 3 illustrates this. To access the service from the JMS API, you must create the JMS destination and connection factory and point to the correct SIBus destination and bus. You can also specify the data format over the wire; you can place either a serialized Java object or XML serialized data. In most integration scenarios, XML is preferred because XML is programming language independent. Because the business objects in WebSphere Process Server with WebSphere ESB are defined by an XML schema, you can share it with partners so they can use their own binding tool.
Figure 3. Underlying messaging artifacts
Because the WebSphere Process Server or WebSphere ESB deployment provides automatic configuration of the underlying artifacts, the available tabs provide advanced options that enable you to provide the SIBus information (see Resources for details on the WebSphere Application Server SIBus.) In our example, we will provide a JMS import that will send a one way message to an audit system from the history module.
Web services bindings
Web services imports enable you to invoke Web services from an SCA application using the SCA programming model. A component wired to a Web service import will pass the request to an externally-defined Web service. In WebSphere Process Server, if you are using business objects, which are defined by an XSD, the parameters will be translated if the XSD of the external WSDL matches. However, unlike XSDs, WebSphere Process Server lets you to use data maps map. Figure 4 shows the Web services import screen.
Figure 4. Web services imports
For exports, you can expose your SCA components as Web services. Web service exports let you to specify the Port and Service. In addition, it will generate the additional WSDL documents, which you can give to your Web service clients.
Figure 5. Web services export
Setting up the example
To run this example, set up your workspace and load the SCA modules we built in Part 3, extending them to send a JMS audit message and invoke an external Credit Score Agency from the Credit Agency Module:
In WebSphere Integration Developer, open a new workspace and close the Welcome screen.
From the Business Integration perspective, right-click in the Business Integration view and select Import.
Figure 6. Import SCA project interchanges
Select Project Interchange from the wizard and press Next (Figure 7).
Figure 7. Select Project Interchange
Press Select All and Finish (Figure 8).
Figure 8. Select All projects
If you examine the projects in the Business Integration view, you will recognize them as the same modules we built in Part 3.
Expand the CreditApprovalSCAModule (Figure 9) and open the Assembly editor.
Figure 9. Examine CreditApproval module
When it opens, notice that the CreditApproval Module is wired to two SCA imports.
Figure 10. Credit Approval module
Examine the other modules in the Assembly area as well. (See Part 3 for more details on these modules.)
Integrating an SCA solution with JMS applications
In the following steps, we will update the CreditHistory Module to write an audit message to a JMS queue. The consumer of the message will be a message-driven bean in a Java EE application. This application will rely only on IBM Rational® Application Developer tools. In our example, we assume you have a shared shell between Rational Application Developer and WebSphere Integration Developer.
Import the existing Java EE application. Keep in mind that we are going to unit test all these applications in the same WebSphere Process Server test environment; however, the Java EE application can reside on a regular WebSphere Application Server (which would, however, limit the data type to XML, since base WebSphere Application Server would not have the business object framework.)
If you are using WebSphere Integration Developer with Rational Application Developer, you may need to enable Enterprise Java and Web Service Development support. Go to your Preferences and select Workbench => Capabilities, then select Enterprise Java and Web Service Development, as shown in Figure 11. (You cannot have a shared WebSphere Integration Developer/Rational Application Developer workspace).
Figure 11. Enable Java EE and Web Service Development support
Open the J2EE perspective and press OK (Figure 12).
Figure 12. Open J2EE perspective
From the main File Menu, select File => Import.
Select Project Interchange from the Import wizard and press Next.
Press Select All and Finish as shown in Figure 13.
Figure 13. Import Java EE Project Interchange
Examine the Java EE application. Open the deployment descriptor editor in the EJB project (Figure 14).
Figure 14. Deployment Descriptor editor
Go to the Bean tab and examine the JMS binding (Figure 15). We will bind to an activation specification per the Java EE specification (see Resources). (We will specify the destination name as part of the activation specification configuration in a later step. The destination name in the deployment descriptor serves as an overriding mechanism.)
Figure 15. Activation specification
We will now add the JMS import to the CreditHistorySCAModule:
Switch back to the Business Integration perspective. From the Business Integration view, expand the CreditHistorySCAModule and double-click the SCA Assembly (Figure 16).
Figure 16. Open SCA Assembly
Drag an Import icon onto the Assembly (Figure 17).
Figure 17. Drag import
Name the Import
JMSAuditand click the Add Interface button (Figure 18).
Figure 18. Add Interface
Select AuditHistory from the Interface wizard (Figure 19) and press OK.
Figure 19. AuditHistory interface
Right-click the JMSAudit import and select Generate Binding... => JMS Binding (Figure 20).
Figure 20. Select JMS Binding
Select Text to indicate that we will send the message as text rather than a serialized Java object.
Figure 21. Data to be sent as text
Examine the JMS binding information in the Properties view. In the Bindings section, shown in Figure 22, you can see the JMS information. Keep all the default values.
Figure 22. JMS bindings
To examine the MDB code, expand the ejbModule folder and ejbs package, as shown in Figure 23.
Figure 23. Open message-driven bean
In the onMessage method (Figure 24), see how the XML message will be printed out. (You can add your own JAXB, SDO XML generator, or other code here.)
Figure 24. MDB code
Next, we will wire the CreditHistory component to the JMS import:
Drag a wire from the CreditHistory component to the JMSAudit import (Figure 25).
Figure 25. Wire component to JMS import
Select OK and Yes in the text boxes.
Figure 26. Asynchronous invocation
Double-click the CreditHistory component to open the underlying Java implementation (Figure 27).
Figure 27. Open Java implementation
Copy the code from the CodeSnippet1.txt file (shown below) from the included download materials, and add it into the getCreditLimit method before returning the value.
// call the audit service to record the application ServiceManager sm = new ServiceManager(); System.out.println("************ getting audit history asynchronous service *********"); AuditHistoryAsync ah = (AuditHistoryAsync) sm.locateService ("AuditHistoryPartner"); System.out.println("************ calling audit history service *********"); ah.logAuditAsync(creditApp); System.out.println("************ audit history service call complete *********");
Save all your editors.
We will now configure the JMS artifacts needed to test the application:
From the Server view, right-click WebSphere Process Server and select Start.
Figure 28. Start server
Right-click and select Add and remove projects, then add CreditHistorySCAModuleApp to the Configured projects.
Figure 29. Add CreditApprovalSCAModuleApp
Right-click and select Run administrative console (Figure 30).
Figure 30. Run administrative console
From the main menu, select Default messaging (Figure 31).
Figure 31. Default messaging
Under destinations, select JMS queue (Figure 32).
Figure 32. JMS queue
JMSAuditQueuefor the Name field, and enter
jms/auditQueuefor JNDI Name. Select the queue name that matches your import and the SCA application bus (Figure 33).
Figure 33. JMS queue configuration
Create the JMS activation specification for our MDB to bind to. Select the JMS activation specification link on the default messaging page (Figure 34).
Figure 34. Select activation specification
For Name, enter
AuditName, and for JNDI name, enter
jms/AuditActSpec(this matches the activation name in the EJB deployment descriptor). Select Queue as the Destination type, enter
jms/auditQueuefor the queue JNDI name, and select your SCA application bus. Figure 35 illustrates the settings.
Figure 35. Activation specification configuration
Save your configuration, as shown in Figure 36, and close the administrative console.
Figure 36. Save configuration
Right-click the server and select Add and remove project. We can now deploy our JMSAuditTargetEAR, as shown in Figure 37.
Figure 37. Add JMSAuditTargetEAR to the server
Time to test our JMS integration:
From the assembly editor, right-click CreditHistory and select Test Component (Figure 38).
Figure 38. Test component
On the Configuration tab, remove the JMSAudit Emulator (Figure 39). (See previous articles in this series for the purpose of emulators.)
Figure 39. Remove emulators
Switch back to the Events tab, enter test data, then press Continue (Figure 40).
Figure 40. Test component
Select WebSphere Process Server v6.0 as your deployment location and press Finish (Figure 41).
Figure 41. Select WebSphere Process Server
The results should return as they did in Part 3 (Figure 42).
Figure 42. Results
We still need to verify that the JMS request made it to the consumer, examine the WebSphere console, and look for the XML message, as shown in Figure 43.
Figure 43. XML result
Invoking Web services
We will now update the CreditAgency module to invoke the external Credit Agency Web service. A Java EE 1.4 based Web service has been provided.
Import the existing Web service:
Switch back to the J2EE perspective. Import the WSTargetCreditAGency_PI.zip project interchange (Figure 44).
Figure 44. Import Web service
From the Project explorer, you will be able to examine the Web service (Figure 45).
Figure 45. Examine Web service
If you expand the WSTargetCreditAgency Web project (Figure 46), you will find the defined WSDL.
Figure 46. WSDL file
Examine the WSDL file to ensure the address matches your server as shown in the code snippet below.
<wsdl:service name="TPCreditAgencyImplService"> <wsdl:port binding="impl:TPCreditAgencyImplSoapBinding" name="TPCreditAgencyImpl"> <wsdlsoap:address location="http://localhost:9083/WSTargetCreditAgency/services/TPCreditAgencyImpl"/> </wsdl:port> </wsdl:service>
Deploy the Web service by adding it to the server (Figure 47).
Figure 47. Deploy Web service
For our SCACreditAgency module to invoke the Web service, we must create an SCA Web service import:
Switch back to the Business Integration view and open the CreditAgencySCAModule assembly editor (Figure 48).
Figure 48. Open CreditAgencySCAModule
Drag another import icon (Figure 49).
Figure 49. Drop import
Name the import
TPWImportand press the Add Interface button (Figure 50).
Figure 50. Add interface
Select TPCCreditAgencyImpl as the WSDL interface (Figure 51).
Figure 51. TPCreditAgecny
Right-click the import and select Generate Binding => Web Service Binding (Figure 52).
Figure 52. Generate Web service binding
Select the Browse button in the Binding tab of the Properties view (with Import selected), as shown in Figure 53.
Figure 53. Browse for Web service
Find the TPCCreditAgencyImpl in the Web project (Figure 54).
Figure 54. Find target WSDL
The Port and Service should now be populated, as in the Binding section, as shown in Figure 55. (Ports may vary.)
Figure 55. Port and Service
Wire the CreditAgency component to the TPWSImport (Figure 56).
Figure 56. Wire Web service import
Double-click the CreditAgency component (Figure 57).
Figure 57. CreditAgency component
Add the code below to the component. You can paste the code from the Snippet2.txt file from the included download file.
ServiceManager sm = new ServiceManager(); System.out.println("************ creating credit agency service *********"); TPCreditAgencyImpl tpca = (TPCreditAgencyImpl) sm.locateService("TPCreditAgencyImplPartner"); System.out.println("************ calling credit approval service via WS import *********"); Integer cs = tpca.getTPCreditScore(creditApp.getString("creditId")); System.out.println("************ credit approval service returned credit score = " + cs.toString() + " *********"); return cs;
Save all the editors.
We can test the solution very easily:
Add the CreditAgency module to the server as we did with the other modules.
Right-click the CreditAgency component and select Test Component.
Remove the TPWSImport emulator (Figure 58).
Figure 58. Remove the Web service emulator
Populate the data with test values and run the test (Figure 59).
Figure 59. Run component test
Examine the results, which should appear similar to Figure 60.
Figure 60. Examine test results
View the console to verify that the request went through the Web service.
Figure 61. Check test results with admin console
Create Web service client
Finally, we will expose our solution as a Web service. We will do this by creating a Web services export in the CreditApproval SCA module:
Open the CreditApprovalSCAModule:
Open the CreditApproval Assembly Editor (Figure 62).
Figure 62. Open CreditApprovalSCAModule
Drag an export onto the assembly (Figure 63).
Figure 63. Drag export
Name the export
WSCreditRequestand Add the WSDL interface.
Figure 64. WSCreditRequest
Select CreditRequest from the Interface wizard and press OK.
Press OK to generate the binding/service/port elements, which we will need (Figure 65).
Figure 65. Generate binding/service/port
Select soap/http as shown in Figure 66.
Figure 66. Select soap/http
You will notice that a brand new WSDL file has been created with the needed information to call the SCA solution using Web service technologies.
Figure 67. Generated WSDL
If you examine the WSDL file, you will notice that it actually imports the CreditRequest. Your Web service client would need both. Also, make sure you host and port match your test server.
<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="WSCreditRequest_CreditRequestHttp_Service" targetNamespace="http://CreditApproval/CreditRequest/Binding2" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:Port_0="http://CreditApproval/CreditRequest" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:this="http://CreditApproval/CreditRequest/Binding2" xmlns="http://schemas.xmlsoap.org/wsdl/"> <wsdl:import namespace="http://CreditApproval/CreditRequest" location="CreditRequest.wsdl"/> <wsdl:binding name="WSCreditRequest_CreditRequestHttpBinding" type="Port_0:CreditRequest"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="calulateCreditScore"> <soap:operation/> <wsdl:input name="calulateCreditScoreRequest"> <soap:body use="literal"/> </wsdl:input> <wsdl:output name="calulateCreditScoreResponse"> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="WSCreditRequest_CreditRequestHttpService"> <wsdl:port name="WSCreditRequest_CreditRequestHttpPort" binding="this:WSCreditRequest_CreditRequestHttpBinding"> <soap:address location="http://localhost:9083/CreditApprovalSCAModuleWeb/sca/WSCreditRequest"/> </wsdl:port> </wsdl:service> </wsdl:definitions>
In the next step, we will use the Web service client wizard tools from Rational Application Developer to generate a Java EE Web service client, but for the wizard to function, it must find both the CreditRequest WSDL and the newly generated WSDL. The easiest way to do this is to copy or move the WSDL into the CreditApprovalLibrary. This will also provide consistency of having interfaces in a shared library.
Figure 68. Move WSDL to library
Save the assembly editor.
Deploy the CreditApprovalSCAModule (Figure 69).
Figure 69. Deploy the CreditApproval module
Create a sample Java EE Web service client using the Rational Application Developer Web service wizard tools:
Switch to the J2EE perspective, then select File => New => Dynamic Web Project from the main menu.
Figure 70. Create a new dynamic project
Name the Web project
WSClientCreditApprovaland press Finish. This should create a new Dynamic Web Project and corresponding EAR project.
Select File => New from the main menu again. This time, select Web Services => Web Service Client (Figure 71), then Next.
Figure 71. Web service client
Browse to the CreditApprovalLibrary project and select WSCreditRequest_CreditRequestHttp_Service.wsdl (Figure 72).
Figure 72. Select WSDL
Select Web for client type and select the newly create Web projects (Figure 73).
Figure 73. Web client
On the last page of the wizard, choose to test the generated proxy with a sample JSP page and press Finish (Figure 74). Make sure you select the calculateCreditScore and getCreditRequest methods.
Figure 74. Generate Web pages
The application should automatically deploy and launch the Web pages in a browser. Select the CalculateCreditScoremethod, enter some test data, and test entire solution.
Figure 75. Test application and view results
This article showed how you can use JMS and Web services to integrate your SCA solutions with various types of systems. Specifically, we illustrated to the steps for binding export and imports to JMS and Web services. The SCA specification is a programming model targeted for defining integration and should make use of proven technologies like JMS and Web services. It is worth noting that the SCA versions of WebSphere Process Server and WebSphere ESB are precursors to the public specification of SCA, in which imports have been re-named as external services and exports as entry points.
In the final installment of this series, we will show you how to use more complex interactions using BPEL.
More articles in this series
- Part 1: Oh great, another programming model?
- Part 2: Assembling SCA components
- Part 3: Integrating SCA modules with imports and exports
|Code sample||SCAArticlePart4.zip ( HTTP | FTP )||49 KB|
- Service Component Architecture Specification
- Specifications: Service Component Architecture (SCA) and Service Data Objects (SDO)
- Apache Tuscany (open source implementation of SCA specification)
- WebSphere Enterprise Service Bus product information
- Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 1: Introduction to WebSphere V6 Messaging Resources
- Deploying message-driven beans and JMS applications into the Service Integration Bus
- Deploying publish and subscribe applications into the Service Integration Bus
- A practical introduction to message mediation -- Part 1: The basics of message mediation
- WebSphere Process Server: IBM's new foundation for SOA
- Introduction to Service Data Objects
- Simplified Data Access with SDO
- IBM WebSphere: Deployment and Advanced Configuration