Came across a very interesting video on Channel 9 dealing with the future BizTalk Solution Designer. It looks really good and now i cant wait to get my hands on it. I was thinking of experimenting with DSL's in VS2005 and building something that does a very similar task, to be able to graphically sketch out stuff from receieve adapters, through locations, pipelines, orchestrations and into the message box (and out again). And I want to be able to use GAT packages , project templates and so on. Well, we might have some of that when the official tool comes out.
The only 'drawback' perhaps, is that it isnt built using the Whitehorse kind of design surface nor is it done with the DSL design tools available today. Now this could be for a very good reason. The AD surface probably just isnt rich enough (and when you see the whizzy stuff in the BTS SD like the redrawing and consolidation of shapes you will understand why) and the DSL tools are still in a very early stage, although some folks are managing to put them to good use (such as the DSL that goes with WSCF) But Im sure this wont be insurmountable. After all, they are looking at a release date beyond 2006 for this tool and the DSL team would sure love to get their hands on a real world killer application (not to mention that AD could be done with the DSL designer too, the ultimate dog-fooding) which would help them mature their product really quickly.
The other reason they should do it is for platform/tool coherence sake. As it is there is a big divergence in tools. I discussed this with some of the project team reps in TechEd Amsterdam. For instance Beat Schwegler demo'ed the Melted Cheese GAT package where his webservice consisted of around 8 projects. That was all well and good, but if you put a Webservice in your project design surface in AD, it generates a single project. There is no way to customize it to make it generate an entire solution for the WS like the GAT package would have us do, neither can it use Enterprise Templates, nor can it even be customized with Project Templates (the simplest of the lot) so that doesnt leave architects with many options if you want to spec out a multi solution architecture (of course you could manually refactor the stuff and extract the WS into its own solution and have an AD for that alone) but then you lose some of the point of using the AD in the first place as it would be just a pretty model. Apparently there are some efforts on to get some convergence in these tools so that architecture creation and representation is more consistent and I for one am very eager to see the progress here.
So coming back to the point, I like the idea of the solution designer and for MS sake i hope things progress to the point where this utilises the DSL designer. Wonder what Steve Cook would say to this.
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.