The following is about the behaviour of DataPower's Web Service proxy with a WSRR subscription and the out-of-the-box integration. This is not about what can happen if you write custom processing rules, either stand-alone, or you extend the generated flow in the WS-Proxy when using a WSRR subscription.
Recently I set up the DataPower integration as described in the articles Using WebSphere Service Registry and Repository V8 and DataPower V5 for service level mediation policy enforcement. I was using a Web Service Proxy on 7.5 DataPower firmware, using a named query to retrieve the WSDLs from WSRR.
Multiple Service Level Definitions (SLDs)
In this case, rather than having a single SLD on a service version as described in the article, we had two SLDs. There was an interface WSDL which defined the port type, binding and messages and types. Then there were two WSDLs which just defined endpoints, each endpoint had a different service and port name. The endpoint for each WSDL was attached to one SLD, so we ended up with two SLDs with different endpoints.
The named query was returning all the WSDLs; both endpoint WSDLs and the interface WSDL.
Then we had a single consumer set up in WSRR with two SLAs. One SLA went to one SLD and one went to the other SLD. The intention was to use the context identifier on the SLA to set the SLA the request was using, so we set up the consumer ID location and context ID location fields on the SLD.
The client was able to send a request on either SLA by varying the context ID, and kept the consumer ID the same as that what was set on the Application Version we used to consume both SLDs.
The behaviour as we saw was that DataPower would pick one of the endpoints and always route to that endpoint, irrespective of what context ID we were using. It seems that DataPower picks one of the endpoints that the operation is available on to route to.
We then added policies to each SLD, first logging policies and then routing policies.
The behaviour as we saw was that all the policies on all the SLDs were applied on the request, irrespective of what context ID we were using. Looking in the gateway SLA Policies panel confirmed this; DataPower listed all the policies we attached to both SLDs in WSRR on a single SLD on the service. The WSRR documentation about the policy attachment API confirms this behaviour; if a policy is attached to an SLD then a standard PolicyAttachment section is returned and no filters are present. This means that all consumers will get the policy behaviour. If a policy is attached to an SLA then a wsmcf:Filter element is present that specifies that the policy is related to a specific consumer or context pair.
We added policies to the SLAs to see if we could select these policies. When we selected one SLA using the consumer and context ID we saw only the policy on that SLA being used. This confirms what the WSRR policy attachment API documentation says.
This means that in the out of the box DataPower and WSRR integration using only the WSRR subscription on a Web Service proxy, all policies attached to any SLDs are always run when a consumer calls the service. Only policies on the SLA from the consumer to the service SLD can be selected using the consumer and context identifiers. And a single endpoint from the WSDL is selected to be routed to.
It is possible to do things like adding custom rules to the processing to do an endpoint look up in WSRR, or perhaps more advanced DataPower coding to apply different policies, but as of yet I have no experience of such things so cannot detail what is possible.