Contents


Integrating IBM Integration Bus with WebSphere Service Registry and Repository

Part 1: Scenarios and configuration

Comments

Content series:

This content is part # of # in the series: Integrating IBM Integration Bus with WebSphere Service Registry and Repository

Stay tuned for additional content in this series.

This content is part of the series:Integrating IBM Integration Bus with WebSphere Service Registry and Repository

Stay tuned for additional content in this series.

IBM Integration Bus is an enterprise service bus (ESB) that provides connectivity and universal data transformation for SOA and non-SOA environments. WebSphere Service Registry and Repository (WSRR) is a central point of reference for service metadata, including service definition documents such as WSDL, XSD, and WS-Policy documents.

Integrating WSRR with IBM Integration Bus enables message flows to access the metadata associated with services registered in WSRR at runtime, allowing for dynamic connectivity between service consumers and service providers. IBM Integration Bus can also dynamically retrieve resources from WSRR at runtime to be used in message flow processing. This process lets you defer decisions about which artifacts you want to use within a message flow until runtime, rather than making the decision at deployment time, avoiding the need to build and redeploy the message flow if the artifacts change.

For example, target endpoints do not need to be predefined in your message flow, because they can be retrieved dynamically from WSRR at runtime. Therefore you can deploy a message flow and govern its routing and transformations dynamically by updating the service metadata in WSRR. For more information on the Endpoint Lookup and Registry Lookup nodes, see Part 2.

Business scenarios

The example message flows that are described by the articles in this series can be used to address a number of business scenarios. These scenarios are described in the sections that follow:

Service location

ESBs have provided the ability to decouple service consumers from service providers for some time. In reality, however, the problem of needing to know the location of the target service was simply moved from the service consumer to the ESB.

  • Business problem

    Message flows that act as proxies for other services, or invoke other services at runtime, need to know the location, or endpoints, of these services. The location of the services could be hard coded into each message flow but this makes them vulnerable to changes in your environment. For example, if the location of any of the services that are invoked changes, the affected message flows will need to be updated with the new locations and redeployed. It might also be necessary to modify the location of the services that are invoked by each message flow as they move through various environments during the development process.

  • Solution

    The locations of the invoked services can be registered in WSRR and retrieved dynamically by the message flows at runtime. If the location of a service changes for some reason, it is a simple task to update the endpoint that is registered in WSRR so that any affected message flows can route requests to the service at its new location.

  • Benefits

    This approach reduces the impact of changes that are made to the location of services, both in terms of impact to the message flows and in terms of system management. It also allows for substitution of one service provider for another without the service consumer being aware of the change or without needing to alter the architecture to support the substitution.

Almost all of the sample flows that are provided with this series retrieve endpoints from WSRR dynamically at runtime. Dynamic routing is discussed in detail in Part 3, Endpoint Lookup Scenarios.

Service selection

The service selection scenario is an extension to the service location scenario described previously and arises when multiple implementations of a target service are available.

  • Business Problem

    An interface for a Stock Quote service has been defined, but three implementations have been deployed. One implementation returns up-to-date stock quotes and should only be used by Gold customers. Another implementation returns quotes that are 5 minutes old and should only be used by Silver customers. The final implementation returns quotes that are 20 minutes old and should only be used by Bronze customers. Consumers of the stock quote service want to be able to invoke it using a single endpoint.

  • Solution

    The endpoints of the all three services can be registered in WSRR and additional metadata can be associated with each endpoint. For example, in the scenario described previously, you might define a custom ontology in WSRR that allows you to classify each endpoint as Gold , Silver or Bronze. When the endpoints are retrieved by a message flow at runtime, the metadata is also returned to IBM Integration Bus. This metadata can then be used by the message flow to decide which endpoint the request should be routed to, probably in conjunction with some information available on the original request or contextual information available in the ESB.

  • Benefits

    This approach enables you to select between multiple service providers at runtime based on metadata about those providers. The routing decision could be influenced by information that is available in the original request, which is sometimes referred to as content based routing. Alternatively, the decision could be entirely based on the metadata about the target endpoints. For example, a monitoring component in your environment could be pushing performance metrics into WSRR and the message flow could decide to route the request to the endpoint with the lowest average response time.

