Anyone remember IDL back from the good ol' COM/DCOM days? Even though I used to do a lot of VB (versions 3.0-6.0; I'm now recovering nicely thankyouverymuch), I always had interest in how IDL worked and had Mr. Box's Essential COM tome bookmarked at the page containing the the datatype compatibility between C++, VB (and scripting). The C++ "design IDL first" vs. the VB "code first and let VB generate the IDL goo" just added to the my-tool-is-better-than-your-tool issues.
I found Mr Skonnard's article: Service Station: Contract-First Service Development -- MSDN Magazine, May 2005 a very interesting in how, like many other things in technology, we're back to repeating ourselves in the web service world with WSDL First vs. Code first (the ASMX plumbing) displacing IDL vs. Code first.
Defining an abstraction via any Definition Language (IDL or WSDL) and coding to it seems much more like engineering/constructing something intentionally vs. just hacking the functionality out and refactoring it later. This can only improve the quality of the system, thereby making maintenance and extensibility better (and perhaps even possible)!
On our current project, we've been able to use contract first to help us go faster; by working together to define the WSDL, I was able to get the client side objects created and hooked up to the UI, while Mork and Neil started on the backend plumbing. Even though the standard vs.net tools around creating XML schema and WSDL are not high-productivity tools, we do ok w/ them and have hopes for a future where either we write our own version of wsdl.exe, or grab the source from wsdl.exe and refactor it into something that generates more useful proxy classes! :)
I'm looking forward to part two of Aaron's article!
Contract first baby! (think: Just win baby!)
jk
No comments:
Post a Comment