How to consume WSDL that defines overloaded functions, using Groovy or Ruby?

Question

It is common for WSDL generated by Java to contain multiple function definitions with the same function name, differing only by argument type or number.

This poses problems when attempting to consume the WSDL from other languages (particularly languages which don't handle overloading well or at all). For example:

• Groovy's WSClient fails outright during initialisation:

  java.lang.IllegalArgumentException: An operation with name
  [{http://example.com/service-v1}overloadedFunction]
  already exists in this service
  

• Ruby's wsdlDriver doesn't fail immediately, but only one version of the overloaded function definitions is invokable (the others seem to be unusable).

Assuming I'm unable to modify the service, Is there a good way to handle this? Perhaps an option on these SOAP client libraries, different libraries, or a well-established transform of the WSDL?

Answer 1

Genesis/Restatement of the problem:

The issue is the generation of consumer side proxies for communicating with a Web Service over SOAP, where the WSDL is not using WS-I Basic profile - specifically by exposing operations of the same name under the same PortType.

Addressing the specifically mentioned client generators:

• Groovy's WSClient explicitly states for the module overview:

  "If you need to quickly consume and/or publish WS-I compliant web services, GroovyWS can help you."

• The Ruby language allows for classes to have methods of the same name, but the last one defined is the only one that the runtime will ever execute.

Options:

1. Create an Intermediary:

   Using a language that (easily) supports the creation of client proxies for overloaded PortType Operations, create a new web service which exposes the services in a WS-I Basic Profile compataible manner, and proxies the requests back up to the original service. This is a manifestation of the Adapter pattern.

   • Pros: This adapter will serve any consumer capable of generating proxies for WS-I Basic Profile compliant WSDLs. Also, if the Provider service changes you may be able to change the intermediary service without changing the service interfaces it provides to your consuming programs.
   • Cons: You will need to set up your own server for the web services.

2. Change the Generated Code:

   This is a great solution for the Ruby wsdlDriver issue, since the proxy generator successfully generates a proxy method per operation. All you need to do is change the method names in the Ruby class to be unique.

   • Pros: Very easy.
   • Cons: Only applies to a subset of client generators, such as Ruby's wsdlDriver. Also, the proxies will have to be edited every time they are regenerated.

3. Give the client generators an altered WSDL:

   Download the WSDL and manually change it to expose only the definition of the operation that you want, or rename the operations so they have unique names (change MyOp, MyOp, MyOp -> MyOp1, MyOp2, MyOp3). You will almost certainly need to alter the generated code.

   • Pros: Simplicity.
   • Cons: If you have a large or ever changing number of WSDL documents to process, this can be time consuming. Also, the proxies will have to be edited every time they are regenerated.