Because this scenario is an extension of the service selection scenario, it is also discussed in detail in Part 3: Endpoint lookup scenarios.

Alternate service provider

The alternate service provider is an extension to the service selection scenario described previously.

  • Business Problem

    Multiple endpoints are available for a target service, but an error occurs when attempting to invoke the selected endpoint. Consumers of the service only know the endpoint of the message flow that is proxying the service. They expect the ESB to be able to handle routing requests around problem endpoints transparently.

  • Solution

    All of the endpoints for the target service can be registered in WSRR and retrieved by the message flow in a single query. If an error occurs when attempting to invoke the target service on the selected endpoint, the message flow can simply select one of the other endpoints for the service and retry. The message flow can continue this process until the request is successful or all of the service endpoints have been tried.

  • Benefits

    This approach enables you to build a level of fault tolerance into your ESB by allowing the ESB to transparently route service requests around problem endpoints. You might decide to allow message flows to try all of the available endpoints for a service or, alternatively, you might decide to limit the number of endpoints that are attempted before returning an error to the service consumer. Obviously, any fault tolerance built into the ESB must be designed to work in conjunction with other high availability mechanisms in use in your environment.

Because this scenario is an extension of the service selection scenario, it is also discussed in detail in Part 3: Endpoint lookup scenarios.

Service transformation

Another capability that is typically offered by ESBs is the ability to transform message formats between the service consumer and the service provider. Typically, interfaces and operations of disparate services are not identical. The ESB can transform the message from the source format into a format that can be accepted by the target service.

  • Business Problem

    A new version of a service has been implemented that is not backwards compatible with previous versions. You want to take the older versions of the service offline to free up resources, but you do not want to break the consumers of those versions or force them to update their implementations.

  • Solution

    All of the versions of the service can be registered in WSRR and additional metadata can be associated with each service. For example, in the scenario described previously, you might define XSL transformations that can convert service requests for older versions of the service to the format required by the latest version (and the reverse transformations for the service responses). These XSL transformations can be loaded into WSRR and associated with the relevant services. They can then be retrieved by a message flow at runtime and applied to the messages flowing across the ESB.

  • Benefits

    This approach enables you to transparently route service requests intended for earlier versions of a service to a later version of the service. This allows you take the earlier versions of the service offline, freeing up the resources that they would otherwise consume. It also allows you to store the XSL transformations in WSRR and retrieve them dynamically at runtime, avoiding the need to build and redeploy the message flow if they change.

The service transformation scenario is discussed in detail in Part 4, Service Transformation.

Service gateway

The SOAP nodes in IBM Integration Bus can be operate in gateway mode. When configured to work in gateway mode, the nodes are not configured to use a specific WSDL file and are able to handle generic SOAP messages.

  • Business Problem

    You have a number of services that you want to apply some common processing to at the ESB level. You do not want to have to build and deploy a separate flow to proxy each back-end service to achieve this.

  • Solution

    By using a SOAP Input node in gateway mode, no service specific validation is performed on the SOAP messages that are received by that node. This enables you to implement a message flow that can handle service requests for several different back end services. Such a message flow can then provide some common functionality that is applied to all of the service requests that it processes, such as authorization, logging and so on. To route the service requests to the back end services the message flow can retrieve the endpoints from WSRR.

  • Benefits

    This approach enables you to implement common processing logic in a single place, reducing the overall development and test effort by simplifying the process of routing, monitoring, logging, versioning and securing service requests for multiple services. It also simplifies the process of invoking the target services because the service consumers only need to know a single endpoint.

The service gateway scenario is discussed in detail in Part 6: Service Gateway.

SLA checking

