． NET Framework and network services (on)

Network NET Framework and network services (on)
(Author: MSDN February 06, 2001 10:47)

Network Services (Web service) are the basic building blocks of web-based distributed applications that are built on platforms, object templates, and multilanguage.

Network services are built on open Internet standards like HTTP and XML, and thus form the basis of the idea of a programmable network.


Figure 1 Network Service Application Model

This article provides a detailed account of network services and the technologies that support them, which ensure that services are integrated into the application. This article will also describe the new Microsoft.NET framework and its support for generating and using network services.

The most pressing problem in development is the integration of applications: different applications running on different operating systems, often created by different programming language object templates, are obtained and then converted into Easy-to-use Web applications. Network services based on open network standards, such as HTTP and XML, accept this challenge.

But only standard protocols are not enough, and we have to have a way to build, deploy, extend, and maintain these network services, which is exactly the problem that the Microsoft.NET framework addresses.


Figure 2 Microsoft.NET Framework Architecture

The following is an introduction to the components of the network services and microsft.net framework, including the common running language (Common Language Runtime), the service framework, and the program templates for building and integrating network services.

　　 Network Services at a glance
Typically, a Web service is simply a simple application that is released as a service. In other words, it is a resource that can be positioned via a URL to automatically return information to the client that needs it. An important feature of network services is that customers do not need to know how a service is implemented. In this article, I will explain how network and network services combine the best aspects of component-based technology and introduce the basic framework needed to communicate with network services.

Like components, a network service provides a "black box" function that can be used multiple times without being concerned about how the service is implemented. The Network Service also provides an exact definition of the interface known as the contract, which depicts the service provided. Developers can combine remote services, local services, and custom code to integrate into an application. For example, a company can use the following services to build an online store: Microsoft Passport (Passport) services are used to authenticate user identities, Third-party personalized services that enable Web pages to match each user's parameters, credit card processing services, sales tax services, and parcel tracking service for each shipping company, Link internal inventory management procedures and a small amount of custom code to make their stores stand out. The model shown in Figure 1 illustrates how network services should be linked for the generation of distributed network applications.

However, network services are not the same as today's component technologies, and they do not use specific object model protocols that require a clear, homogeneous, basic architecture of the server and client, such as DCOM, RMI, or IIOP. Although implementations that are tightly coupled with specific component technologies are well accepted in a controlled environment, they become impractical in a networked environment. Because the participants in an integrated business process change and technology changes over time, it becomes difficult to ensure a single, unified architecture among all participants. The network service takes another approach, using ubiquitous network protocols and data formats for communication, such as HTTP and XML. Network services are supported by any system that supports these network standards.

Furthermore, the Network service contract describes the services provided in the form of a term message, which is generated and accepted by the Network service, and does not describe how the service is implemented. By focusing on the message, the Network Service template becomes fully transparent to the language, platform, and object templates. In this way, the network service can be realized by using any set of programming languages, object models and complete features of the platform. Network services can be used by any application on any platform. As long as the contracts used to interpret service capacity, message sequences, and desired protocols are identified, the implemented network services and Network service users can be different from each other without affecting the application on the other end of the session.

Network Service templates have low requirements for minimal architecture to ensure that network services are implemented and accessed on platforms that use any technology and programming language. The solution to the interoperability of network services can only rely on network standards. However, to make it easier for applications to use network services, it is not enough to simply access network services through standard network protocols. Network services are easier to use when network services and network service consumers rely on standard methods such as XML to represent data and commands, represent network service contracts, and calculate the capacity provided by network services.

XML is a smart choice for defining a standard, extensible language for providing commands and typical data. Although you can define rules that use other techniques, such as encoding as a query string, to represent commands and typical data, XML is specifically designed to describe the standard meta language of the data. Simple Object Access Protocol (SOAP) is an industrial standard that uses XML to represent data and commands in an extensible way. Network services can choose to use SOAP to determine the format of the message.

XML is a common technology of network service contract. The Service Contract language (SCL) is the XML syntax for recording Network service contracts. Because the SCL is xml-based, it is easier for developers and development tools to generate and interpret contracts.


Figure 3 Services Framework class Library

The Disco specification describes a standard way for a service provider to publish a network service contract and the corresponding mechanism, which will enable developers or development tools to find the contract literature.

Standards like soap, SCL, and disco help developers because they don't need to understand and implement the way each network service is accessed. Better, fully tested, high-performance architectures that support these standards will be provided by the development platform, which can greatly simplify the entire development process.

　　 Microsoft.NET Framework
The Microsoft.NET framework is designed to make it easier for you to set up network applications and network services. Figure 2 shows the architecture of the Microsoft.NET framework. A service built on the top of the operating system is the common Language Runtime that manages the requirements of running code that can be written in any modern programming language. Runtime offers a number of services that help simplify code development and application development while also improving application reliability. The. NET framework includes a set of class libraries that developers can use for any programming language. On top of that are a number of application templates that provide advanced components and services for developing network sites and network services, which are described in layers below.

