The LA Fox Developer Newsletter

November 2000

“.NET” (Con't from page 5)

tion information defines where to look for assemblies, thus the runtime can load different versions of the same assembly for two different applications that are running concurrently. This eliminates issues that arise from incompatibilities between component versions, improving overall system stability. If necessary, administrators can add configuration information, such as a different versioning policy, to assemblies at deployment time, but the original information provided at build time is never lost.

Because assemblies are self-describing, no explicit registration with the operating system is required. Application deployment can be as simple as copying files to a directory tree. (Things are slightly more complicated if unmanaged components must be installed for the application to work.) Configuration information is stored in XML files that can be edited by any text editor.

Finally, the runtime also supplies integrated, pervasive security services to ensure that unauthorized users cannot access resources on a machine and that code cannot perform unauthorized actions. This improves overall system safety and reliability. Since the runtime is used to load code, create objects, and make method calls, the runtime can perform security checks and enforce security policy as managed code is loaded and executed.

The Microsoft .NET Framework provides both code access security and role-based security. With code access security, developers can specify the required permissions their code needs to accomplish work. For example, code may need permission to write a file or access environment variables. This information is stored at the assembly level, along with information about the identity of the code. At load time and on method calls, the runtime verifies that the code can be granted the permissions it has asked for. If not, a security violation is reported. Policies for granting permissions, known as trust policies, are established by system administrators, and are based on evidence about the code such as who published the code and where it was obtained from, as well as the identity and requested permissions found in the assembly. Developers can also specify permissions they explicitly don’t want, to prevent malicious use of their code by others. Programmatic security checks can be written if the permissions required depend on information that isn’t known until runtime.

In addition to code access security, the runtime supports role- based security. Role-based security builds on the same permissions model as code access security, except that the permissions are based on user identity rather than code identity. Roles represent categories of users and can be defined at development or deployment time. Policies for granting permissions are assigned to each defined role. At runtime, the identity of the user on whose behalf the code is running is determined. The runtime determines what roles the user is a member of and then grants permissions based on those roles.

Before looking at programming models in the Microsoft .NET Framework, let’s look at the services it provides.

The Services Framework

As you may recall from Figure 2, on top of the common language runtime is the services framework. This framework provides classes that can be called from any modern programming language. All classes comply with a set of naming and design guidelines to further reduce the learning curve for developers.

Figure 3 Services Framework Class Libraries

Some of the key class libraries in the services framework are shown in Figure 3. The framework includes a base set of class libraries that developers would expect in a standard language library, such as collections, input/output, string, and numerical classes. In addition, the base class library provides classes to access operating system services such as graphics, networking, threading, globalization, and cryptography. The services framework also includes a data access class library, as well as classes that development tools can use, such as debugging and profiling services. There isn’t room in this article to discuss all the classes in detail, so I’ll focus on the data access classes since most Web Services need access to data. Of course, you can find additional information about the services framework class libraries in the Microsoft .NET Framework SDK.

Data Access Services

Nearly all Web Services need to query or update persisted data, whether in simple files, relational databases, or any other type of store. To provide data access, the services framework includes the ActiveX® Data Objects+ (ADO+) class library. As the name implies, ADO+ evolves from ADO. ADO+ is designed to provide data access services for scalable Web-based applications and services. ADO+ provides high-performance stream APIs for connected, cursor-style data access, as well as a disconnected data model more suitable for returning data to client applications, as I will explain later. Figure 4 illustrates the ADO+ architecture and shows that any data—regardless of how it is actually stored—can be manipulated as XML or relational data, whichever is most appropriate for the application at a given point in time.

(Con't page 7)

Page 6