Service Level Agreements (SLAs) in WSRR are agreements between service providers and service consumers. They can be enforced by ESBs at runtime when processing requests to ensure that the service consumer is authorized to invoke the target service.

  • Business Problem

    You have a number of services deployed in your SOA and they are all registered in WSRR. You have not, however, registered the consumers of those services in WSRR. As a consequence you do not know which service consumers might be invoking each service at any given point in time. You want to ensure that all of the service consumers in your SOA are registered in WSRR and that only consumers who are authorized to invoke a target service are allowed to do so.

  • Solution

    WSRR allows you to register the service consumers in your SOA, as well as service providers. It also enables the agreements, or contracts, that exist between service providers and service consumers to be represented using Service Level Agreements (SLAs). A message flow can retrieve this information from WSRR dynamically at runtime and use it to determine whether a service consumer is authorized to invoke a target service. If the service consumer is authorized to invoke the target service it can forward the request on to the agreed endpoint. If the service consumer is not authorized to invoke the target service a suitable error can be returned.

  • Benefits

    This approach allows you to control which service consumers are invoking the actual back end services, enabling you to enforce a level of runtime governance in your SOA. An added benefit is that, after the service consumers and providers are registered in WSRR, you can visualize these relationships in the Service Registry Dashboard user interface and use it to assess the impact of any changes that you are planning to make to your service.

The SLA checking scenario is discussed in two articles in this series. Part 5: Performing SLA checks at runtime shows you how to implement this functionality using the Registry Lookup node, while Part 8: SLA Checking using the HTTP Request Node shows you how to implement it using the HTTP Request node to invoke the WSRR REST API.

Policy enforcement

In addition to enabling you to register service providers and service consumers, WSRR also enables you to load policies and attach them to services. Used in this manner, WSRR becomes a central point of reference for both services and policies in your SOA.

  • Business Problem

    You have service enabled a number of existing applications on legacy systems to make them available in new environments. However, these applications are still accessed through other channels such as native interfaces and messaging applications through WebSphere MQ. To ensure that existing consumers of these applications are not adversely impacted by requests coming in over the web service interface, you would like to be able to specify a limit on the volume of traffic that can be handled over this interface.

  • Solution

    IBM Integration Bus allows you to control the rate of processing within a message flow by attaching WLM policies to the flow. WLM policies enable you to increase, decrease or simply monitor the rate at which a message flow processes messages. A single WLM policy can be attached to multiple message flows. A WLM policy can also be updated at runtime and does not require any message flows to be restarted in order for the changes to take effect.

    IBM Integration Bus WLM policies are defined using WS-Policy, allowing them to be loaded and centrally managed in WSRR along with other types of WS-Policy that you use in your SOA. By registering your flows in WSRR and attaching WLM policies to them you can dynamically control the volume of traffic allowed through the flow in IBM Integration Bus at runtime.

  • Benefits

    This approach allows you control the volume of traffic passing through your message flows while still enabling you to centrally manage your services and policies in WSRR, giving you a single view onto the services in your SOA and the policies that apply to them.

The policy enforcement scenario is discussed in detail in Part 9, IBM Integration Bus WLM Policy Integration.

Basic IBM Integration Bus configuration

Message flows in IBM Integration Bus can depend on external services, such as WSRR. The properties that relate to these external services are defined using configurable services in IBM Integration Bus. Instead of defining properties on a node in a message flow you can create configurable services so that message flow nodes can refer to them to find properties at run time. Most of the properties that control the interaction between IBM Integration Bus and WSRR are encapsulated in the DefaultWSRR configurable service object. You can use the mqsireportproperties command to display the current properties for the DefaultWSRR configurable service object:

mqsireportproperties command
mqsireportproperties <BROKER_NAME>
                     -c ServiceRegistries
                     -o DefaultWSRR
                     -r

Where:

  • <BROKER_NAME> is the name of the broker (Integration Node).

An example of the output from this command is shown below:

mqsireportproperties output
ServiceRegistries
  DefaultWSRR
    connectionFactoryName='jms/SRConnectionFactory'
    connectionTimeout='180'
    enableCacheNotification='false'
    endpointAddress='http://my.wsrr.host:9080/WSRRCoreSDO/services/WSRRCoreSDOPort'
    initialContextFactory='com.ibm.websphere.naming.WsnInitialContextFactory'
    locationJNDIBinding='iiop://fill.in.your.host.here:2809/'
    needCache='false'
    predefinedCacheQueries=''
    refreshQueriesAfterNotification='true'
    subscriptionTopic='jms/SuccessTopic'
    timeout='100000000'

Modifying the DefaultWSRR configurable service

