.NET & XML

The .NET Framework

Unlike Windows (and operating systems generally), .NET is a software platform that enables developers to create software applications that are network-native. A network-native application is one whose natural environment is a standards-based network, such as the Internet or a corporate intranet. Rather than merely coexisting with the network, the network-native application is designed from the ground up to use the network as its playground. The alphabet soup of network standards includes such players as Internet Protocol (IP), Hypertext Transfer Protocol (HTTP), and others.

.NET enables componentization of software; that is, it allows developers to create small units of functionality, called assemblies in .NET, that can later be reused by other developers. These components can reside locally, on a standalone machine, or they can reside elsewhere on a network. Componentization is not new; previous attempts at building component software environments have included Common Object Request Broker Architecture (CORBA) and the Component Object Model (COM).

An important factor in the componentization of software is language integration. You may already be familiar with the concept of language independence, which means that you can develop software components in any of the languages that .NET supports and use the components you develop in any of those languages. However, language integration goes a step further, meaning that those languages support .NET natively. Using the .NET Framework from any of the .NET languages is as natural as using the language’s native syntax.

Building on top of these basic goals, .NET also allows developers to use enterprise services in their applications. The .NET Framework handles common tasks such as messaging, transaction monitoring, and security, so that you don’t have to. Enterprise services that .NET takes advantage of can include those provided by Microsoft SQL Server, Microsoft Message Queuing (MSMQ), and Windows Authentication.

Finally, .NET positions software developers to take advantage of the delivery of software functionality via web services. “Web services” is one of the latest buzzwords in the buzzword-rich world of information technology; briefly, a web service represents the delivery of application software functionality, over a network, on a subscription basis. This application functionality may be provided directly by a software vendor, as in a word processor or spreadsheet that runs within a web browser, or it may be provided in a business-to-consumer or business-to-business manner, such as a stock ticker or airline reservation system. Web services are built, in large part, on standards such as Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL).

Each of these goals builds on and relies on each of the others. For example, an enterprise service may be delivered via a web service, which in turn may rely upon the Internet for the delivery of data and components.

The .NET environment is composed of a group of products, each of which provides a piece of the total .NET puzzle. The .NET Framework is the particular set of tools that a developer can use to produce .NET applications and services. Figure 1-1 shows the .NET Framework architecture.

Figure 1-1. .NET Framework architecture

As Figure 1-1 suggests, the .NET Framework (which I’ll often refer to simply as .NET throughout the rest of the book) has a layered structure that resembles a wedding cake. The bottom layer consists of the operating system, which is generally a member of the Windows family—although it doesn’t need to be. Microsoft has provided .NET implementations for MacOS and FreeBSD, and there are open source efforts to implement it on other operating systems.

Above the operating system is the Common Language Runtime, (CLR), which is the actual execution environment in which .NET programs run. The CLR does exactly what its name implies; it provides a common set of constructs that all .NET languages have access to, and, in fact, they must provide language-specific implementations of these common constructs. (For further information, see .NET Framework Essentials, by Thuan Thai and Hoang Lam (O’Reilly).)

Above the OS and CLR are a series of framework classes, including the data and XML classes, which provide higher-level access to the framework services; framework base classes, which provide I/O, security, threading, and similar services; and services classes, such as web services and web forms. Finally, your custom applications make up the top layer.

To reiterate, here are some of the terms I’ve introduced in this discussion of the .NET Framework:

The Common Language Runtime

The CLR is the layer of the .NET Framework that makes language independence work. Written mostly in Microsoft’s new language, C#, the CLR provides services that any .NET program can use. Because of .NET’s component architecture, software written in any language can call upon these services.

Microsoft has also submitted a subset of the CLR to ECMA, the European information and communications standards organization. This subset is referred to as the Common Language Infrastructure (CLI).

The Framework Class Library

The FCL contains the classes that allow you to build applications and services quickly and easily. These classes are used for file access, network socket communication, multithreading, database access, and a host of other functions.

Data and XML classes

Although they are still a part of the FCL, the data and XML classes deserve to stand on their own in an introduction to .NET. These are the classes that enable you to work with data in a variety of formats.

Services

The services layer makes up .NET’s remoting and web services capabilities, which I’ll talk about more in a minute. This layer also contains the user interface services, including Web Forms and Windows Forms.

Applications

Finally, your applications are at the top. These applications are not limited to accessing only the previous layer of services; applications can, and often do, make use of all the lower layers.