Santosh Benjamin

BTS Diary 8 - The Care and Feeding of Interfaces

So here I am back again after a long hiatus. I was quite deeply involved with getting the Immediacy CMS part of our solution going and there wasnt any new ground covered on the BizTalk front. The CMS turns out to be quite easy to use with some quirks here and there but definitely better than MCMS.

Now to the topic of this post and its title. We created a schema to provide to our suppliers with the intention that this will form the core web service through which they can send us their data. The WS forms just another entry point into the system along with the FTP. In fact all the WS does is serialise the message into a file and stick it into the FTP folder , which is a BTS Receive location so there is no need for extra pipelines or orchestrations. Anyway, as in the rest of the solution we took XSDObjectGen (or it may have been XSD.exe that got accidentally used) and created the classes which we stuck into the Business Objects assembly. The WS then referenced that and generated the WSDL. All was fine upto this point.

We then moved on to the client to check if our service was actually usable. We created the object required by the proxy and sent it across and found that very few elements actually got across. After quite a bit of investigation we found that the code generator had created some extra elements for booleans, enums and some float values with the basic element name suffixed with a 'Specified'. So for a IsApplicable field we had an extra one called IsApplicableSpecified and if this member was not set, then the Xml did not contain the IsApplicable value either. I remember coming across this in XSD.exe a year ago but living with it (when sending data across to a remoting server), but looking at it from a "contract" point of view, i think its disgusting. Those "Specified" fields were not in the WSDL, so how is a proxy to know anything about them. More importantly, why are they there? The functionality is not compromised if those fields are missing.

This is why we need to focus a lot on the contract and have tools like WSCF generate the stubs from the XSD and WSDL otherwise these dodgy issues can foul up a project. Imagine explaining to clients that they need to populate some hidden fields because a psycho code generator decided they were needed. Of course, we can always delete those elements from the class, but thats such an awful waste of time. Might as well not include it in the first place. As a rule hereafter, for myself, the XSD.exe and XSDObjectgen have no place in my webservices. They can be used in the code in other places (until I can find the time to write my own version) but thats all. I havent had time to go through WSCF in detail (except for reading the documentation on the site), but after reading it  and also going through Jeffrey Hassans interesting book "Expert SOA in C#", i'm beginning to see the advantages of Contract First development.

If anyone would like to defend XSDObjectGen or XSD.exe and tell me why those extra fields are actually necessary, pl do drop me an email and let me know your thoughts. Would also be happy to share if you want to rant about them.

And while we are on the subject of BizTalk, I must point out that I hadnt had an occasion to publish an orchestration as a webservice till recently and then i found that BTS in its infinite wisdom generates one ASMX for every single method that you want to expose. Sure you can write your own ASMX front end and connect that to BTS, but it begs the question, why multiple ASMX files? couldnt they have at least provided an option to allow you to aggregate them into one file? I hope this is fixed in 2006 cos thats one of the requirements for a project Im moving on to and i dont want to waste time coding extra facades when the tool is supposed to handle WS interfaces properly.