The Endpoint Lookup and Registry Lookup nodes in IBM Integration Bus communicate with WSRR using the WSRR web service API. To do this, configure IBM Integration Bus with the endpoint address of the WSRR web service API by setting the endpointAddress property on the DefaultWSRR configurable service object. However, WSRR exposes multiple endpoints for the web service API to maintain backwards compatibility with previous versions of the product. Each version-specific endpoint that is exposed has a unique URL suffix. For more information on these URLs, see Web service interface URLs in the WSRR V8 documentation in IBM Knowledge Center.

The value specified for the endpointAddress property must be one of the compatibility URLs supported by IBM Integration Bus. Here are the supported compatibility URLs for IBM Integration Bus V9:

WSRR Compatibility URLs Supported by IIB
WSRR VersionURL Suffix
6.1/WSRR6_1/services/WSRRCoreSDOPort
6.2/WSRR6_2/services/WSRRCoreSDOPort
6.3/WSRR6_3/services/WSRRCoreSDOPort

To set the value of the endpointAddress property on the DefaultWSRR configurable service object, you need to use the mqsichangeproperties command:

Configuring the Endpoint Address
mqsichangeproperties <BROKER_NAME>
                     -c ServiceRegistries
                     -o DefaultWSRR
                     -n endpointAddress
                     -v <WSRR_ENDPOINT_URL>

Where:

  • <BROKER_NAME> is the name of the broker (Integration Node).
  • <WSRR_ENDPOINT_URL> is the fully qualified URL of the endpoint for the WSRR web service API, for example https://localhost:9443/WSRR6_3/services/WSRRCoreSDOPort.

To optimize the interaction between IBM Integration Bus and WSRR at runtime, the Endpoint Lookup and Registry Lookup nodes store the results of the queries that they issue in a cache. Use the WSRR cache in IBM Integration Bus in production environments for performance reasons. However, in development environments, disable the WSRR cache. This enables you to test the impact of any changes to the metadata in WSRR on your message flows immediately, without the need to wait for the WSRR cache to be updated. The WSRR cache is described in detail in Part 7, Configuring the WSRR Cache in IBM Integration Bus. To disable the WSRR cache, you need to use the mqsichangeproperties command:

Disabling the WSRR Cache
mqsichangeproperties <BROKER_NAME>
                     -c ServiceRegistries
                     -o DefaultWSRR
                     -n needCache
                     -v false

Where:

  • <BROKER_NAME> is the name of the broker (Integration Node).

Configuring IBM Integration Bus to access a secure WSRR instance

In a typical production environment, application security is enabled in the WebSphere Application Server cell hosting WSRR. There are two implications of this for clients that attempt to access a secure WSRR instance:

  • Users attempting to access WSRR in such an environment must be authenticated. After a user is authenticated, WSRR determines which resources the user is allowed to access by evaluating any access control permissions that apply. This statement is true regardless of whether the user is attempting to access WSRR using a browser based user interface, such as the Service Registry Dashboard, or one of the programmatic interfaces, such as the WSRR web service API.
  • The communication between the client and the WSRR instance must take place over an encrypted channel, such as HTTPS.

Specifying the WSRR user ID and password

Any message flow running in IBM Integration Bus that attempts to access a secure WSRR instance must provide a user ID and password. If the message flow is using the Endpoint Lookup or Registry Lookup nodes then the credentials that are passed to WSRR are configured in IBM Integration Bus using the mqsisetdbparms command. If the message flow is using an HTTP Request node to invoke the WSRR REST API, the user ID and password can be specified programmatically using a compute node within the flow. This approach is described in detail in Part 8: SLA Checking using the HTTP Request Node.

Specifying the WSRR User ID and Password
mqsisetdbparms <BROKER_NAME>
               -n DefaultWSRR::WSRR
               -u <USER_ID>
               -p <PASSWORD>

Where:

  • <BROKER_NAME> is the name of the broker (Integration Node).
  • <USER_ID> is the id of a user who is authorized to access the required artifacts in WSRR.
  • <PASSWORD> is the password for this user.

Extracting the WSRR signer certificate

When IBM Integration Bus attempts to communicate with a secure WSRR instance an SSL handshake takes place to establish a secure connection. For the SSL handshake to succeed IBM Integration Bus must, at a minimum, trust the target WSRR instance. This is achieved by extracting the signer certificate for the target WSRR instance and adding it to the truststore used by IBM Integration Bus. The steps that follow describe how to extract the signer certificate for the target WSRR instance using either Firefox or Internet Explorer:

