| Clearly, a considerable amount of infrastructure is required to make XML Web Services transparent to the developers and users. The .NET Framework provides that infrastructure. To the .NET Framework, all components can be XML Web Services, and XML Web Services are just a kind of component. In effect, the .NET Framework takes the best aspects of the Microsoft Component Object Model (COM) and combines them with the best aspects of loosely coupled, XML-based 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 two main parts: the Common Language Runtime (CLR) and a set of unified class libraries. The class libraries include versions of many of Microsoft's existing development technologies, such as an advanced version of Active Server Pages, called ASP.NET, a set of classes for rich user interface development, called Windows Forms, and a data-access subsystem called ADO.NET. All these existing libraries have been updated to be XML aware within the .NET Framework. The Common Language Runtime Despite its name, the Common Language Runtime actually has a role in a component's development time and runtime experiences. While the component is running, the runtime is responsible for managing memory allocation, starting up and killing threads and processes, enforcing security policy, and 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 (for example, 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 has 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 runtime and development environment across all programming languages. The .NET 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 or J2EE, and Visual Basic developers will use VB's APIs. Simply put, the .NET CLR unifies the disparate frameworks Microsoft has today. The result is that dev-elopers no longer have to learn multiple frameworks when working in multiple languages. 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 they want to use. Here are some of the key benefits of the .NET Framework for developers: Can use any .NET-enabled programming language. The .NET Framework enables developers to use any .NET-enabled programming language, and it enables applications written in these languages to integrate deeply with each other, which means current development skills can be used right away within the same project and future projects. Can write less code. The .NET Framework uses a highly "componentized," plumbing-free design that enables developers to focus on writing business logic. Developers don't need to write Interface Definition Language (IDL) or Registry code anymore. ASP.NET, for example, includes dozens of controls that encapsulate common programmer tasks, such as user validation, creating calendars and ad rotators, and much more. Can use XML and SOAP without learning these technologies. The .NET Framework was built for delivering software as a service, so it is built on XML and the SOAP family of integration standards. Simply annotate method calls and the .NET Framework turns them into full XML Web Services. You do not need to learn these underlying technologies because the .NET Framework wraps classes around them. Can run more reliable applications. The .NET Framework includes technologies to make applications more reliable. For example, memory, threads, and processes are managed by the .NET Framework to ensure that memory leaks don't occur. Also, ASP.NET monitors running Web applications and can automatically restart them at administrator-defined intervals. In addition, when applications are upgraded (versioned), the .NET Framework includes technologies to avoid version conflicts (often called DLL hell). Can improve performance. The .NET Framework improves the performance of typical Web applications. ASP.NET includes advanced compilation and caching features that improve performance by a factor of two to three over existing Active Server Pages applications. Figure 2.1 gives you an overview of how the different pieces of the .NET Framework relate to one another. Figure 2.1. All the layers of the .NET platform, from the OS all the way up to the highest-level classes.
The Win32 APIs are at the lowest level in this platform. Above are the common services built in to the OS, with which you can interact. These include the message queuing services, transactions, Internet Information Server (IIS), and the Windows Management Instrumentation (WMI). The CLR in the .NET Framework interacts with these lower-level services so all .NET languages can interact with these services using a common interface. On top of the CLR is a framework of classes, including ADO.NET and ASP.NET. Next comes the set of languages that have been written to take advantage of the .NET Framework. These languages are most of the common languages in use today, including Visual Basic, C++, C# (a new language), COBOL, Perl, Python, Eiffel, and many others. Common Language Specification The Common Language Specification (CLS) is a contract that states how a language that interacts with the CLR will behave. When languages use the CLS, they are said to be using managed code. Managed code is a set of language constructs that all .NET languages must contain, including data types, error handling, metadata, and so forth. Managed code can be broken down by a compiler into a set of bytecodes, known as the Microsoft Intermediate Language (MSIL or IL). The MSIL is stored, along with some metadata about the program itself, in a portable executable (EXE or DLL). Intermediate Language Intermediate Language (IL) is used so that a compiler can translate the program into the final code, which can, in turn, be interpreted by the OS and the hardware. Using IL makes it easier to create a compiler for that IL for any OS and hardware platform. The compiler for .NET is called a Just-In-Time (JIT) compiler. When you distribute a DLL or EXE file, it is not in an executable format. Instead, it is in a Microsoft IL (MSIL) format that will be compiled into native code for the target operating system. This compilation can either be done at runtime (JIT) or when the program is installed for the first time. In either case, it is the JIT compiler that performs this compilation, as shown in Figure 2.2. Figure 2.2. Managed code is compiled down to MSIL, which is then compiled by the JIT compiler.
Services in .NET The .NET Framework supplies many services to a developer. Here are some of the most notable ones: Memory management Threads Garbage collection Exception handling Security Application isolation Data interaction Encryption services Deployment In the past, to get all these sophisticated services, you either had to build them yourself or use a higher-level language. The problem with building these services yourself is they are ancillary to the actual program. Most customers just want a business problem solved; they do not want you spending your time developing security systems and garbage-collection routines. In other words, they just want you to give them a program that solves their problem. Therefore, in a low-level language, you might end up spending twice as long to get an application that accomplishes the business purpose because you have to spend so long on designing all of these infrastructure services. If you use a high-level language, most of these services are built in. However, if they are not built in to the language, you might not be able to build these services because the language is so far removed from the OS. This means that it is difficult, if not impossible, to take advantage of threading or security from that language. All these services can be used from any language that works with the CLR. So now your choice of language does not matter so much, because everything compiles down to the same Intermediate Language. Data Services (ADO.NET) One of the new services built in to the .NET Framework is a complete new data-access model called ADO.NET. Although it has the same name as an earlier data-access technique, called ADO, it is very different. You might recognize some of the objects that are similar to the Connection and Command objects in ADO, but there are enough different methods and properties to keep you on your toes. The biggest difference between the two models is how the data is stored in memory after it is read from the database. In ADO, the recordsets were stored in a binary format. In ADO.NET, they are stored as XML. Another big change is that ADO.NET is disconnected. That is, ADO.NET does not keep any connections open after reading the data in from a data source. There are several new classes, such as Command, DataAdapter, DataReader, and DataSet. The Recordset object is gone, and all records are read either from the DataReader or the DataSet object. DataSet objects allow you to read in several tables into one object. You can then set relationships between the tables in memory as well as add, edit, and delete the data in these tables, and you can store the data back in the database. The schema for the tables is also read in and stored in an XML format. ADO.NET has the capability to natively read and write to XML. In addition, you can use OLE DB or native providers to read data from data sources such as SQL Server, Oracle, and Access. Security Services Security is pervasive throughout the .NET Framework. Table 2.1 shows some of the different types of security that you can set up for your applications. Table 2.1. The Different Security Types in .NET | Security Type | Description | | Access Control | Secures objects, such as files, Registry keys, and directory service objects | | Security Support Provider Interface | Establishes authenticated connections | | Logon Authenticated | Provides for password filtering, Windows logon, and local security authentication | | Certificate Services and Components | Issues and manages certificates | | Cryptography | Provides a set of classes based on the Crypto API functions in Windows 2000 | | Smart Card | Allows you to integrate with smart card based authentication | | Policy Management | Programmatically sets and manages local security policies | Common Type System and Standard Data Types As part of the .NET Framework and the CLR, it is important that all languages have access to common data types. This makes the interoperability between languages much easier. To accomplish this, Microsoft has created the Common Type System with a standard set of data types that each language can utilize. Data types in .NET are no longer defined by each language. Instead, they are a core part of the CLR. Each data type is itself an object. Each language has the choice to implement all of them or just a subset. Table 2.2 lists each of the different data types and tells which languages implement each one. Table 2.2. Each Data Type in the .NET Framework Is Actually Implemented as a Class | Data Type | Description | Language Usage | | Byte | 8-bit unsigned integer | Visual Basic: Byte C#: Byte Visual C++: Char | | Sbyte | 8-bit signed integer | Visual Basic: N/A C#: sbyte Visual C++: signed char | | Int16 | 16-bit signed integer | Visual Basic: Short C#: short Visual C++: short | | Int32 | 32-bit signed integer | Visual Basic: Integer C#: int C++: int or long | | Int64 | 64-bit signed integer | Visual Basic: Long C#: long Visual C++: _int64 | | Unint16 | 16-bit unsigned integer | Visual Basic: N/A C#: ushort Visual C++: unsigned short | | Uint32 | 32-bit unsigned integer | Visual Basic: N/A C#: uint Visual C++: unsigned int or unsigned long | | Uint64 | 64-bit unsigned integer | Visual Basic: N/A C#: ulong Visual C++: unsigned __int64 | | Single | 32-bit floating-point number | Visual Basic: Single C#: float Visual C++: float | | Double | 64-bit floating-point number | Visual Basic: Double C#: double Visual C++: double | | Boolean | True (1) or False (0) | Visual Basic: Boolean C#: bool Visual C++: bool | | Object | The base type of any class or data type | Visual Basic: Object C#: object Visual C++: Object | | Char | Unicode character (16 bit) | Visual Basic: Char C#: Char Visual C++: __wchar_t | | String | A string of Unicode characters | Visual Basic: String C#: string Visual C++: String | | Decimal | 96-bit decimal value | Visual Basic: Decimal C#: decimal Visual C++: Decimal | |
