This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Why don't .NET developers grok scalable distributed computing?
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
I have had this essay gnawing in my head for at least three months and have been trying to phrase it, think through it, agonizing over it. Seeing Clemen's post made me feel better as he observes the exact same thing. First a little story. In doing research for my INETA Choosing ADO.NET Data Access Options for ASP.NET talk, I had the chance to go over just about every ASP.NET book out there and their “data chapters“; over twenty of them at last count Not a single one of them ever talked about distributed data access except for one - Homer and Sussman's Distributed Data Applications with ASP.NET. In fact, many carried on about choosing DataReaders almost exclusively and even passing them around in layers. This is not to mention all the other problems with the books being highly simplistic and non-real world. Rob Howard's presentation on ASP.NET Best Practices advises to use DataReaders unless you absolutely need DataSets.
Now, don't get me wrong; I am the first to want to use DataReaders over the bloated and large memory overhead DataSet creating a whole heirarchy of objects underneath. I find any reason I can not to use DataSets, especially in the data-driven display but not update world of many ASP.NET apps. But one fact remains. DataReaders will not go over either ES or Remoting boundaries across the wire. They don't scale. So you read all these ASP.NET books and wonder if anyone ever built an enterprise multi-tier distributed system with ASP.NET. It isn't just about DataSets obviously. You talk with developers, read blogs, and you come to the same conclusion that Clemens comes up with: “very many of them apparently still write fairly compact (to avoid the word monolithic) ASP.NET applications or Windows Forms applications that use a conservative client/server approach. All presentation and logic resides in one tier and the only remote component worth mentioning is the database.”
Scary, shades of the 1980's client/server days. Now, I have always built distributed systems. When I was working at Digital in the late 1980's. I worked with and on DCE RPC which was really the first of these distributed technologies that later COM, DCOM, Corba, etc would be based on. Back then everyone worked on distributed systems. It was something nearly every one just learned. As we progressed through initial Acesss/VB front-ends to databases client/server systems in the early 90's we quickly realized that they didn't scale, they didn't support the ACID rules of transactions. MTS was a revolution for us in 1997 and I jumped on board. I have been building distributed systems since with MTS, COM+, ES and some work with EJB/Corba in the Java space. For years and years, we have been seeing N-tier architectures with the famous three of four tiers.
The client/server solutions that we discarded so long ago, and now most .NET developers seem to be utilizing, are fairly easy to implement but tend to have limited scalability. So people just add boxes. A better solution is to add a middle tier for things like business logic. Of course its not mandated that that middle tier must be on a seperate box(es) but doing so allows for scalability by distributing various functional areas of the application to seperate nodes and usually gives far better performance relative hardware costs. Gosh, we were doing this in Windows DNA with COM+. So why isn't it being done in .NET systems today? Sure, it's going on but you would never know it from any .NET books, blogs, conferences (virtually nothing on ES) out there. In sharp contrast, the Java community gets it. They tend to think enterprise. The Java developers tend to know how to build distributed applications that scale. From my time spent there years ago, I was much more likely to find a discussion of a distributed transactional EJB app at a local user group than some dog and pony data binding with a data grid demo that tends to permeate a lot of .NET user groups. MSDN articles on architecture tend to get low scores because .NET developers just want to put something together.You look at the MSFT Architecture main page with lots of great Architecture resources and look at the low score people have given it. Screw it they say, just show me that drop in Server control again.
This is not to say that all applications need or must be distributed applications or applications that need features of things like ES or transactions. There are plenty of monolithic LOB and utility apps that don't apply to what I am talking about here. I am talking about the tendency of many ASP.NET applications or Windows Forms applications that use a conservative client/server approach. All presentation and logic resides in one tier and the only remote component worth mentioning is the database.
It's important to not be scared of these technologies but to embrace them. Sites like Microsoft's Architecture Center, PAG, and ServerSide.NET are big steps in the right direction. ES, Web Services, Remoting and the culmination in Indigo have a huge amount of value to give to your applications. Distributed computing is your friend.
Previous Topic