Using Firefox:

  1. Enter the endpoint address for the WSRR Web Service API that you configured in previously. For example: https://localhost:9443/WSRR6_3/services/WSRRCoreSDOPort
  2. Enter the user ID and password that you configured in previously. You should see a page like this:
    WSRR web service API hello
    WSRR Web Service API Hello
    WSRR Web Service API Hello
  3. Right-click the page and select View Page Info.
  4. On the Security tab, click View Certificate.
  5. Switch to the Details tab and click Export.
  6. Give the certificate a suitable name and select the type (such as DER). Click Save.

Using Internet Explorer:

  1. Ensure that Protected Mode is off: Go to Tools => Internet options => Security and uncheck Enable Protected Mode.
  2. Enter the endpoint address for the WSRR Web Service API that you configured in previously, for example https://localhost:9443/WSRR6_3/services/WSRRCoreSDOPort.
  3. Enter the user ID and password that you configured in previously. You should see a page similar to that shown in previously.
  4. Right click the page, select Properties, and then click Certificates.
  5. Go to the Details tab and click Copy to file. Follow the directions given by the Certificate Export Wizard.

Creating the IBM Integration Bus truststore

IBM Integration Bus does not provide or create any keystores out of the box. You need to create them manually during the process of securing IBM Integration Bus and its communications with other servers in your environment. For more information on creating a keystore using the gsk7cmd command-line tool, see Setting up a public key infrastructure in the IBM Integration Bus V9 documentation in IBM Knowledge Center. The steps below show how to create a keystore using the IBM Key Management graphical tool provided with IBM Integration Bus. If you already have a keystore created in your IBM Integration Bus environment, you can skip these steps.

  1. Open a command window.
  2. Start the IBM Key Management tool using either the strmqikm command or by navigating to the <IIB_INSTALL>/jre17/bin directory and running the ikeyman command directly.
  3. The IBM Key Management window will be displayed. Click Key Database File => New.
  4. The New dialog will be displayed. Specify a Key database type of JKS and a suitable value for the File Name and Location. The dialog should look similar to this:
    Creating a new Key Database File
    Creating a new Key Database File
    Creating a new Key Database File
  5. Click OK.
  6. The Password Prompt dialog will be displayed. Specify the password that will be used to secure access to the key database file and confirm it.
  7. Click OK.

Importing the WSRR signer certificate

The steps that follow describe how to import the WSRR signer certificate into your IBM Integration Bus truststore using the IBM Key Management tool that is provided with IBM Integration Bus.

  1. Open a command window.
  2. Start the IBM Key Management tool using either the strmqikm command or by navigating to the <IIB_INSTALL>/jre17/bin directory and running the ikeyman command directly.
  3. The IBM Key Management window will be displayed. Click Key Database File => Open.
  4. The Open dialog will be displayed. Specify a Key database type of JKS then click Browse.
  5. Navigate to, and select, your IBM Integration Bus truststore and then click Open.
  6. Click OK.
  7. The Password Prompt dialog will be displayed. Enter the password for your IBM Integration Bus truststore.
  8. Click OK.
  9. In the Key database content section of the window, select Signer Certificates in the drop down.
  10. Click Add....
  11. The Open dialog will be displayed. Click Browse....
  12. Navigate to and select the file that contains the WSRR signer certificate that you extracted earlier. Click OK.
  13. The Enter a Label dialog will be displayed. Enter a label that will be used to identify the WSRR signer certificate in the truststore.
  14. Click OK.
  15. The WSRR signer certificate will be added to the list of signer certificates in the trust with the label that you specified. The IBM Key Management window should look similar to this:
    IBM Integration Bus truststore
    IBM Integration Bus truststore
    IBM Integration Bus truststore
  16. Close the IBM Key Management tool.

Configuring the IBM Integration Bus truststore

Now that you have a keystore that contains the signer certificate for your WSRR server, you need to configure IBM Integration Bus to use that keystore. The location of the keystores used by IBM Integration Bus are configured on the BrokerRegistry object using the mqsichangeproperties command:

