views:

173

answers:

3

I have created a C# .net 2.0 webservice. I need to capture the raw XML sent from the client and validate it against an XSD and return any errors to the client. The webservice will allow the client to upload a list of widgets to our system.

The following is some background info:

I created an XSD to model a "Widget", which is a complex object. It looks something like this:

<xs:element name="WidgetList">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="Widget" maxOccurs="unbounded" type="WidgetType" />
  </xs:sequence>
 </xs:complexType>
</xs:element>
<xs:complexType name="WidgetType">
 <xs:sequence maxOccurs="1" minOccurs="1">
  <xs:element name="Seller" type="AccountType" maxOccurs="1" minOccurs="1" />
  <xs:element name="Buyer" type="AccountType" maxOccurs="1" minOccurs="1" />
 </xs:sequence>
 <xs:attribute name="Market" type="MarketType" use="required" />
</xs:complexType>
<!-- etc... -->

Then, I used XSD.exe to generate classes from the xsd.
The Classes that are created are WidgetList, Widget, Seller, Buyer, etc.

Next, I created a webservice method to take the Upload. It looks like so:

[WebMethod]
[SoapHeader("SecurityAuthenticationHeader", Direction = SoapHeaderDirection.In)]
public string UploadWidgets(WidgetList wl)
{
    //Need to validate the XML against the XSD here.

    //Code to import...
}

Two questions:

  1. Is there a way that I can validate the raw XML sent from the client against my original XSD?
  2. Is there anything wrong with the way I have created this service?

UPDATE:
The reason I need to do this is that even though the XSD says fields are required or minOccurs=1, it seems that those properties are not required in the WSDL (Not really sure why).

This is what part of the WSDL looks like (removed unnecessary parts for brevity):

<s:schema elementFormDefault="qualified" targetNamespace="http://www.clearpar.com/XMLSchema"&gt;
  <s:element name="lt">
    <s:complexType>
      <s:sequence>
        <s:element minOccurs="0" maxOccurs="unbounded" name="LoanTrade" type="s1:LoanTradeType" /> 
      </s:sequence>
     </s:complexType>
   </s:element>
<s:complexType name="LoanTradeType">
  <s:sequence>
    <s:element minOccurs="0" maxOccurs="1" name="Seller" type="s1:AccountType" /> 
    <s:element minOccurs="0" maxOccurs="1" name="Buyer" type="s1:AccountType" /> 
  </s:sequence>
  <s:attribute name="Market" type="s1:MarketType" use="required" /> 
</s:complexType>
<s:complexType name="AccountType">
  <s:attribute name="Name" type="s:string" /> 
  <s:attribute name="ClientSystemID" type="s:string" /> 
</s:complexType>
+1  A: 

I don't think that there's a simple way to do this.

There is an MSDN article on implementing a SoapExtension to perform schema validation. This is the route I took, with a few enhancements.

It's unfortunate that there is no automatic mechanism to validate against the WSDL, especially since the service inherently knows the schema already. I would be interested to know if this situation has changed in WCF: I'm porting my services now and would love it if they've solved this problem more elegantly.

TickleMeElmo
I haven't heard that it's changed in WCF. Also, BTW, it is not accurate to say that the service knows the schema. Certainly in the case of ASMX services, the schema is usually generated _from_ the service metadata, not the other way around. The XML Serializer then creates the code it needs based on the .NET types found by reflecting over the service metadata. No XML manipulation is involved up to this point. At runtime, the schema is not even implied by the generated serialization code, which will ignore most facets of the schema.
John Saunders
A: 

Since you need more strict control over your WSDL, I recommend writing it manually, and generate both your service contract interface/data/messages and client proxies from a single WSDL contract. There is a great project on CodePlex, WCSF.blue, that can help you do contract-first service development.

jrista
A: 

For question 1, bartoncasey is right.

The only way that I know to validate the incoming message is to create SOAP Extension that validates the incoming message against the expected schema. The reason is that the .NET plumbing deserializes the incoming XML into an object before entering your WebMethod. If there is an issue with the incoming XML then your Web Method will never be entered and a SOAP Fault will be returned to the client. Another issue is that perhaps the deserializer does not deserialize "properly". Read the XML Schema Validation article for more information.

In terms of question 2: your approach is correct for contract first development using (asmx) web services. My question back to you is why not use WCF to expose a web service instead of the older ASMX technology. WCF supports schema validation as well.

Tuzo