Rant: Moving Targets
A trip back in time. In 2000 we were starting a large project. The architecture was pretty standard stuff – database server, application server with business objects, semi-thin desktop client, featuring bi-directional communication between the clients and the server. All were Windows native applications. During the design phase the question about the inter-tier communication technology came up. Back then, Windows DNA1 was the super-dee-duper stuff out there, praised by Microsoft as the prime guide to making distributed applications. We decided to follow its wisdom, and built the communication layer on top of Distributed COM and COM+. Oh, why, why?
I have huge respect for COM as a technology, and within a single workstation it is a wonderful instrument for application interoperability and extensibility. However, when you stick your head out in the outer world, things get tough. Every weathered COM developer will tell you what a nightmare it is to setup and configure DCOM in a local network. Yes, once configured properly, it is solid. But that is only when you configure it. God forbid you have to setup DCOM in a network without Active Directory. Even with AD, doing DCOM callbacks is as pleasant as a trip in a swamp, plagued by mosquitos and crocodiles. DCOM over the Internet? Please. That works only in Microsoft papers from late 90s, when the Internet was not plagued by hackers, worms and trojans, and there was little need for firewalls.
By 2005 the product was successful and the number of installations was increasing, and we found ourselves wondering how the hell to get rid of COM, and replace it with something as high-performing, but easy to deploy. Before you start giving bright ideas about the next hot shit on the block – Java RMI, NET Remoting, web-services, just think about the hundreds of thousands lines of native Win32 code we simply had to preserve. We needed something that would plug in with minimal changes in the existing code base.
This time we approached the problem very carefully and full of suspicions about every new thing out there. Rumors already had it that Remoting was not as hot as it seemed at first, and its abilities for bi-directional communications were more trouble that real use. Microsoft was already murmuring about the next hottest thing – WCF, which was supposed to solve all communication problems again. Yeah, right.
We considered really many things, including .NET Framework. We designed a dozen of bridge applications, only to scrap them all. Our analysis indentified that the types of data we were transferring were standard types as integer, float and string, ADO Recordsets, and Variants. And the server-to-client communication, of course, that was supposed to work even for clients behind firewalls. The common types are trivial to marshal across a network with any technology out there. The other two are sweet with COM. Marshalling ADO Recordsets is not that hard actually, because ADO can save and load recordsets to streams. Sweet. Marshalling Variants is a bigger issue, as COM keeps this part strictly undocumented. However, we managed to do that, too.
Having achieved that, we made our decision. We implemented our own RPC protocol, based on TCP/IP. It was capable of marshalling all necessary data types, and supported bi-directional communications through firewalls.
The DNA->Remoting->WS->WCF technology transition is not the only one in the world. Sun Java also adopted web services and kind of forgot about RMI. Microsoft recently made it clear that WinForms will be retired with honors to give way to WPF.
Technology is dynamic, and so is the world. I do not blame Microsoft, neither anyone else. The price of progress is the low long-term value of moment achievements.
The moral of the story is: never, ever trust newest technologies as the best cure for all problems. Always test them against your case. And, sometimes, you’d better do it your own way. More often than not the investment is worthy.
1. There is no more a homepage for Windows DNA. www.microsoft.com/dna quitely forwards you to NET Framework.