Web Services Contract First
There are lots and lots of reasons to design the contract for the webservice (interface,messages etc) and only then proceed to the actual coding. Anyway it’s a common practice to any software project, but it is not that straightforward process in Visual Studio ASMX webservices.
With all the Vistual studio pre-generated project artifacts and templates it’s so much easier to get your[WebMethod] and voila! WSDL is genareted and contract is ready.
Here is nice article to address the doubts “Contract-First Web Services: 6 Reasons to Start with WSDL and Schema” on SOA Magazine
Nice post on the WebServiceContractFirst in VS2008 and WCF
ww.dotneteer.com/Weblog/post/2008/04/WSDL-first-(Contract-first)-Web-Service-development-with-Visual-Studio-2008.aspx
After doing some research and blogs scanning WSCF tool from thinktecture looks promising for ASMX
WSCF.blue is the new edition that supports WCF http://wscfblue.codeplex.com/
(For the default .AddIn file locations for Visual Studio 2008 add-ins http://www.mztools.com/articles/2008/MZ2008001.aspx )
Disable Soap1.2 generation in ASMX.NET WSDL generator
Websphere ESB 6.1 does not support Soap 1.2 yet. Presense of Soap1.2 bindings in .NET auto generated WSDL files created lots of problems with the new WID 6.1.2 release. So there are two options either modify WSDL manualy when importing to ESB or modify the .NET web service to supress Soap1.2.
To disable Soap1.2 binding generation add in web.config under <system.web>
<webServices>
<protocols>
<clear/>
<add name=“HttpSoap“ />
<add name=“Documentation“/>
</protocols>
</webServices>
wsdl.exe generator for WSDL with modeled soap faults
Here is common problem with faults modeled using WSCF (WebServiceContractFirst) tool – while trying to generate C# Proxy for a webservice WSDL, I have kept getting the following error:
Error: Unable to cast object of type ‘System.Xml.XmlElement’ to type ‘System.Web
.Services.Description.ServiceDescriptionFormatExtension’.
After a careful investigation of WSDL on W3C, I have discovered that the the bogus definition ( that wsdl.exe can’t understand) was in fault section of the binding:
<binding name=”SOAServices“ type=”tns:SOAServicesInterface“>
<soap:binding transport=”http://schemas.xmlsoap.org/soap/http“/>
<operation name=”ValidateUser“>
<soap:operation soapAction=”soa:validateUserIn“ style=”document“/>
<input>
<soap:body use=”literal“/>
</input>
<output>
<soap:body use=”literal“/>
</output>
<fault name=”ValidateUserFault“>
<soap:body use=”literal“/>
</fault>
</operation>
</binding>
Replacing the definition to include soap:fault instead of soap:body resolves the problem.
<wsdl:fault name=” ValidateUserFault “>
<soap:fault name=” ValidateUserFault “ use=”literal“/>
</wsdl:fault>
It would have been nice if wsdl.exe will generate more information for the errors, but ….