Learn .NET

What you should already know

To read and understand this, a basic understanding of COM and ASP/VB programming would be useful.

Introduction

Application development is undergoing a major shift - a shift that will ultimately increase developer productivity and open the way for a new class of applications.

Historically, developers built applications by integrating local system services. This model gave developers access to a rich set of development resources and precise control over how the application behaves.

Developers have already largely moved beyond this model. Today, developers are building complex N-tier systems that integrate entire applications together from all over their networks and then add unique value on top. This enables developers to focus on their unique business value rather than building infrastructure. The result is lower time to market, higher developer productivity, and, ultimately higher-quality software.

We're entering the next shift, and it's a shift enabled by the Internet - specifically the key Internet technology, XML. Whereas N-tier application development focused on building great applications for your corporation, XML is enabling the creation of great applications that can be used by anyone, anywhere. It increases the reach of applications and enables the continual delivery of software not so much as something you install from a CD, but as a service - a service like caller ID or like pay-per-view.

It does this by coupling the tightly-coupled, highly productive aspects of N-tier computing with the loosely-coupled, message-oriented concepts of the Web. This style of computing is called Web services and represents the next evolution of application development. A Web service is an application that exposes its features programmatically over the Internet or intranet using standard Internet protocols like HTTP and XML. Think of it as component programming over the Web.

Conceptually, developers integrate Web services into their applications by calling "Web APIs" just as they call local services. The difference is that this call can be routed across the Internet to a service residing on a remote system. For example, a service such as Microsoft Passport could enable a developer to provide authentication for an application. By programming against the Passport service, the developer can take advantage of Passport's infrastructure and rely on Passport to maintain the database of users, make sure that it is up and running, backed up properly, and so on.

Loose Coupling

The concept of distributing application logic over a network isn't new. The concept of distributing and integrating application logic over the Web is.

Previously, distributed application logic called for a distributed object model such as Microsoft's DCOM, the OMG's CORBA, or Sun's RMI. Using this infrastructure, developers can maintain much of the richness and precision that they're used to with the local programming model, yet still place services on remote systems.

Web services are loosely coupled - where you can change the implementation at either end of a connection and the application will continue working. Technically, this translates to using message-based, asynchronous technology to achieve robustness, and using Web protocols such as HTTP, SMTP, and, most importantly, XML to achieve universal reach.

Messaging systems wrap up the fundamental units of communication into self-describing packages (called messages) that they put onto the network wire.  In this way the receiver of the SOAP message is free to upgrade and improve without breaking any current applications. Further, the sender doesn't require any special software to be able to talk with the receiver: as long as it can emit properly formed messages!

XML on the Wire: SOAP

The key to making Web Services work across the Web and its heterogeneous infrastructure is to agree to a simple data description format. That format is XML. Specifically, Web Services require XML for three things: the basic wire format, service description, and service discovery.

SOAP

At the lowest level, systems need to speak the same language. In particular, communicating applications need to have a set of rules for how they are going to represent different data types (e.g., integers and arrays) and how they are going to represent commands (i.e., what should be done with the data). Also, the applications need a way to extend this language if they have to. The Simple Object Access Protocol (SOAP), an implementation of XML, represents one common set of rules about how data and commands will be represented and extended.

SOAP Contract Language

Once applications have general rules for how they will represent data types and commands, they need a way to describe the specific data and commands they accept. It's not enough for an application to say that it accepts integers; somehow, there must be a way to deterministically say that, if you give it two integers, it will multiply them. The SOAP Contract Language (SCL) is an XML grammar that developers and development tools can use to represent the capabilities of a Web Service.  

This is also known as a .DISCO file in the past.  These .DISCO files have been merged into the architecture.

SOAP Discovery

The final layer that you need is a set of rules for how to locate a service's description - where does a human or tool look by default to discover a service's capabilities? The SOAP Discovery specification provides a set of rules so that a human or development tool can automatically discover a service's SCL description.

