In the May 21, 2002, issue of Windows Web Solutions UPDATE, I explained why Web developers can build more powerful Web applications faster in ASP.NET than they can in traditional Active Server Pages (ASP). The availability of more than 6500 Microsoft .NET framework classes gives Web developers Win32-caliber power but with simplicity that beginning or average-level Visual Basic .NET developers can handle easily. Also, Visual Studio .NET's automatic code-generation feature lets the programming tool do much of the work for Web developers.
I received an overwhelming reader response to the May 21 article, which seems to have persuaded many traditional administrators (such as Microsoft IIS administrators) who aren't software developers to dive into ASP.NET with Visual Studio .NET and start building applications, prototypes, and pilots. I think this reaction is very exciting. I've answered numerous email messages asking such questions as, "How do I get started?" "What is the best book to get me started?" and "Where do I get an evaluation copy of Visual Studio .NET?"
Few things satisfy seasoned developers as much as beginning a project with a well-thought-out design and prototype. Other than a learning curve that many administrators are finding pretty fun, nothing is holding administrators back from using Visual Studio .NET to build prototypes and eventually production-class applications. However, here is a common misconception about .NET: As easy as Visual Studio .NET makes application development, it doesn't replace a seasoned software architect. You still need experienced software developers to design enterprise-class applications from the bottom up.
Another misconception about the conceptual difficulties of .NET involves Web services, which hold the promise of seamless distributed computing over the Internet. Web services enable interoperability and truly distributed computing among numerous platforms. But unlike distributed technologies of the past, which were dependent on proprietary object models and proprietary programming languages, Web services work in a loosely coupled and vendor-neutral environment.
One reason seamless distributed applications haven't existed on the Internet is because firewalls preclude the use of efficient binary protocols (e.g., Distributed COM—DCOM) that are traditionally used for distributed computing. .NET Web services use Simple Object Access Protocol (SOAP), which delivers XML through port 80 (or an alternate port) to other systems and even other platforms. Web services aren't just a "Microsoft thing"; they're an industry standard. Microsoft just makes building Web services easy with Visual Studio .NET, which lets you click your way to building a simple Web service without writing any code.
If you understand some of the basic concepts of COM, you can easily understand the functionality of a Web service: A Web service has public methods exposed to the Internet, much like the methods of a COM object. A Web service is like a COM object turned inside out (i.e., inside the firewall to outside the firewall); that is, the methods are exposed on the Internet and can be called from anywhere (if the proper security privileges exist) on the Internet. As a Microsoft platform developer, I find the idea of calling a method on a Sun Microsystems' Java system across the Internet and retrieving the results to use in an application running on the Microsoft platform very exciting and powerful.
I think you'll agree that the .NET platform and its accompanying toolset give developers power we never dreamed of having when we were building traditional ASP applications. Can you imagine what improvements Microsoft has in store for the next versions of these technologies? I'll be writing about those improvements in the months to come.
