Using DataPower SOA Appliances to query WebSphere Service Registry and Repository

Learn how to use IBM® WebSphere® DataPower® SOA Appliances to query information from IBM WebSphere Service Registry and Repository using the REST API and SOAP API. Reusable stylesheets are provided to serve as standard query components to be used throughout DataPower configurations. Step-by-step examples show how these assets can be used to query WebSphere Service Registry and Repository. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Robert R. Peterson (rrpeters@us.ibm.com), WebSphere Enablement Consultant, EMC

Robert R. PetersonRobert R. Peterson is a solution architect for Tivoli's Integration Center of Competency. He works to improve integration across Tivoli's Service Availability and Performance Management (SAPM) product portfolio. Robert is an IBM Master Inventor for his patent contributions, an IBM Press author, and a frequent conference speaker. Visit his website.


developerWorks Contributing author
        level

14 May 2008

Introduction

IBM WebSphere Service Registry and Repository (hereafter referred to as Service Registry) often stores valuable metadata that an Enterprise Service Bus (ESB) or enterprise application needs at run time to make decisions, such as where to route a message or what operation to execute upon receiving a message. IBM DataPower SOA Appliances often serve as an ESB, and querying information from Service Registry (such as WSDL information, owner of a service, or classification of a service) is a common scenario.

Figure 1 illustrates the use case of DataPower querying Service Registry for runtime metadata. This enables key runtime information to be externalized from the DataPower configuration. In a sense, this results in parameterization of the ESB configuration and enables its behavior to be modified at run time by editing metadata in Service Registry.

Figure 1. Service Registry and DataPower topology
Figure 1. Service Registry and DataPower topology

This article shows how you can use DataPower to query information from Service Registry using the REST and SOAP APIs, with reusable stylesheets to serve as standard query components for use throughout DataPower configurations.

Prerequisites

If you plan to perform these steps as you follow the article, the following configuration is assumed:

  • IBM WebSphere Service Registry and Repository V6.1
  • IBM DataPower 3.6; any DataPower model (XA35, XS40, or XI50) is sufficient for these simple examples
  • Curl, a simple open source command line utility used by the examples to send messages to DataPower.

See Resources for detailed information on the above software.


Using the REST API

