I tried calling the same web service using Apex generated using the FuseIT SFDC Explorer (full disclosure, I work for the FuseIT). In theory the results should be the same as the built in Wsdl2Apex implementation, but it could also account for some differences.
After adding the Remote Site Settings for http://validator2.addressdoctor.com I tried the following minimal anonymous Apex:
validator2AddressdoctorComAddbatchB.BatchSoap bs = new validator2AddressdoctorComAddbatchB.BatchSoap();
validator2AddressdoctorComAddbatchB.addBatchRequest addBatchRequest = new validator2AddressdoctorComAddbatchB.addBatchRequest();
bs.Validate(addBatchRequest);
This gave the error:
System.CalloutException: Web service callout failed: WebService returned a SOAP Fault: System.Web.Services.Protocols.SoapException: Server was unable to read request. ---> System.InvalidOperationException: There is an error in XML document (1, 334). ---> System.FormatException: Input string was not in a correct format.
I found the debug log showed the full error message in the CALLOUT_RESPONSE:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>System.Web.Services.Protocols.SoapException: Server was unable to read request. ---> System.InvalidOperationException: There is an error in XML document (1, 334). ---> System.FormatException: Input string was not in a correct format.
at System.Number.ParseInt64(String s, NumberStyles style, NumberFormatInfo info)
at System.Xml.XmlConvert.ToInt64(String s)
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read1_addBatchRequest(Boolean isNullable, Boolean checkType)
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read19_Validate()
at Microsoft.Xml.Serialization.GeneratedAssembly.ValidateSerializer.Deserialize(XmlSerializationReader reader)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
--- End of inner exception stack trace ---
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, XmlDeserializationEvents events)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader)
at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
--- End of inner exception stack trace ---
at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
at System.Web.Services.Protocols.WebServiceHandler.Invoke()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()</faultstring>
<detail />
</soap:Fault>
</soap:Body>
</soap:Envelope>
Looks like it was expecting a long (Int64) in the request. From the addBatchRequest element that would most likely be the AddressCount. So I tried the request:
validator2AddressdoctorComAddbatchB.BatchSoap bs = new validator2AddressdoctorComAddbatchB.BatchSoap();
validator2AddressdoctorComAddbatchB.addBatchRequest addBatchRequest = new validator2AddressdoctorComAddbatchB.addBatchRequest();
addBatchRequest.AddressCount = 0;
bs.Validate(addBatchRequest);
That gave me a ValidateResponse in the CALLOUT_RESPONSE. Admittedly that contained the ErrorCode 201, but the web service was called and sent a response.
By the way, that web service shouldn't be returning stack traces for errors. It would make it easier for hacker types to figure out what is going on.