Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly
get the code
more resources

Validate SOAP Messages With XSD Schemas
Use the XmlValidatingReader to verify the structure and datatypes of Web service XML message payloads.
by Roger Jennings

Posted July 8, 2002

As Web service technology matures, it's a good bet that schema-based document/literal SOAP messaging will gradually replace the rpc/encoded format used by most of today's fledgling Web services. Microsoft didn't toss a coin to decide to adopt document/literal as the default format for ASP.NET Web Service projects—in fact, Microsoft's use of the term XML Web services might be an attempt to distinguish document/literal from rpc/encoded services. It's easy to override the .NET-standard message format by applying a SoapRPCService or SoapRPCMethod attribute. But most .NET developers probably will accept the default format, so you'll encounter increasing use of the document/literal messaging format as Visual Studio .NET gains momentum. The Web Services Interoperability Organization's final Basic Profile is expected to specify—or at least strongly recommend—document/literal style.

Another trend you can expect is replacement of rpc-style, section 5-encoded method parameters and return values by XML documents as the SOAP request message payload. In this scenario, SOAP headers substitute for rpc-style parameters to authenticate and authorize users of consuming applications. The .NET Framework's built-in XML serialization/deserialization features let you define complex SOAP message structures by nested classes. Schema elements of the WSDL file specify the structure and datatypes of the request and response documents' nodes. If your service or consuming app must support rpc/encoded XML payloads or your app can't interpret the schema in a WSDL file generated by a particular SOAP toolkit, you must process the raw XML string. The same is true if the app or Web service MIME- or DIME-encodes the payload.

 
Figure 1. Take in the XSD Schema View.

Handling raw XML document payloads, rather than method parameters or serialized classes, generates a simple WSDL document that defines request and response messages as simple s:string elements. The same is true for DIME-encoded messages, which have a DimeAttachment type. The WSDL document doesn't define the XML payload's structure, so message validation requires a separate XML Schema document (XSD). Validation within the XML Web service ensures that the request document has the expected structure and its element values conform to the required XSD datatype, such as xsd:date or xsd:int. It's also a good practice for consumers to validate XML Web service response documents. Validation code is almost identical for XML Web services and consumers, so validating messages at the two endpoints doesn't involve much additional coding effort.

Back to top











Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home