This level is now called UDDI (http://www.uddi.org) which stands for Universal Description, Discovery, and Integration.

Once these three layers are in place, developers can easily find a Web service, instantiate it as an object, integrate into their applications, and build enough infrastructure so that the resulting application can communicate back to the Web Service.

The .NET Framework: A Web Services Engine

Clearly, there is a considerable amount of infrastructure required to make this process transparent to the developers and users. The .NET Framework provides that infrastructure. To the .NET Framework, all components can be Web services, and Web services are just a kind of component. In effect, the .NET Framework takes the best aspects of COM (the Microsoft Component Object Model) and combines them with the best aspects of loosely-coupled computing. The result is a powerful, productive Web component system that simplifies programmer plumbing, deeply integrates security, introduces an Internet-scale deployment system, and greatly improves application reliability and scalability.

The .NET Framework consists of three main parts: the common language runtime, a hierarchical set of unified class libraries, and an advanced version of Active Server Pages called ASP.NET.

The Common Language Runtime

Despite its name, the runtime actually has a role in a component's development time and run time experiences. While the component is running, the runtime is responsible for managing memory allocation, starting up and killing threads and processes, enforcing security policy, as well as satisfying any dependencies that the component may have on other components. At development time, the runtime's role changes slightly: because it automates so much (e.g., memory management), the runtime makes the developer's experience very simple, especially when compared to COM today. In particular, features such as reflection dramatically reduce the amount of code a developer must write in order to turn business logic into a reusable component.

Runtimes are nothing new for languages: virtually every programming language has a runtime. Visual Basic is the most obvious runtime (the aptly-named VBRUN), but Visual C++ has one (MSVCRT), as do FoxPro, JScript, SmallTalk, Perl, Python, and Java. The .NET Framework's critical role, and what really sets it apart, is that it provides a unified environment across all programming languages.

Unified Programming Classes

The .NET Framework's classes provide a unified, object-oriented, hierarchical, extensible set of class libraries ("APIs") for developers to use. Today, C++ developers will use the Microsoft Foundation Classes, Java developers will use the Windows Foundation Classes, and Visual Basic developers will use VB's APIs. Simply put, the frameworks unify the disparate frameworks Microsoft has today. The result is more than developers no longer having to learn multiple frameworks. By creating a common set of APIs across all programming languages, the .NET Framework enables cross-language inheritance, error handling, and debugging. In effect, all programming languages, from JScript to C++, become equals and developers are free to choose the language that they want to use.

ASP.NET

ASP.NET builds on the .NET Framework's programming classes, providing a "Web application model" in the form of a set of controls and infrastructure that make it simple to build Web applications. Developers are exposed to a set of ASP.NET controls that encapsulate common HTML user interface widgets such as text boxes, drop down menus, and so on. These controls actually run on the Web server, however, and simply project their user interface as HTML to a browser. On the server, the controls expose an object-oriented programming model that brings the richness of object-oriented programming to the Web developer. ASP.NET also provides infrastructure services such as session state management and process recycling that further reduce the amount of code a developer must write and increase application reliability. ASP.NET also uses these same concepts to enable developers to deliver software as a service. Using ASP.NET Web Services features, ASP.NET developers can simple write their business logic and the ASP.NET infrastructure will be responsible for delivering that service via SOAP.

Even though it's not even released yet, ASP.NET is already delivering some staggering improvements in Web applications - performance improvements of 3X over existing ASP-based applications, and productivity improvements even more dramatic than that.

Key Aspects of the .NET Framework

There are a few aspects of the .NET Framework that bear calling out. Principal among these are its security and deployment systems. These two systems work together to help reduce the likelihood of unsafe code being able to execute, and to cut down on some of the application deployment challenges often referred to as "DLL Hell."

Security

When a .NET Framework application is installed on a system, for example, it can collect evidence about running applications (such as where it was downloaded from, whether it is signed with an Authenticode signature, and even what precisely it is trying to access on the system) and work with an administratively-set policy to determine if the application should be allowed to run or not. The runtime can even tell the application that it can't grant all the permissions requested, and give the application the choice of continuing to run.

With such a security system in place, solving some of the problems related to application deployment over the Internet is greatly simplified.

Versioning

One of the largest challenges faced by developers and administrators (and ultimately users) is versioning. If your system works fine today and you install a new application and suddenly nothing works any more, it's very often because the new application overwrote some shared library and (more often than not) fixed some bug that existing applications were relying on.

This is so frequent, there's even a name for it: DLL Hell.  The .NET Framework includes a couple of advances that virtually eliminate DLL Hell. 

First, it includes a very strong internal naming system that makes it much harder for two libraries that may even have the same file name to be mistaken for each other. But beyond that, there's a new feature called "side by side" deployment. If that new application in the previous example really does overwrite a shared library, the existing application can actually repair itself. 

The next time the existing application starts up, it'll check all its shared files. If it finds that one has changed and that the changes are incompatible, it can ask the runtime to fetch a version it knows it can work with. Because of the security system, the runtime can do so safely, and the application can repair itself.

Conclusion

Too often, people speak platitudes like, "the Internet changes everything." Too often, they're speaking in marketing hyperbole. But the Internet truly has changed application development and deployment in fundamental ways. 

Delivering software as a service is the future, and XML is critical to enabling it. 

The .NET Framework is a key part of Microsoft's developer strategy aimed at making it easy for developers to build, deploy, and run Web services.

Sidebar: Relationship to COM and COM+

One of the primary goals of the .NET Framework was to make COM development easier. One of the hardest things about COM development was simply dealing with the COM infrastructure. Consequently, to make COM development easier, the .NET Framework automated a lot of the hard work around what developers think of as "COM," including reference counting, interface description, and registration.

It's important to note that this doesn't mean that .NET Framework components aren't COM components. In fact, a COM developer using Visual Studio 6.0 could call a .NET Framework component and, to the developer, it'd look like a COM component, complete with iUnknown. 

Conversely, a .NET Framework developer using Visual Studio .NET would see a COM component as a .NET Framework component.

Partitioning

COM+ is the name of COM when you combine it with Microsoft Transaction Server, or MTS, and DCOM. COM+ provides a set of middle-tier-oriented services. In particular, COM+ provides process management and database and object connection pooling. In future versions, it will also provide stronger process isolation designed for application service providers - a feature called partitioning.

The COM+ services are primarily oriented toward middle-tier application development and focus on providing reliability and scalability for large-scale, distributed applications. These services are complementary to the programming services provided by the .NET Framework. The .NET Framework classes provide direct access to these component services.

You can think of COM+ providing component services for building scalable, reliable distributed middle tier applications. The .NET Framework provides language services that simplify and speed up application development and deployment.

Well done!

You are now well on your way to understanding .NET and working with it.  Read the further reading examples in the focus area.

(Based on an article provided toTopXMLby Andrew Layman and John Montgomery - Andrew Layman was chief XML architect at Microsoft. John Montgomery is lead product manager for Web services and the .NET Framework at Microsoft)