Specifying the location of the truststore
mqsichangeproperties <BROKER_NAME>
                     -o BrokerRegistry
                     -n brokerTruststoreFile
                     -v <TRUST_STORE_FILE>

Where:

  • <BROKER_NAME> is the name of the broker (Integration Node).
  • <TRUST_STORE_FILE> is the full path to truststore file.

For IBM Integration Bus to open the keystore file and access the certificates that it contains, you must provide it with the password. This is configured the mqsisetdbparms:

Specifying the Key truststore Password
mqsisetdbparms <BROKER_NAME>
               -n brokerTruststore::password
               -u dummy
               -p <PASSWORD>

Where:

  • <BROKER_NAME> is the name of the broker (Integration Node).
  • <PASSWORD> is the password for the truststore that has been configured in IBM Integration Bus.

You have now completed the configuration of the connection between IBM Integration Bus and WSRR.

Importing and building the sample flows

The sample flows that accompany the articles in this series are provided in the WSRRIntegrationDemos.zip archive available in the Downloadable resources section. The flows include two versions of the Math Service. This service performs basic arithmetic operations and returns the results to the client. The remainder of the flows consume the Math Service, demonstrating various aspects of the integration that is possible between IBM Integration Bus and WSRR. To deploy these flows to IBM Integration Bus you first need to import them into an IBM Integration Toolkit workspace and build them into a BAR file. The sections that follow describe how to perform these tasks.

Importing the sample flows in IBM Integration Toolkit

The first step is to import the sample flows contained in the archive into an IBM Integration Toolkit workspace. To do this you need to perform the following steps:

  1. Open IBM Integration Toolkit.
  2. Select File => Import...
  3. The Import dialog will be displayed. Expand the General folder and select Existing Projects into Workspace, then click Next >.
  4. On the next panel, select the Select archive file radio button and then click Browse...
  5. Navigate to the directory that contains the WSRRIntegrationDemos.zip archive that is provided with this article.
  6. Double click the WSRRIntegrationDemos.zip archive.
  7. In the Import dialog, ensure that all of the projects listed are selected (BARFiles, WSRRIntegrationDemos and WSRRIntegrationDemosJava). The Import dialog should look similar to this:
    Import Dialog
    Import Dialog
    Import Dialog
  8. Click Finish.

Modifying the Java project build path

The WSRRIntegrationDemosJava project that has been imported into your workspace may have a number of compile errors. This is due to the fact that the com.ibm.mq.jar and ConfigManagerProxy.jar files that have been added to the Java Build Path for this project might be in a different location in your environment. If your WSRRIntegrationDemosJava project has compile errors, you will need to modify the Java Build Pathin order for it to compile. To do this you need perform the following steps:

  1. In IBM Integration Toolkit, open the Java perspective.
  2. Right-click the WSRRIntegrationDemosJava project.
  3. In the context menu that is displayed, select Build Path => Configure Build Path....
  4. The Properties for WSRRIntegrationDemosJava dialog will be displayed with Java Build Path selected in the left panel. In the right panel, select the Libraries tab.
  5. Select the com.ibm.mq.jar file from the list and click Edit...
  6. The Edit JAR dialog will be displayed. Navigate to the <MQ_INSTALL_DIR>/java/lib directory. Select com.ibm.mq.jar, and click Ok.
  7. Select the ConfigManagerProxy.jar from the list and click Edit.
  8. The Edit JAR dialog will be displayed. Navigate to the <IIB_INSTALL_DIR>/classes directory. Select ConfigManagerProxy.jar, and click Ok.
  9. In the Properties for WSRRIntegrationDemosJava dialog, click Ok.

Building the sample flows in IBM Integration Toolkit

Now you need to build the sample flows in IBM Integration Toolkit. To do this you need perform the following steps:

  1. Open the Integration Development perspective.
  2. In the Application Development view, expand BARs and double-click WSRRIntegrationDemos.bar:
    Opening the BAR file
    Opening the BAR file
    Opening the BAR file
  3. The file will be opened in the Broker Archive Editor. Select the Prepare tab at the bottom of the editor.
  4. Click Build and Save...:
    Building the BAR file
    Building the BAR file
    Building the BAR file
  5. A progress dialog is displayed while IBM Integration Toolkit builds the BAR file. When the process is complete, you see the message Operation completed successfully. Click OK.

