tags:

views:

1343

answers:

3

I'm using a 3rd party web service written in Java and using Apache Axis 1.3. The service has many overload operations. When the WCF Svcutil generates the proxy, it renames the overloaded operation by appending a number after the operation name. For example:

getDataResponse getData(getDataRequest request);

getDataResponse1 getData1(getDataRequest1 request);

This by itself isn't a problem, but when Svcutil generates the request/response messages, it neglects to change the WrapperName property of the MessageContracts.

    [MessageContractAttribute(
        WrapperName = "getData", 
        WrapperNamespace = "http://namespace.com", 
        IsWrapped = true)]
    public partial class getDataRequest1 {  ..  }

When the client application attempts to open the proxy, the following exception is thrown:

InvalidOperationException: RPC Message getDataRequest1 in operation getData1 has an invalid body name getData. It must be getData1

If I change WrapperName = "getData1" the proxy will open, however...

  1. I am unable to call the operation because the service doesn't recognize "getData1"
  2. The service has almost 1100 operations, of which nearly half are overloads

Is there any way to generate and/or modify the proxy so that all operations work with WCF?

Mark

A: 

Write a script that'll do this text fix and set it as the post-build script for your proxy library.

Sijin
I may end up doing that if I can't find a cleaner way.
Mark Good
Part of the reason that I'm reluctant to script these edits is that the cs file generated is almost 13 megs.
Mark Good
+1  A: 

The only workaround that I have been able to find is to edit the generated code by hand and remove all of the overloads that I don't need.

Mark Good
+1  A: 

I didn't see this question before, because you had a "java" tag on it, and I ignore Java questions. Your question wasn't about Java, so should not have had a "java" tag.

svcutil is not renaming the overloaded operations. That's because there's no such thing as overloaded operations. WSDL has no concept of two operations with the same name, but using different messages.

If you look at the WSDL from Axis, I believe you'll find the operations have the numbers appended to them.


Correction: In a comment, Mark Good correctly points out that WSDL 1.1 does permit overloading. I happen to think it only makes any sense in the context of an RPC-based service, where the message name can be used to distinguish between one overload and another.

However, he may not be aware that operator overloading is prohibited by WS-I Basic Profile 1.1:

4.5.3 Distinctive Operations

Operation name overloading in a wsdl:portType is disallowed by the Profile.

R2304 A wsdl:portType in a DESCRIPTION MUST have operations with distinct values for their name attributes.

Note that this requirement applies only to the wsdl:operations within a given wsdl:portType. A wsdl:portType may have wsdl:operations with names that are the same as those found in other wsdl:portTypes.


If one reads more of WS-I BP1.1, one will learn why not everything in WSDL 1.1 is a good idea.

John Saunders
The question stood for months without the Java tag and you did not answer. I recently added the java tag because the 3rd part software was written in Java and I was hoping that someone might be able to offer a way to generate the WSDL differently. From what I read, overloading operations WAS supported in WSDL 1.1 (ref http://webservices.xml.com/pub/a/ws/2003/01/08/randyray.html). You are incorrect about svcutil not renaming the operations and the operations having numbers appended to them in the WSDL. I can send you and/or post a snippet on Monday if you would like.
Mark Good
I don't actually see every question that everyone posts. I only got around to this one due to being unemployed. I hope soon to be seeing fewer posts
John Saunders
I wasn't specifically aware that it was prohibited by WS-I Basic Profile 1.1, but thanks for the info. Sorry to hear about your unemployment. I with you luck with fewer posts. :-)
Mark Good
Take the opportunity to read http://www.ws-i.org/Profiles/BasicProfile-1.1.html. It's quite instsructive, and teaches a lot about how not to write a specification (SOAP, WSDL).
John Saunders