Question about interoperability with Java-based web services

Jan 6, 2012 at 5:56 PM
Edited Jan 10, 2012 at 3:42 PM

Can anyone tell me if the document consumer actor in this reference implementation has been tested successfully against a Java-based implementation of the document registry and document repository services?

I am attempting to create such an actor using .NET 4.0 under Visual Studio 2010.  We will be talking to Java-based web services implemented by another company.   When I perform the "add service reference" in my Visual Studio web application, no proxy class is being generated and no binding/endpoint configuration is being added to the web.config file.   The absence of the endpoint/binding configuration is not necessarily a problem (since I've learned that WCF 4 doest not necessarily generate the configuration output that WCF 3.5 did), but the complete absence of a proxy class certainly suggests that something is missing from the .wsdl file.     Obviously, I'd rather avoid writing the proxy class(es) myself, and I don't think that should be necessary if a proper .wsdl file is generated by the server.   Has any one encountered similar issues?  

I will be taking a closer look at the reference implementation of the XDS.b Solution Accelerator.   Again, my question is:  has the reference implementation been tested against Java-based web services or only against WCF services?


Feb 6, 2012 at 11:45 AM

Sounds like bad wsdl to me. What's the address ? We'll test our consumer against it, and cross reference the wsdl files with our services. And no we didn't test against java.

Feb 6, 2012 at 2:40 PM

Thanks for the response.  I have some new information since I posted my question:  

I decided to try using svcutil.exe instead of the "Add service reference" functionality built into Visual Studio 2010, and surprisingly, svcutil was able to generate the proxy class without throwing any errors.     The fact that I get an error when using "Add service reference" would suggest that Visual Studio does not use svcutil, but instead has it's own implementation of that functionality.   Do you know, is that the case?

Anyway, the size of the proxy class file was huge:  it generated something like 50,000 non-commented lines of code.   This is, I believe, due to there being numerous .xsd files (67 of them if memory serves) referenced by the .wsdl.   Due to the tremendous compexity of the generated proxy class, I have, for the short-term at least, decided to forgo using the proxy class and am instead using lower-level APIs, e.g. HttpWebRequest, to send pre-constructed SOAP messages to the web service url.    This approach may seem less than ideal, but to use the proxy class, I would have to instantiate a very large hierarchy of objects in order to construct the SOAP message, and learning how to do that in the proper order and with the appropriate paramter values, looked to be a daunting task -- something we may have to tackle later on -- but for right now, we're simply trying to verify that we can communicate with the web service.   In addition, it was straight-forward, with the low-level API approach, to add an authorization header (per RFC 2617) to the http request.

If you provide me an e-mail address (send it to:  markshy at, I can send you the url of the web service.