IBM WebSphere Developer Technical Journal: Building SOA solutions with the Service Component Architecture -- Part 4

Integrating with JMS and Web services

Integrate Service Component Architecture (SCA) solutions with other systems using Java™ Message Service (JMS) and Web services, two common ways of integrating heterogenous systems -- that also enable you to solve many of the complex challenges inherent in integration.

Share:

Roland Barcia, Certified IT Specialist, EMC

Roland Barcia is a Certified IT Specialist for IBM Software Services for WebSphere in the New York/New Jersey Metro area. He is a co-author of IBM WebSphere: Deployment and Advanced Configuration. For more information on Roland, visit his Web site.



Jeff Brent (jeffb@us.ibm.com), Advisory Software Engineer, EMC

Jeff Brent is an Advisory Software Engineer for the Service Component Architecture team and Technical Lead for WebSphere Process Server SWAT from West Palm Beach, Florida. In his spare time, he enjoys spending time with his family and playing basketball.



19 April 2006

Also available in Chinese

From the IBM WebSphere Developer Technical Journal.

Introduction

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.


Integrating systems

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
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.

JMS bindings

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
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
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
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
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:

  1. In WebSphere Integration Developer, open a new workspace and close the Welcome screen.

  2. From the Business Integration perspective, right-click in the Business Integration view and select Import.

    Figure 6. Import SCA project interchanges
    Figure 6. Import SCA project interchanges
  3. Select Project Interchange from the wizard and press Next (Figure 7).

    Figure 7. Select Project Interchange
    Figure 7. Select Project Interchange
  4. Press Select All and Finish (Figure 8).

    Figure 8. Select All projects
    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.

  5. Expand the CreditApprovalSCAModule (Figure 9) and open the Assembly editor.

    Figure 9. Examine CreditApproval module
    Figure 9. Examine CreditApproval module
  6. When it opens, notice that the CreditApproval Module is wired to two SCA imports.

    Figure 10. Credit Approval module
    Figure 10. Credit Approval module
  7. 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.

  1. 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.)

    1. 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
      Figure 11. Enable Java EE and Web Service Development support
    2. Open the J2EE perspective and press OK (Figure 12).

      Figure 12. Open J2EE perspective
      Figure 12. Open J2EE perspective
    3. From the main File Menu, select File => Import.

    4. Select Project Interchange from the Import wizard and press Next.

    5. Press Select All and Finish as shown in Figure 13.

      Figure 13. Import Java EE Project Interchange
      Figure 13. Import Java EE Project Interchange
    6. Examine the Java EE application. Open the deployment descriptor editor in the EJB project (Figure 14).

      Figure 14. Deployment Descriptor editor
      Figure 14. Deployment Descriptor editor
    7. 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
      Figure 15. Activation specification
  2. We will now add the JMS import to the CreditHistorySCAModule:

    1. 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
      Figure 16. Open SCA Assembly
    2. Drag an Import icon onto the Assembly (Figure 17).

      Figure 17. Drag import
      Figure 17. Drag import
    3. Name the Import JMSAudit and click the Add Interface button (Figure 18).

      Figure 18. Add Interface
      Figure 18. Add Interface
    4. Select AuditHistory from the Interface wizard (Figure 19) and press OK.

      Figure 19. AuditHistory interface
      Figure 19. AuditHistory interface
    5. Right-click the JMSAudit import and select Generate Binding... => JMS Binding (Figure 20).

      Figure 20. Select JMS Binding
      Figure 20. Select JMS Binding
    6. 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
      Figure 21. Data to be sent as text
    7. 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
      Figure 22. JMS bindings
  3. To examine the MDB code, expand the ejbModule folder and ejbs package, as shown in Figure 23.

    Figure 23. Open message-driven bean
    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
    Figure 24. MDB code
  4. Next, we will wire the CreditHistory component to the JMS import:

    1. Drag a wire from the CreditHistory component to the JMSAudit import (Figure 25).

      Figure 25. Wire component to JMS import
      Figure 25. Wire component to JMS import
    2. Select OK and Yes in the text boxes.

    3. Select the reference and create an Asynchronous invocation qualifier, as shown in Figure 26. (See Part 2 and Part 3 for more information on qualifiers.)

      Figure 26. Asynchronous invocation
      Figure 26. Asynchronous invocation
    4. Double-click the CreditHistory component to open the underlying Java implementation (Figure 27).

      Figure 27. Open Java implementation
      Figure 27. Open Java implementation
    5. 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 *********");
    6. Save all your editors.

  5. We will now configure the JMS artifacts needed to test the application:

    1. From the Server view, right-click WebSphere Process Server and select Start.

      Figure 28. Start server
      Figure 28. Start server
    2. Right-click and select Add and remove projects, then add CreditHistorySCAModuleApp to the Configured projects.

      Figure 29. Add CreditApprovalSCAModuleApp
      Figure 29. Add CreditApprovalSCAModuleApp
    3. Right-click and select Run administrative console (Figure 30).

      Figure 30. Run administrative console
      Figure 30. Run administrative console
    4. From the main menu, select Default messaging (Figure 31).

      Figure 31. Default messaging
      Figure 31. Default messaging
    5. Under destinations, select JMS queue (Figure 32).

      Figure 32. JMS queue
      Figure 32. JMS queue
    6. Enter JMSAuditQueue for the Name field, and enter jms/auditQueue for JNDI Name. Select the queue name that matches your import and the SCA application bus (Figure 33).

      Figure 33. JMS queue configuration
      Figure 33. JMS queue configuration
    7. 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
      Figure 34. Select activation specification
    8. 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/auditQueue for the queue JNDI name, and select your SCA application bus. Figure 35 illustrates the settings.

      Figure 35. Activation specification configuration
      Figure 35. Activation specification configuration
    9. Save your configuration, as shown in Figure 36, and close the administrative console.

      Figure 36. Save configuration
      Figure 36. Save configuration
    10. 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
      Figure 37. Add JMSAuditTargetEAR to the server
  6. Time to test our JMS integration:

    1. From the assembly editor, right-click CreditHistory and select Test Component (Figure 38).

      Figure 38. Test component
      Figure 38. Test component
    2. 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
      Figure 39. Remove emulators
    3. Switch back to the Events tab, enter test data, then press Continue (Figure 40).

      Figure 40. Test component
      Figure 40. Test component
    4. Select WebSphere Process Server v6.0 as your deployment location and press Finish (Figure 41).

      Figure 41. Select WebSphere Process Server
      Figure 41. Select WebSphere Process Server
    5. The results should return as they did in Part 3 (Figure 42).

      Figure 42. Results
      Figure 42. Results
    6. 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
      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.

  1. Import the existing Web service:

    1. Switch back to the J2EE perspective. Import the WSTargetCreditAGency_PI.zip project interchange (Figure 44).

      Figure 44. Import Web service
      Figure 44. Import Web service
    2. From the Project explorer, you will be able to examine the Web service (Figure 45).

      Figure 45. Examine Web service
      Figure 45. Examine Web service
    3. If you expand the WSTargetCreditAgency Web project (Figure 46), you will find the defined WSDL.

      Figure 46. WSDL file
      Figure 46. WSDL file
    4. 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>
    5. Deploy the Web service by adding it to the server (Figure 47).

      Figure 47. Deploy Web service
      Figure 47. Deploy Web service
  2. For our SCACreditAgency module to invoke the Web service, we must create an SCA Web service import:

    1. Switch back to the Business Integration view and open the CreditAgencySCAModule assembly editor (Figure 48).

      Figure 48. Open CreditAgencySCAModule
      Figure 48. Open CreditAgencySCAModule
    2. Drag another import icon (Figure 49).

      Figure 49. Drop import
      Figure 49. Drop import
    3. Name the import TPWImport and press the Add Interface button (Figure 50).

      Figure 50. Add interface
      Figure 50. Add interface
    4. Select TPCCreditAgencyImpl as the WSDL interface (Figure 51).

      Figure 51. TPCreditAgecny
      Figure 51. TPCreditAgecny
    5. Right-click the import and select Generate Binding => Web Service Binding (Figure 52).

      Figure 52. Generate Web service binding
      Figure 52. Generate Web service binding
    6. 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
      Figure 53. Browse for Web service
    7. Find the TPCCreditAgencyImpl in the Web project (Figure 54).

      Figure 54. Find target WSDL
      Figure 54. Find target WSDL
    8. 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
      Figure 55. Port and Service
    9. Wire the CreditAgency component to the TPWSImport (Figure 56).

      Figure 56. Wire Web service import
      Figure 56. Wire Web service import
    10. Double-click the CreditAgency component (Figure 57).

      Figure 57. CreditAgency component
      Figure 57. CreditAgency component
    11. 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;
    12. Save all the editors.

  3. We can test the solution very easily:

    1. Add the CreditAgency module to the server as we did with the other modules.

    2. Right-click the CreditAgency component and select Test Component.

    3. Remove the TPWSImport emulator (Figure 58).

      Figure 58. Remove the Web service emulator
      Figure 58. Remove the Web service emulator
    4. Populate the data with test values and run the test (Figure 59).

      Figure 59. Run component test
      Figure 59. Run component test
    5. Examine the results, which should appear similar to Figure 60.

      Figure 60. Examine test results
      Figure 60. Examine test results
    6. View the console to verify that the request went through the Web service.

      Figure 61. Check test results with admin console
      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:

  1. Open the CreditApprovalSCAModule:

    1. Open the CreditApproval Assembly Editor (Figure 62).

      Figure 62. Open CreditApprovalSCAModule
      Figure 62. Open CreditApprovalSCAModule
    2. Drag an export onto the assembly (Figure 63).

      Figure 63. Drag export
      Figure 63. Drag export
    3. Name the export WSCreditRequest and Add the WSDL interface.

      Figure 64. WSCreditRequest
      Figure 64. WSCreditRequest
    4. Select CreditRequest from the Interface wizard and press OK.

    5. Press OK to generate the binding/service/port elements, which we will need (Figure 65).

      Figure 65. Generate binding/service/port
      Figure 65. Generate binding/service/port
    6. Select soap/http as shown in Figure 66.

      Figure 66. Select soap/http
      Figure 66. Select soap/http
    7. 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
      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>
    8. 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
      Figure 68. Move WSDL to library
    9. Save the assembly editor.

    10. Deploy the CreditApprovalSCAModule (Figure 69).

      Figure 69. Deploy the CreditApproval module
      Figure 69. Deploy the CreditApproval module
  2. Create a sample Java EE Web service client using the Rational Application Developer Web service wizard tools:

    1. Switch to the J2EE perspective, then select File => New => Dynamic Web Project from the main menu.

      Figure 70. Create a new dynamic project
      Figure 70. Create a new dynamic project
    2. Name the Web project WSClientCreditApproval and press Finish. This should create a new Dynamic Web Project and corresponding EAR project.

    3. 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
      Figure 71. Web service client
    4. Browse to the CreditApprovalLibrary project and select WSCreditRequest_CreditRequestHttp_Service.wsdl (Figure 72).

      Figure 72. Select WSDL
      Figure 72. Select WSDL
    5. Select Web for client type and select the newly create Web projects (Figure 73).

      Figure 73. Web client
      Figure 73. Web client
    6. 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
      Figure 74. Generate Web pages
    7. 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
      Figure 75. Test application and view results

Conclusion

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


Download

DescriptionNameSize
Code sampleSCAArticlePart4.zip  ( HTTP | FTP )49 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere, SOA and web services, Architecture
ArticleID=108899
ArticleTitle=IBM WebSphere Developer Technical Journal: Building SOA solutions with the Service Component Architecture -- Part 4
publish-date=04192006