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 elimi-

nates issues that arise from incompatibilities between compo-

nent 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 informa-

tion 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 unautho-

rized 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 informa-

tion 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 permis-

sions model as code access security, except that the permis-

sions are based on user identity rather than code identity. Roles

represent categories of users and can be defined at develop-

ment 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 lan-

guage runtime is the services framework. This framework

provides classes that can be called from any modern program-

ming language. All classes comply with a set of naming and

design guidelines to further reduce the learning curve for devel-

opers.

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, network-

ing, 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 applica-

tions 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