Christian Weyer: Smells like service spirit

What's first?

ASMX's conformance to the WS-I BP 1.0 - do not blindly trust public information

At first sight I thought that the latest article on MSDN about attributing your ASMX code to control the WSDL (Inside WSDL with .NET Attribution) will help people to better understand what WSDL is and how it works.

Abstract: Understanding how a WSDL file describes your Web service is the key to understanding how XML Web services work in general. This article is for .NET developers who want to demystify the WSDL files that Microsoft ASP.NET generates by examining the seven major elements that compose a WSDL file. Techniques for altering the generated WSDL by using the attributes available within the System.Web.Services, System.Web.Services.Protocols, and the System.Xml.Serialization namespaces are also shown.

Maybe a further step will then be that they actually first think about their service's contract and then start coding (with tool support)... it actually seems to propose some best practices when working with service interfaces. Well, that was at least my theory.

When playing with the article's sample code I happened to start up the SOAPscope 3.0 Analyze Service feature. Kawoom! Ouch!

WS-I BP compliancy error messages.

The following list depicts details of some of the most important errors that occured when analyzing the demo service MyStoreMB.asmx(there were a bunch more, but I did not quite understand their meaning ;-) See at the bottom of this entry).
Obviously ASMX does currently not support a number of the WS-I BP 1.0 recommendations, which is natural as the ASMX engine did not get any service pack or fix release since the BP's existence

Schema Error: Duplicate key value [ID Value:] declared for identity constraint of element "definitions".
Node: import

Schema Error: Duplicate key value [ID Value:] declared for identity constraint of element "definitions".
Node: import

Wsdl:import points to a schema document
Imported file "
http://pcpauline/WSLibrary/MyStoreMB.asmx?schema=schema1" is a schema, which is not permitted through the use of import.

Xsd:import schemaLocation unknown
SOAPscope cannot perform the xsd:import specified by Element xs:import([?,?] imported from "
http://pcpauline/WSLibrary/MyStoreMB.asmx?schema=schema1") because the namespace is unrecognized and the "schemaLocation" attribute is missing or invalid.

Multiple wsdl:ports with same location
Multiple wsdl:ports Sales and Support have the same value for their "location" attributes.

Missing wsdl:binding
Wsdl:port Sales refers to an unknown wsdl:binding with QName "{}Sales".

Missing wsdl:binding
Wsdl:port Support refers to an unknown wsdl:binding with QName "{}Support".

The last error e.g. is related to the second binding entry in the WSDL as shown below and defined through the SoapDocumentMethod(Binding:="Support") attribute in the source code.

<definitions targetNamespace=""
   <import namespace="" location="http://pcpauline/WSLibrary/MyStoreMB.asmx?schema=schema1"/>
   <import namespace="" location="http://pcpauline/WSLibrary/MyStoreMB.asmx?schema=schema2"/>
   <import namespace="" location="http://pcpauline/WSLibrary/MyStoreMB.asmx?schema=schema3"/>
   <import namespace="" location="http://pcpauline/WSLibrary/MyStoreMB.asmx?wsdl=wsdl1"/>
   <import namespace="" location="http://pcpauline/WSLibrary/MyStoreMB.asmx?wsdl=wsdl2"/>
   <service name="MyStoreMB">
      <documentation>MyStore web service with multiple bindings</documentation>
      <port name="Sales" binding="i3:Sales">
         <soap:address location="http://pcpauline/WSLibrary/MyStoreMB.asmx"/>

      <port name="Support" binding="i4:Support">
         <soap:address location="http://pcpauline/WSLibrary/MyStoreMB.asmx"/>



It is left as an excercise to the reader to determine the other above mentioned problems in the XML document.
So I cannot help but recommend NOT TO USE THE APPROACH mentioned in the article's Controlling Port Types with .NET Attributes section. It may lead to heavy interoperability issues!

And finally I will also show you the error I did not quite understand. It occured several times. Any comments?:

Malformed XML:
Line: 1, Column: 55 in the original XML stream.
White spaces are required between publicId and systemId.

As a last fact I just to to make sure that nobody voluntarily uses RPC/encoded Web services (as introduced in another section of the article).

All in all, I like the basic idea of what Keith Pijanowski did. But I really expected that such public and recommended information had been tested and proved several times before published. Maybe a hint on the WS-I BP would have been just one more line or link in the article. We know from Yasser that they plan to fully support the BP in ASMX and it is really a must - there is no way out.

Just my 2 cents.


No Comments