In writing my book, I’ve had a chance to compare the two BizTalk service generation wizards, and I now remember why the BizTalk Web Services Publishing Wizard (ASMX) drove me nuts.
Let’s look at how the WCF Wizard and ASMX Wizard take the same schema, and expose it as a service. I’ve purposely included some complexity in the schema to demonstrate the capabilities (or lack thereof) of each Wizard. Here is my schema, with notations indicating the node properties that I added.
Now, I’ve run both the BizTalk Web Services Publishing Wizard (ASMX) and the BizTalk WCF Service Publishing Wizard (WCF) on this schema and pulled up WSDL of each. First of all, let’s look at the ASMX WSDL. Here is the start of the schema definition. Notice that the “Person” element was switched back to “sequence” from my XSD definition of “all.” Secondly, see that my regular expression no longer exists in the “ID” node.
We continue this depressing journey by reviewing the rest of the ASMX schema. Here you can see that a new schema type was created for my repeating “address” node, but I lost my occurrence boundaries. The “minOccurs” is now 0, and the “maxOccurs” is unbounded. Sweet. Also notice that my “Status” field has no default value, and the “City” node doesn’t have a field restriction.
So, not a good story there. If you’ve thoughtfully designed a schema to include a bit of validation logic, you’re S.O.L. Does the WCF WSDL look any better, or will I be forced to cry out in anger and shake my monitor in frustration? Lucky for me (and my monitor), the WCF wizard keeps the ENTIRE schema intact when publishing the service endpoint.
There you go. WCF Wizard respects your schema, while the ASMX Wizard punches your schema in the face. I think it’s now time to take the ASMX Wizard to the backyard, tie it to a tree, and shoot it. Then, tell your son it “ran away but you got a brand NEW Wizard!”