Microsoft .Net Framework, Delivering software as a service

With the release of the .NET Framework, Microsoft is taking the most significant risk in its history. Microsoft has spent billions of dollars, representing over 80 percent of its R&D budget, on designing and constructing this fundamental shift in its development tools in order to build a framework for the future of application development.

Microsoft has effectively realized its vision of Windows in every PC and a PC on every desktop. Its current problem is that the desktop represents only a portion of the new Internet universe. With the huge shift brought on by the Internet and its pervasiveness into everything from watches to cell phones to cars, Microsoft must now shift its view of the future from a PC-centric orientation to a service-centric orientation.

So what is the future? From Microsoft's point of view, the future is delivering software as a service. Instead of purchasing a shrink-wrapped installable solution, you will instead rent, borrow, or purchase application logic across a distributed network. Software will of course still be sold on store shelves. However, most, if not all of the business logic and power of these applications will reside across a set of distributed applications using open Internetbased standards such as XML and HTTP. This framework will open extensive new possibilities for you in the process of designing, constructing, delivering, licensing, and collecting fees for your software.

Why Microsoft .NET?
Why would you as a developer invest in learning and understanding this new foundation of products and services? Those of you who are practicing solution developers already probably have a code base of Windows- and Internet-based applications written in Visual Basic, ASP, C++, or a combination of all three. If you have to address Windows API calls from C++ and Visual Basic and then integrate those calls as a COM component called by an ASP page, you will be amazed at how the .NET Framework based classes provide a common approach and object model to accessing Windows services and resources.

You will be further impressed at how the choice of development languages is no longer dependent upon power, flexibility, or support of OOP best practices. Now all languages compile to a Microsoft Intermediate Language (MSIL) and execute against a Common Language Runtime (CLR).
Previous Post
Next Post
Related Posts