Service Registry supports a convenient REST-like interface that accepts HTTP GET requests with XPath queries embedded in the HTTP URL. The instructions that follow explain how both a browser and DataPower appliances can be used to access the REST interface. In this example, two WSDL documents are uploaded to Service Registry to serve as query metadata to be retrieved.

  1. Upload both of the WSDLs provided in the download file included with this article (StockPrice.wsdl and StockPriceByDate.wsdl) to Service Registry:

    1. In the Service Registry administrative console, select Service Documents => WSDL Documents => Load Documents.
    2. Select Local file system and Browse to the location of StockPrice.wsdl. Enter 1.0 for the document version, then select OK (Figure 2).
      Figure 2. Upload WSDL
      Figure 2. Upload WSDL
    3. Repeat these steps to upload StockPriceByDate.wsdl.
  2. The REST API can be very convenient because it can be accessed with just a Web browser. Both graph and property queries are supported from a browser. Graph queries take this form:

    http://<host>:9080/WSRR/6.1/Metadata/XML/GraphQuery?query=<XPathQuery>

    For example, the query below returns all the metadata associated with the StockPrice.wsdl. Enter this into a browser:

    http://<host>:9080/WSRR/6.1/Metadata/XML/GraphQuery?
    query=/WSRR/WSDLDocument[@name='StockPrice.wsdl']

    The result should be similar to that shown in Figure 3.

    Figure 3. REST browser graph query
    Figure 3. REST browser graph query

    Property queries take this form:

    http://<host>:9080/WSRR/6.1/Metadata/XML/PropertyQuery?
    query=<XPathQuery>&<properties>

    The query below returns the name of all WSDLs in Service Registry. Enter this query in a Web browser:

    http://<host>:9080/WSRR/6.1/Metadata/XML/PropertyQuery?
    query=/WSRR/WSDLDocument&p1=name

    The result should be similar to that shown in Figure 4.

    Figure 4. REST browser property query
    Figure 4. REST browser property query

    For information on Service Registry XPath queries, see the WebSphere Service Registry and Repository Information Center.

  3. You need a host alias before you can configure a DataPower service to query Service Registry. A host alias is bound to an IP address. The host alias name can then be used in any DataPower configuration or development. The steps below configure a host alias called WSRR which is bound to the IP address of the host machine for Service Registry.

    1. From the DataPower default domain in the administrative console, navigate to Network => Interface => Host Alias.
    2. Create a host alias called WSRR and input the IP address of your Service Registry installation (Figure 5).
      Figure 5. Host alias configuration
      Figure 5. Host alias configuration
    3. Switch to the wsrr-devworks domain or any other working domain other than default.
  4. Now, you can configure a REST query from DataPower. The steps below illustrate how to create a loopback XML Firewall that queries Service Registry:

    1. From the control panel, select XML Firewall => Add Wizard => Pass Thru, and then Next (Figure 6).
      Figure 6. Firewall wizard
      Figure 6. Firewall wizard
    2. Name the Firewall WSRR-REST-query-example, then Next.
    3. Select loopback-proxy for the Firewall type, then Next.
    4. Select the desired port, then Next.
    5. Commit the changes and then navigate to the configuration of the newly created XML firewall.
    6. Change the Request Type to XML and then select the Firewall Policy by selecting the "..." button next to it (Figure 7).
      Figure 7. Configure XML firewall
      Figure 7. Configure XML firewall
      At this point, you are going to add a stylesheet to the processing policy that performs the WSRR REST query. The stylesheet is called WSRR-REST-query.xsl and is shown in Listing 1.
      Listing 1
      lt;xsl:stylesheet version="1.1"
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
          xmlns:dp="http://www.datapower.com/extensions"
          xmlns:dpquery="http://www.datapower.com/param/query"
          extension-element-prefixes="dp"
          exclude-result-prefixes="dp">
          
          <xsl:param name="dpquery:host" select="'WSRR'" />
          <xsl:param name="dpquery:port" select="'9080'" />
          <xsl:param name="dpquery:xpath-query" />
          <xsl:param name="dpquery:is-property-query" select="false" />
          
          <xsl:template match="/">     
              <xsl:choose>
                  <xsl:when test="$dpquery:is-property-query">
                      <dp:url-open 
                          target="http://{$dpquery:host}:{$dpquery:port}
                          /WSRR/6.1/Metadata/XML/PropertyQuery?
                          query={$dpquery:xpath-query}"
                          response="xml" /> 
                  </xsl:when>
                  <xsl:otherwise>
                      <dp:url-open 
                          target="http://{$dpquery:host}:{$dpquery:port}
                          /WSRR/6.1/Metadata/XML/GraphQuery?
                          query={$dpquery:xpath-query}"
                          response="xml" />        
                  </xsl:otherwise>
              </xsl:choose>
          </xsl:template>
      </xsl:stylesheet>

      Notice that the url-open extension function is used to make the actual HTTP GET. The url-open node does not contain children, providing no input for the outbound call. DataPower interprets this as an HTTP GET instead of a POST. Notice also that the stylesheet has four parameters. It can handle both graph queries and property queries. The type of query is indicated with is-property-query boolean parameter. The XPath query string is provided with the xpath-query parameter.
    7. In the processing policy, drag the Transform action on to the request rule (Figure 8).
      Figure 8. Processing policy
      Figure 8. Processing policy
    8. Double-click on the Transform action and upload WSRR-REST-query.xsl (Figure 9).
      Figure 9.Figure Upload REST stylesheet
      Figure 9.Figure Upload REST stylesheet
    9. Select the Advanced tab and enter the values below for these parameters (Figure 10):
      • host: WSRR
      • port: 9080
      • xpath-query: /WSRR/WSDLDocument&p1=name&p2=bsrURI
      • is-property-query: true
      Figure 10. Stylesheet parameters
      Figure 10. Stylesheet parameters
    10. Click Done. Save the processing policy by selecting Apply Policy and select Apply to the XML Firewall.
    11. To test the query, send any well-formed XML message to the XML firewall. For example:

      curl --data-binary @blank.xml <datapower_host>:<port>

      The result should be as similar to Figure 11.
      Figure 11. REST query output
      Figure 11. REST query output

Using the SOAP API

Service Registry also supports a SOAP API that can be accessed via any JAX-RPC compliant client. This section shows how DataPower can be used to query Service Registry using the SOAP API. (If you skipped the previous section, you will still need to setup the WSRR host alias and upload the WSDLs to Service Registry (steps 1 and 3 above) to follow this example.)