Deploying the sample flows to IBM Integration Bus

Now you need to deploy the BAR file to IBM Integration Bus. Fortunately, this process is simple.

  1. Ensure that the target IBM Integration Bus instance is running.
  2. Open the Integration Development perspective.
  3. In the Application Development view, expand BARs and right-click WSRRIntegrationDemos.bar.
  4. In the context menu that is displayed, click Deploy...
  5. The Deploy dialog will be displayed. Select the Integration Server to which the BAR file should be deployed, as shown in the following example:
    Deploying the BAR file
    Deploying the BAR file
    Deploying the BAR file
  6. Click Finish.
  7. A progress dialog will be displayed while the BAR file is being deployed. When the process is complete, the progress dialog closes automatically. If it does not, click Close.

Importing the test data into WSRR

Before testing any of the sample flows, you need to import a set of test data into your WSRR instance. This test data contains a representation of both the Math Service and an application that consumes this service, called the Calculator Application. The consumption relationship is captured in a Service Level Agreement that is also included in the test data. shows a high level view of this relationship in the test data.

Test Data
Test Data
Test Data

To import the test data into WSRR, perform the following steps:

  1. Open a command window.
  2. Navigate to the <WAS_INSTALL_ROOT>/WSRR/admin/scripts_cell directory.
  3. If your WSRR instance is running on a WebSphere Application Server cluster execute the following command:
    <WAS_INSTALL_ROOT>/bin/wsadmin.sh -f importMetadata.jacl 
        -user <USER_ID>
        -password <PASSWORD>
        -cluster <CLUSTER_NAME>
        -filepath <FILE_PATH>
        -filename MathServiceExport.zip

    If your WSRR instance is not running on a WebSphere Application Server cluster execute the following command:

    <WAS_INSTALL_ROOT>/bin/wsadmin.sh -f importMetadata.jacl 
        -user <USER_ID>
        -password <PASSWORD>
        -cell <CELL_NAME>
        -node <NODE_NAME>
        -server <SERVER_NAME>
        -filepath <FILE_PATH>
        -filename MathServiceExport.zip

    Where:

    • <USER_ID> is the id of a WSRR administrator.
    • <PASSWORD> is the password for this user.
    • <CLUSTER_NAME> is the name of the WAS cluster.
    • <CELL_NAME> is the name of the WAS cell.
    • <NODE_NAME> is the name of the WAS node.
    • <SERVER_NAME> is the name of the WAS server.
    • <FILE_PATH> is the path to the MathServiceExport.zip file. Forward slashes should be used as path separators regardless of what platform you are executing the command on.

    An example of using the command is shown below:

    # /opt/IBM/WebSphere/AppServer/profiles/WSRRSrv01/bin/wsadmin.sh
        -f importMetadata.jacl
        -user wasadmin
        -password passw0rd
        -cell halberdNode01Cell
        -node halberdNode01
        -server server1
        -filepath /root 
        -filename MathServiceExport.zip
  4. The test data will be imported into the target WSRR instance. You should see the following messages at the end of the console output in your command window:
    The entities with the following URIs were imported:
    [7c94a07c-1917-47ce.bc0a.95e874950a25, 72c3c072-56f7-4735.ba18.3afa1b3a1858]
    > ServiceRegistryRepository#importMetaData imported URIs:
    >> 7c94a07c-1917-47ce.bc0a.95e874950a25
    >> 72c3c072-56f7-4735.ba18.3afa1b3a1858
    > ServiceRegistryRepository#importMetaData completed, successfully.

Modifying the endpoint in the test ata

The test data supplied with the articles in this series assumes that your IBM Integration Bus instance is configured to listen for HTTP requests on the default port (7800). If this is not the case, you will need to modify the endpoint WSDL document to specify the correct port and then upload the modified document to WSRR, replacing the content of the existing document. You can use the mqsireportproperties command to check the port that is currently configured:

Checking the HTTPConnector port
mqsireportproperties <BROKER_NAME>
                     -e <EXECUTION_GROUP_NAME> 
                     -o HTTPConnector
                     -n port

