The .NET Framework: The Microsoft XML Web Services Engine
Clearly, a considerable amount of infrastructure is required to make building XML Web services transparent to developers and users. The Microsoft .NET Framework provides that infrastructure. The .NET Framework supplies an application model and key enabling technologies to simplify the creation, deployment, and ongoing evolution of secure, reliable, scalable, highly available XML Web services while building on existing developer skills.
View of an automatically generated XML Web service client.
o the .NET Framework, all components can be XML Web services, and XML Web services are just another kind of component. In effect, the .NET Framework combines the best aspects of the Microsoft Component Object Model (COM) with the best aspects of loosely coupled XML Web services-style applications. The result is a powerful, productive Web component system that simplifies program plumbing, deeply integrates security, introduces an Internet-scale deployment system, and greatly improves application reliability and scalability.
The .NET Framework: Three Parts
The goal of the Microsoft .NET Framework is to make it easy to build XML Web services and applications, but it also has a dramatic effect on every kind of application, from simple client applications to many kinds of distributed applications.
The .NET Framework consists of three main parts: the common language runtime, a hierarchical set of unified class libraries, and a component-based version of Microsoft Active Server Pages called Microsoft ASP.NET.
The .NET Framework from the application view.
he common language runtime is built on top of operating system services. It is responsible for actually executing the application—ensuring that all application dependencies are met, managing memory, handling security, language integration, and so on. The runtime supplies many services that help simplify code development and application deployment while improving application reliability.
The developer doesn’t actually interact with the runtime, however. Developers use a unified set of classes built on top of the runtime. These classes can be used from any programming language.
As part of these class libraries, the .NET Framework includes a Web-application programming model called ASP.NET, which provides higher-level components and services targeted specifically at developing XML Web services and applications.
The common language runtime (CLR) is a high-performance execution engine. Code that targets the runtime and whose execution is managed by the runtime is referred to as managed code. Responsibility for tasks such as creating objects, making method calls, and so on is delegated to the common language runtime, which enables the runtime to provide additional services to the executing code.
Despite its name, the CLR also has a role in a component’s development-time experiences.
While the component is running, the runtime provides services—such as memory management (including garbage collection), process management, thread management, and security enforcement—and satisfies 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. In particular, features such as lifetime management, strong type-naming, cross-language exception handling, delegate-based event management, dynamic binding, and reflection dramatically reduce the amount of code a developer must write in order to turn business logic into reusable components.
The common language runtime.
Runtimes are nothing new for languages; virtually every programming language has a runtime. Visual Basic has the most well known runtime (the aptly-named VBRUN), but Microsoft Visual C++® also has one (MSVCRT), as do Microsoft Visual FoxPro®, Microsoft JScript®, SmallTalk, Perl, Python, Haskell, and Java. The critical role of the common language runtime, and what really sets it apart, is its provision of a unified runtime environment across all programming languages.
The key features of the runtime include a common type system (enabling cross-language integration), self-describing components, simplified deployment and versioning, and integrated security services.
Common Type System and Multilanguage Integration
The runtime makes use of a new common type system capable of expressing the semantics of modern programming languages. The common type system defines a standard set of data types and rules for creating new types. The runtime understands how to create and execute these types. Compilers for the .NET Framework use runtime services to define data types, manage objects, and make method calls instead of using tool- or language-specific methods.
The common type system enables deep multilanguage integration. Code written in one language can inherit implementation from classes written in another language; exceptions can be thrown from code written in one language and caught in code written in another; and operations such as debugging and profiling work seamlessly regardless of the languages used to write the code. This means that developers no longer need to create different versions of their reusable libraries for each programming language or compiler, and developers using class libraries are no longer limited to libraries developed for the programming language they are using.
The .NET Framework enables the creation of self-describing components, which simplify development and deployment and improve system reliability. Self-description is accomplished through metadata—information contained in the binary that supplements the executable code, providing details about dependencies, versions, and so on. The metadata is packaged together with the component it describes, resulting in self-describing components.
A key advantage of self-describing components is that you do not need any other files in order to use a component. This contrasts with typical application development today, which requires separate header files for class definitions, separate Interface Description Language (IDL) files, separate type libraries, and separate proxies and stubs. Since the metadata is generated from the source code during the compilation process and stored with the executable code, it is never out of sync with the executable.
Because each application contains a full description of itself, the runtime can dynamically assemble a cache of information about the components installed on a system. If that cache becomes damaged somehow, for example, the runtime can rebuild it without the user even knowing. In addition to solving development challenges, self-description eliminates the dependency on the Windows registry for locating components. A benefit of not relying on the Windows registry is the ability to do no-touch deployment.
This is the ability to simply copy a file to a target machine and have it run, without any registration needed. In addition to the elimination of registry dependencies, the .NET Framework includes other deployment advances that virtually eliminate DLL conflicts—in which shared libraries become out of sync from the applications that are trying to access them. Side-by-side deployment now allows multiple versions of the same named libraries to coexist without conflict. The .NET Framework includes a very strong internal naming system that makes it much harder for two libraries that have the same file name to be mistaken for each other. If a new application overwrites a shared library, an existing application that cannot use the new shared library can actually repair itself. The next time the existing application starts up, it will check its shared files. If it finds that one of its shared files 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.
The .NET Framework takes a major step forward in security by introducing a fine-grained, evidence-based security system. This security system now gives the developer and administrator a wide range of privileges that they can grant (not just “on” or “off”). In addition, it enables those privileges to be applied based on key aspects of the code itself, including the origin of the code and digital signatures.
Because the common language runtime is used to load code, create objects, and make method calls, the runtime can actually perform low-level security checks and enforce security policy as code is loaded and executed.
This design ensures that unauthorized users cannot access resources and code cannot perform unauthorized actions, which improves overall system safety and reliability.