WSDL Cleanliness is next to Godliness (actually Cleavage is next to Cleanliness and Goggles is next to Godliness...)
So let me start my own little possee here and cry: Say No to inline schema definitions in WSDL! Import is your friend.... [Commonality]
I'm with Tomas on this one. Schemas should be written as standalone documents and then be imported into the WSDL document. Not only is this easier to manage for the developer writing the schema and WSDL, but it's also easier for those who have to grok the two. Besides, the service you're writing the WSDL for probably isn't the only thing that's going to need access to the types you define in the schemas. [Drew Marsh]
Totally...not only WSDL First! and <xs:import> but (maybe this is obvious) I'm getting in the habit of putting the Domain Object-y definitions that we use elsewhere and the SOAP-y GetDomainObjectResult/Response definitions into separate XSDs. I preached this at TechEd last week and spoke briefly to Tomas about it although we didn't have enough time to really dig in.
<wsdl:types>
<xs:schema>
<xs:import namespace="http://banking.corillian.com/Account.xsd" schemaLocation="Account.xsd"/>
<xs:import namespace="http://banking.corillian.com/Banking/GetAccounts" schemaLocation="GetAccounts.xsd"/>
</xs:schema>
</wsdl:types>
In this small example, the Account.xsd schema contains all sorts of Account-specific definitions that we may pass around internally to our app (on Queues, to functions, as objects, without SOAP) and GetAccounts.xsd contains definitions for GetAccountsResult and GetAccountsResponse and other useful "container" definitions in a separate namespace.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Simon Fell
Comments are closed.