　　 Common Language Runtime
The Run language (Runtime) can invoke and run code written by any programming language. The code that runs as the target is called the Controlled (Managed) code, and the controlled code simply means the cooperative contract that has been defined within the internal executable code and its own code. Tasks such as generating objects, invoking methods, and so on are delegated to the running language, which allows the running language to add additional services to executable code.

The running language features cross language integration, self-describing components, simple compounding, versioning, and integrated security services.

The runtime language uses a common type system that expresses the semantics of most modern programming languages, which defines a set of standard types and rules for generating new standards. The running language knows how to build and execute these types. Compilers and interpreters use the Run language service to define types, manage objects, and make method calls.

The main design of the type system is to enable multiple languages to be integrated deeply. Code written in one language can inherit a class written in another language, exceptions written in one language can be caught by code written in another language, such as debugging, in a completely closed way, regardless of the language in which the code is written. This means that developers who write reusable class libraries no longer need to generate a version for each programming language or compiler, and developers using class libraries will no longer be limited by the programming language development library they use.

The self-describing component simplifies development and compounding, and improves the reliability of the system. Many of the services provided by the running language are driven by metadata and information that is used to supplement executable code. Because all the information is stored together, only executable code is called a self-describing component.

One of the main advantages of self-describing components is that they do not require additional files. The definition of a class does not require a separate header file, and the definition of the class by examining the metadata can be obtained from the component itself. Accessing components across a language or process boundary does not require their own IDL files, type files, or proxy/stubs; the required information already exists in the metadata. Most important, because metadata is generated by source code during compilation and stored with executable code, it is always synchronized with the executable part.

In addition to improving the configuration of individual components, microsft. NET Framework defines an application configuration template to address the complex process of customizing application installation and DLL versioning (often referred to as "DLL Hell"), which provides services that support this template.

The Microsft.net framework introduces the concept of composition. A composition is a set of resources and types, and includes metadata about those resources and types, which is configured as a unit. Metadata is called a list of combinations, and it contains information that can be seen in groups such as types and resource tables, and this list also includes information about dependencies such as the version number when the composition is established. A developer can specify a version policy to indicate whether the running language loads the most recent version of the assembly that is already installed on the system, to mount a specified version, or a version that is used at compile time.

Multiple copies of a software component can exist on the same operating system, however, usually only one copy can be registered, transferred into memory, and executed by the operating system. For systems, the strategy for locating and paging into memory is global. The. NET Framework Common Language Runtime adds the necessary architecture to support each application policy that manages the positioning and transfer of components, which is often referred to as a parallel configuration.

A combination can be private to an application or shared by multiple applications. Multiple versions of a combination can be configured on the same machine at the same time. The configuration information for the application defines where to look for the composition, so that runtime can load two different applications running concurrently into different versions of the same assembly, eliminating problems caused by the incompatibility of the component version and improving the overall stability of the system. If necessary, the administrator can add configuration information for the Assembly at the time of configuration.

Because the assembly is self-describing, it does not need to be registered on the system. The configuration of the application is simple enough to simply copy the files to the directory (a little more complex if you have to install the components that are not organized in order for the application to run). The configuration information is saved in an XML file that can be edited by any text editor.

Finally, the running language also provides a complete, pervasive security service to ensure that unauthorized users cannot access resources on the machine and that the code does not perform unauthorized actions. This improves the security and reliability of the system as a whole. Because the running language is used to load code, generate objects, and execute method calls, the running language can perform security checks when the managed code is loaded into memory and enforced, thereby hardening the policy.

The Microsft.net framework not only provides code access security mechanisms, but also provides role-based security. With code access security, developers can specify the permissions necessary for the application to complete work. For example, a program might need the power to write files or access environment variables. This type of information is stored at the configuration level along with information about code flags. When code is loaded into memory and the method call is executed, the running language verifies that the permissions required by the code are given. If not, a security conflict information is logged. The policy of giving permission, called the Trust policy, is established by the system administrator and is based on the evidence on the code. For example: Who publishes the code, where it is obtained, and the code flags found in the assembly and the permissions it requires. Developers can specify their specific permissions to prevent others from maliciously using their code. If the required permissions depend on information that is not known until the runtime, the programmatic security check is written.

In addition to code access security, the running language also supports role-based security. role-based security establishes the same permissions templates as code access security, except that these permissions are based on the user's identity rather than on the code's flag. Roles indicate the class to which the user belongs and can be defined at the development and configuration stages. Policies that give permissions are assigned to each predefined role. At run time, the identity of the user is determined and the code will run on behalf of that identity. The running language determines which role the user is a member of, and then gives permissions based on that role.

Before viewing the programmable template for the Microsft.net framework, look at the services it provides.

　　 Service Framework
As we can see from Figure 2, the Service Framework (common) is on top of the Language runtime, which provides classes that are invoked by any modern programming language. All classes follow a set of naming and design guidelines, which greatly reduces the difficulty of the developer learning process.

Figure 3 shows some of the main class libraries in the service framework. The framework includes a set of base class libraries that developers want to exist in the standard language library, such as collections, input/output, strings, and data classes. In addition, the base class library provides classes that access operating system services such as drawings, networks, threads, globalization, and encryption. The service framework also includes data access class libraries and development tools such as debugging and profiling services. (translation: Jinzhili)