This section creates another DataPower XML Firewall. However, this configuration queries Service Registry with the SOAP API.

  1. 1. Create another XML Firewall that is a loopback proxy. (See step 4 above). Name it WSRR-SOAP-query-example, and set the Request Type to XML. This example uses a stylesheet that performs the Service Registry SOAP query. The stylesheet is called WSRR-SOAP-query.xsl and is shown in Listing 2.

    Listing 2
    amp;<xsl:stylesheet version="1.1"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:dp="http://www.datapower.com/extensions"
        xmlns:dpquery="http://www.datapower.com/param/query"
        extension-element-prefixes="dp"
        exclude-result-prefixes="dp">
        
    <xsl:param name="dpquery:host" select="'WSRR'" />
    <xsl:param name="dpquery:port" select="'9080'" />
    <xsl:param name="dpquery:xpath-query" />
    <xsl:param name="dpquery:comma-separated-properties" />
        
    <xsl:template match="/">     
            
    <xsl:variable name="soap-query">
                
        <soap:Envelope 
            xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <soap:Body>
        <executeQuery
            xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/ws/sdo">
        <datagraph xmlns="commonj.sdo">
        <WSRR
            xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/sdo">
        <root>_1</root>
        <xsl:choose>
        <xsl:when 
            test="string-length($dpquery:comma-separated-properties) > 0">
        <artefacts 
            xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/sdo" 
            xsi:type="PropertyQuery" bsrURI="_1"
            queryExpression="{$dpquery:xpath-query}">
        
            <xsl:call-template name="process-properties">
                <xsl:with-param name="properties-string" 
                    select="$dpquery:comma-separated-properties" />
                <xsl:with-param name="count" select="1" />
            </xsl:call-template>
        </artefacts>
        </xsl:when>
        <xsl:otherwise>
        <artefacts 
            xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/sdo" 
            xsi:type="GraphQuery" bsrURI="_1"
            queryExpression="{$dpquery:xpath-query}" />
        </xsl:otherwise>
        </xsl:choose>    
        </WSRR>
        </datagraph>
        </executeQuery>
        </soap:Body>
        </soap:Envelope>
                
    </xsl:variable>
            
    <xsl:copy-of select="dp:soap-call(
     concat('http://',$dpquery:host,
        ':',$dpquery:port,
        '/WSRRCoreSDO/services/WSRRCoreSDOPort')
     ,$soap-query,'',0,'WSRRCoreSDO')"/>
            
    </xsl:template>
        
    <xsl:template name="process-properties">
        <xsl:param name="properties-string" />
        <xsl:param name="count" />
                    
        <xsl:choose>
        <xsl:when test="contains($properties-string,',')">
        <xsl:variable name="property" 
            select="substring-before($properties-string,',')"/>
                    
        <userDefinedProperties  
            xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/sdo"
            name="PropertyQueryProperty{$count}" value="{$property}" />
                    
        <xsl:variable name="remaining" 
            select="substring-after($properties-string,
            concat($property,','))" />
                    
        <xsl:call-template name="process-properties">
        <xsl:with-param name="properties-string" select="$remaining" />
        <xsl:with-param name="count" select="$count + 1" />
        </xsl:call-template>
                    
        </xsl:when>
        <xsl:otherwise>
                    
        <userDefinedProperties 
            xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/sdo"
            name="PropertyQueryProperty{$count}" 
            value="{$properties-string}" />
                
        </xsl:otherwise>
        </xsl:choose>
            
    </xsl:template>
        
        </xsl:stylesheet>

    Although this stylesheet is more complex, its composition is similar to the REST stylesheet. Notice that it also has stylesheet parameters. However, instead of a flag to choose between a graph query or a property query it has a parameter called comma-separated-properties. This parameter should be left blank for a graph query. For a property query, it should be populated with each property in a comma-separated list.

    Also notice that a soap-call() extension function is used to make the actual query to Service Registry.

  2. In the processing policy, drag the Transform action on to the request rule.

  3. Upload WSRR-SOAP-query.xsl for the transform action (Figure 12).

    Figure 12. Upload SOAP stylesheet
    Figure 12. Upload SOAP stylesheet
  4. Select the Advanced tab and enter the following values for these parameters (Figure 13):

    • host: WSRR
    • port: 9080
    • xpath-query: /WSRR/WSDLDocument
    • comma-separated-properties: name,namespace,bsrURI
    Figure 13. SOAP stylesheet parameters
    Figure 13. SOAP stylesheet parameters
  5. As before, send any well-formed XML document through the XML firewall and you should get a result similar to Figure 14.

    Figure 14. SOAP query output
    Figure 14. SOAP query output

Try other XPath queries. For graph queries, simply leave the comma-separated-properties parameter empty.


Conclusion

Once you become familiar with these relatively simple steps, you will have a repeatable and consistent set of assets to query any form of metadata from WebSphere Service Registry and Repository.


Download

DescriptionNameSize
Code sampleDataPower-WSRR-example.zip370 KB

Resources

Learn

Get products and technologies

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
ArticleID=307593
ArticleTitle=Using DataPower SOA Appliances to query WebSphere Service Registry and Repository
publish-date=05142008