Where:

  • <BROKER_NAME> is the name of the broker (Integration Node).
  • <EXECUTION_GROUP_NAME> is the name of the broker (Integration Node).

If the port number shown when executing this command is not 7800, you will need to complete the following steps to modify the endpoint WSDL document and load it into WSRR:

  1. Open IBM Integration Toolkit.
  2. Open the Integration Development perspective.
  3. In the Application Development view, expand WSRRIntegrationDemos => WSDL Definitions -> http://math.pot.ibm.com and double-click MathServerService_EP1.wsdl:
    Opening the WSDL file
    Opening the WSDL file
    Opening the WSDL file
  4. The file will be opened in the WSDL Editor. Specify the correct port number in the URL for the location attribute.
  5. Save your changes to the file.
  6. In a Web browser, log on the the Service Registry Dashboard for your WSRR instance.
  7. Change to the Development view and then select the Overview page.
  8. Select MathService (1.0) in the Collection widget:
    Selecting the MathService
    Selecting the MathService
    Selecting the MathService
  9. You will taken to the Browse page, which will display the details of the MathService (1.0) service version in the Detail widget. This is a representation of an implementation of the service in WSRR, specifically version 1.0. In the Detail widget, under Artifacts select MathServerService_EP1.wsdl ‪(1.0).
  10. The Detail widget will be updated to display the details of the MathServerService_EP1.wsdl ‪(1.0) WSDL document. Select Action => Replace Document:
    Replacing the document
    Replacing the document
    Replacing the document
  11. The Replace Document dialog will be displayed. Click Browse....
  12. Navigate to, and select, the modified MathServerService_EP1.wsdl document on the file system. Click Replace Document.
  13. A Warning dialog will be displayed. Click Yes.
  14. The Replace Document dialog will be updated to indicate that the document was successfully replaced. Click Close.

Running the Calculator application

A client application is provided in the calculator.jar archive, which you can download at the bottom of the article section. It is a simple SWING-based Java application that invokes the Math Service. To run the Calculator application and verify that your IBM Integration Bus environment is correctly configured:

  1. Open a command window.
  2. Execute the following command:
    java -jar <CALCULATOR_JAR_PATH>

    Where:
    • <CALCULATOR_JAR_PATH> is the full path calculator.jar file.
    This command assumes that java is on the path in your environment. If it is not, then specify the full path to your java executable.
  3. After the Calculator application opens, specify suitable hostname and port number values for the server that is running IBM Integration Bus.
  4. Modify the path for the service, setting its value to /MathServer1/services/MathServer, which is the path to the actual Math Service, and will verify that the flow that implements the service has been successfully built and deployed to IBM Integration Bus.
  5. Specify some values and a suitable operator (+, -, /, *) in the drop-down and then click =. The Calculator application will invoke the Math Service and display the result of the specified operation. It should look like this:
    The Calculator Application
    The Calculator Application
    The Calculator Application
  6. Modify the path for the service, setting its value to /MathServer/services/MathServer/eplookup1, the path to the basic endpoint lookup message flow. It will verify that IBM Integration Bus can communicate with the target WSRR instance.
  7. Click =. The service request from the Calculator application will be routed to the Math Service by the basic endpoint lookup message flow. You should see the same result as invoking the Math Service directly.

Conclusion

This article has described a number of business problems that can be solved by integrating IBM Integration Bus and WSRR. It has provided several sample message flows that solve these business problems and has walked you through the process of getting them up and running in your IBM Integration Bus and WSRR environment. The remaining articles in this series describe each of these message flows in detail, explaining how each message flow has been implemented to achieve the desired goals.

Acknowledgements

The author would like to thank the following people for all of their help with the development of the sample messages flows in this series:

  • John Hosie
  • Ben Thompson
  • Matt Golby-Kirk
  • Trevor Dolby
  • Andreas Martens
  • Graham Haxby
  • Andrew Coleman
  • John Reeve

The author would also like to thank the following people for their help with reviewing this article:

  • David Seager
  • Arnauld Desprets
  • Anna Maciejkowicz

Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Middleware
ArticleID=969885
ArticleTitle=Integrating IBM Integration Bus with WebSphere Service Registry and Repository: Part 1: Scenarios and configuration
publish-date=04302014