Using DataPower SOA Appliances to query WebSphere Service Registry and Repository

Robert R. Peterson (rrpeters@us.ibm.com), WebSphere Enablement Consultant, IBM, Software Group

Robert R. Peterson is part of the enablement team under IBM Software Services for WebSphere. He works to ensure that the WebSphere portfolio of products brings IBM's clients the greatest value possible. Robert is an accomplished inventor and co-author of WebSphere Application Server V6: Performance and Scalability. He is an alumnus of IBM's prestigious Extreme Blue Program and holds a M.S. in Computer Engineering from the University of Florida.

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

Tag this!

Date: 14 May 2008
Level: Intermediate
Activity: 2230 views
Comments:

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

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.

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
3. Repeat these steps to upload StockPriceByDate.wsdl.
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

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

For information on Service Registry XPath queries, see the WebSphere Service Registry and Repository Information Center.
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
3. Switch to the wsrr-devworks domain or any other working domain other than default.

Now, you can configure a REST query from DataPower. The steps below illustrate how to create a loopback XML Firewall that queries Service Registry:

From the control panel, select XML Firewall => Add Wizard => Pass Thru, and then Next (Figure 6).

Figure 6. Firewall wizard
Name the Firewall WSRR-REST-query-example, then Next.
Select loopback-proxy for the Firewall type, then Next.
Select the desired port, then Next.
Commit the changes and then navigate to the configuration of the newly created XML firewall.

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

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.

In the processing policy, drag the Transform action on to the request rule (Figure 8).

Figure 8. Processing policy
Double-click on the Transform action and upload WSRR-REST-query.xsl (Figure 9).

Figure 9.Figure Upload REST stylesheet
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
Click Done. Save the processing policy by selecting Apply Policy and select Apply to the XML Firewall.
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

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

In the processing policy, drag the Transform action on to the request rule.
Upload WSRR-SOAP-query.xsl for the transform action (Figure 12).

Figure 12. Upload SOAP stylesheet
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
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

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

Description	Name	Size	Download method
Code sample	DataPower-WSRR-example.zip	370 KB	HTTP

Information about download methods

Resources

Learn

Get products and technologies

Curl download site

About the author

Comments

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=WebSphere, SOA and Web services

ArticleID=307593

ArticleTitle=Using DataPower SOA Appliances to query WebSphere Service Registry and Repository

publish-date=05142008

author1-email=rrpeters@us.ibm.com

author1-email-cc=

Introduction
Using the REST API
Using the SOAP API
Conclusion
Download
Resources
About the author
Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.