Web Service Proxy

Questions that you might ask about a Web Service Proxy.

The configuration of a Web Service Proxy can be accomplished with any combination of the following approaches.
  • One or more local WSDL files
  • One or more WSDL file responses (subscriptions) to WebSphere® Service Registry and Repository queries
The following answers questions about the Web Service Proxy are answered.

Can an operation be defined in multiple WSDL files?

The configuration source for a Web Service Proxy can be multiple WSDL files. Although the same operation can be defined in multiple WSDL files, only one instance of an operation can be viable. When the DataPower® Gateway or domain starts, each Web Service Proxy is created asynchronously. The service that first instantiates the duplicate operation wins. All the other duplicates are deactivated. At the next DataPower Gateway or domain restart, the fight for sole existence restart.

The single instance that wins cannot be determined by sorting by name or by the position in the configuration file. Each losing duplicate operation generates a log entry that is like the following message.

20130320T085114Z [ws-proxy][error] wsgw(foo1): tid(2251): Request to activate operation echoIntegerMultiOccurs on port 8091 and url /asmx/xsd/round4XSD.asmx failed because of a conflict with another instance of the same operation. Perhaps two Web Service Proxy services were configured the same WSDL on the same port, URL, and interface. The conflicting registration is owned by ws-proxy foo0 in domain default.

Can the default port in a WSDL file be deleted?

Through service configuration, you cannot remove a port or binding from the source WSDL file. You can modify the source WSDL file only before it is loaded as the configuration source. After the WSDL file is loaded, you can add support only. If the WSDL source defines a SOAP 1.1 binding, you cannot remove this binding. However, you can add instances of the SOAP 1.1 binding and add a SOAP 1.2 binding (and more instances) to support SOAP 1.2 requests.

Support that you add through configuration becomes part of the published WSDL (?wsdl) and are made available to clients of this service. These changes are not added to the source WSDL file.

For example, the source WSDL file defines the T1Port port with a SOAP 1.1 binding. On the WSDL files tab, you can attach multiple bindings for instances of SOAP 1.1 and SOAP 1.2 to a local endpoint handler (local rewrite rule).
  • If you add a SOAP 1.2 instance and apply the binding, the GUI shows T1Port (for the default SOAP 1.1 binding) and (T1Port.0 (for the added SOAP 1.2 binding). If you access the Policy tab, the WSDL tree shows T1Port() for the default SOAP 1.1 binding and T1Port(0) for the added SOAP 1.2 binding.
  • If you access the WSDL files tab and remove the local rewrite rule for both ports (T1Port and T1Port.0) and return to the Policy tab, the WSDL tree still shows T1Port() but no longer shows T1Port(0).

Why the .NET GET binding does not work?

To have a .NET WSDL, you might need to modify the WSDL source file and the Web Service Proxy is the following way.

  1. Modify the .NET WSDL file to make the location of the GET operation relative. If the WSDL contains an absolute location, change it to a relative location. For example, change <http:operation location="/GetCategories" /> to <http:operation location="GetCategories" /> by removing a forward slash.
  2. In the Web Service Proxy, make the remote URI for the GET binding absolute. If the remote URI does not contain a trailing forward slash, add a trailing slash. For example, change /WehireWS/JobsWs.asmx to /WehireWS/JobsWs.asmx/ by adding a trailing forward slash. URI resolution combines the parts to form the /WehireWS/JobsWS.asmx/GetCategories URI.
  3. Modify the front-end URI to your preference. To mimic the path to the remote web service, the front-end URI must end with a trailing forward slash. Under this condition, the actual web server URL is replaced with the DataPower service URL. For example, if the front-end URI is /WehireWS/JobsWs.asmx, change it to /WehireWS/JobsWs.asmx/.
When completed in the previous manner, the following requests are identical.
Web server URL
http://ws.ibm.ca/WehireWS/JobsWs.asmx/GetCategories
DataPower URL
http://9.33.97.20:8091/WehireWS/JobsWs.asmx/GetCategories

Why is WSDL validation different from the validation in the Web Service Proxy configuration

You can validate WSDL files in two different ways.
  • Use the WSDL validation tool where you select the file and which XML manager to use. Validation uses the compile options policy for this XML manager.
  • Automatic when you upload WSDL files during the Web Service Proxy. Validation uses the user policy that is defined for the web service. The user policy for each service can override the settings in the compile options policy for the XML manager.

For consistent validation, ensure that the compile options policy is defined to match the validation that you want for the service as defined by the applied user policy.

The common reason for inconsistent validation is against the document style, which is not enabled by default. When you enable, the schema for fault messages disallows RPC operation wrappers.
  • The compile options policy has the Require wrapper on fault-details specified by type property.
  • The nonwizard configuration has the Strict Fault Document Style property as a policy toggle.
  • The wizard configuration has no property that you can view.