You may already be using the Policy integration between WebSphere DataPower (DataPower) V5 and WebSphere Service Registry and Repository (WSRR) V8.0 to express your business intent for your services in the form of policies. Perhaps you are doing dynamic look up of web service endpoints stored in WSRR, from DataPower, for WSDL based services. DataPower 6 and WSRR V8 fix pack 2 (V220.127.116.11) add new capabilities on top of this bedrock of dynamic look up and policy enforcement. Now DataPower 6 can dynamically look up the endpoint URL of REST based services that are registered in WSRR. The policies that are authored and stored in WSRR and enforced by DataPower have also been enriched with new capabilities.
WSRR V8 and DataPower V5
WSRR is, among other things, a registry of service details, such as the provider of a service and any applications or other services which are using (consuming) the service. Using the DataPower policy integration you can express business intent in the form of policies, for example you can enforce limits on the number of messages a consumer can invoke a service with, restrict the number of messages that a service can accept within a defined time interval, change where the requests are sent depending on the time of day, and reject rogue consumers of services. DataPower has been able to do this for many releases, but in DataPower V5 a simple policy can be authored in WSRR, rather than writing rules and XSLT in the DataPower appliance. For more details, see the series of articles "SOA governance using WebSphere DataPower and WSRR" or our Service Registry YouTube channel for demos.
WSRR V18.104.22.168 and DataPower V6 new integrations
Rather than being limited to services described by WSDL, you could register your REST services in WSRR since V8.0 using the WSRR REST model. You can now subscribe your DataPower V6 appliance (virtual or real) to keep up to date with changes to the endpoints where these REST services are deployed. You can already enforce policies in DataPower on WSDL based services, but now you can also enforce these same policies on REST services stored in WSRR V22.214.171.124.
What of the new policy capabilities? In version 1.6 of the Web Service Mediation Policy (WS-MediationPolicy) spec, you could make DataPower perform policy enforcement actions when a request message was sent to it. Now in the new 1.7 spec, you can also make DataPower perform actions when the response message, or a fault message, comes back from the service being invoked. You can now get DataPower to log a message to any DataPower log, containing information such as the URL, server time or identifier of the consumer. DataPower can log the message on a request, response or fault, at any severity from informational to critical. You can enforce policies during certain times and set which time zone the time is for. In the 1.6 WS-MediationPolicy spec you could specify that a message was routed to a specific URL, but now in 1.7 you can specify a stylesheet to run on the DataPower appliance, along with any number of parameters and endpoints for the stylesheet to use.
All these policies are authored and attached to services in the WSRR console, so once the service proxy is created in DataPower, you need never access DataPower again to change the traffic throttling, logging or routing policies.
For more information about WSRR 126.96.36.199 see the WebSphere Service Registry and Repository V8.0 Fix Pack 2 Download page, or my WSRR V8.0 Fix Pack 2 (188.8.131.52) and WebSphere DataPower 6 New Features blog post which goes into further detail on the new features. For DataPower 6 see the announcement, or the information center for DataPower. The WS-MediationPolicy 1.7 spec is available for further reading.
Following are some troubleshooting tips I have found very useful when setting up the integration between WSRR and DataPower.
WSRR server connection
Initially when you set up the connection from DataPower to WSRR, you may need to set up the SSL certificates if security is enabled in WSRR. The article titled "Secure integration of WebSphere Service Registry and Repository V8 with WebSphere DataPower V5" shows you how to do it. Once the connection is set up, you can test the connection from the WSRR Server details panel in DataPower by clicking the Test Connection link.
Time outs in the DataPower console
When configuring WSRR servers, you may want to increase the time out so that you are not logged out of the DataPower console. To do this, in the DataPower web management GUI, expand Objects -> Device Management, click Web Management Service and from the panel, increase the value of the Idle Timeout.
Examining DataPower requests to WSRR
For advanced debugging, you may wish to see the specific requests that DataPower makes to WSRR, and their responses. To do this, you configure an XML firewall in DataPower to front the WSRR server, then in your WSRR Server definition in DataPower, you specify this XML firewall instead of the WSRR server. Then you enable a probe on the firewall, and DataPower will capture the traffic to and from WSRR.
First, create a new XML Firewall. Set the type to XML for request & response. In the remote host and remote port fields, specify your WSRR server details and add a crypto profile if your WSRR is secure. See the article "Secure integration of WebSphere Service Registry and Repository V8 with WebSphere DataPower V5" for details of how to set up a crypto profile for WSRR. In the advanced tab, set Disallow GET to Off and Process Messages Whose Body Is Empty to On.
You can use HTTP for the front end, because only DataPower will connect to the XML Firewall. The following screen shot shows my XML firewall set up:
Then you can load the URL http://<datapower>:<port>/WSRR and see the WSRR version, coming through the XML firewall.
In WSRR Server object, you specify the DataPower host and port of the firewall, and http. You do not need a crypto profile because the firewall takes requests on HTTP, and itself manages connecting to a secure WSRR server. In the example below the DataPower is on the host name srvdp02 and port 22048. Note because the XML firewall is on HTTP, a SSL proxy profile is not needed.
To see the requests and responses for WSRR, edit the XML Firewall object and enable the probe. Click Show Probe->Enable Probe. DataPower will capture the traffic to and from WSRR. For example, if you test the WSRR Server connection by clicking Test Connection on the WSRR Server object panel, you will see the following when you click Show Probe in the XML firewall:
This shows that DataPower accesses the /WSRR service on the WSRR server to test the connection, this service returns the version of the WSRR server.
My thanks to Thomas Burke from DataPower for the XML firewall tip and my thanks to Martin Smithson for reviewing this post.
Over to you, how are you looking up endpoints in your ESB at present, hard coded or from somewhere else? Do you have any interest in using Policy integration to manage your traffic?