Introduction to Web Services IN ASP.NET

Web Services solve a basic, but pervasive problem experienced by many of us with today's Internet. Although literally billions of pages of useful data and information are served up by the Web, it is typically difficult to extract, examine, and use that data programmatically.

Much of this difficulty arises from the fact that the Web (at least as it exists today) is designed for human consumption. Consequently, data is presented in a form that's easy for a human to read but relatively difficult and error prone for applications to read and process reliably.

Web services are all about delivering distributed applications via programmable components that are accessible over the Web. As an example, many e-commerce sites need to calculate shipping charges based on a variety of shipping options. Typically, such a site might maintain a set of database tables that describe the shipping options and charges for each shipping company.

Obviously, this can become a time-consuming process, because the data is likely to change often, and someone must repeatedly update the tables.

A more automated approach might incorporate a process called "screen scraping." Suppose that one of the shipping companies maintains a Web site that conveniently lists the various shipping options and associated charges. By utilizing screen scraping (essentially a process of analyzing the data in a page for certain patterns in order to extract the data you are interested in processing), a program can examine the Web page and extract the shipping information from that page.


Suddenly and unexpectedly, your screen scraper may no longer be able to locate the data you need. Now, imagine this same e-commerce site programmatically calling a Web service provided by the shipping company on its Web site that automatically calculates shipping costs based on the shipping method and package weight that you specify in your request and returns the resulting charge to you in real time.

Potentially valuable applications of Web services ARE

Services that are either too difficult or too expensive to implement yourself.

For example, credit card validation, financial account management, stock quotes, and so on.

Services that provide commonly needed functionality for other services. For example, user authentication, usage billing, usage auditing, and so on.

Services that aggregate distributed, discrete services into an orchestrated whole. A good example of this type of service would be travel booking.

Services that integrate your business systems with your partners (or other business systems within your own organization).

No wonder so much excitement surrounds the promise that Web services offer to programmers, systems integrators, and IT professionals.

What is a Web service?

A Web service is a programmable URL. Stated another way, a Web service is an application component that is remotely callable using standard Internet protocols such as HTTP and XML. Thus, any system that supports these basic, standard protocols is capable of supporting Web services.

The ability to package application code into reusable components that is callable across process and machine boundaries is not a new concept. Today, technologies are available such as the Component Object Model (COM), the Common Object Request Broker Architecture (CORBA), Internet Inter-ORB Protocol (IIOP), and Remote Method Invocation (RMI), to name a few. A key limitation of these technologies is that they are not easily interoperable amongst the tremendous number of heterogeneous systems that comprise the Internet.

This is due, in part, to dependencies on particular operating systems, programming languages, or object-model-specific protocols. Consequently, this limits their effectiveness as a standard method for programming the Web. Clearly, what is needed for Web services to succeed on the Internet is a platform that does not depend on a specific operating system, object model, or programming language.

What sets Web services apart from these prior-generation component and middleware technologies is the fact that they are built upon widely accepted Internet standards that can interoperate seamlessly in the diversity of the Web. Web services use a text-based messaging model to communicate, allowing them to operate effectively on these many different platforms.

If you are familiar with creating and consuming COM components for distributed applications, you will find creating and consuming Web services a natural evolution of what you already know.

Foundational elements of Web services

Now that you have an idea of what Web services are and how they can be used, let's examine the key technologies that you will encounter when working with Web services.

Microsoft provides an excellent platform for building and consuming Web services with the .NET Framework, which virtually eliminates the need to learn about the "plumbing" that is a part of building and consuming Web services. If things worked right all of the time and never had the opportunity to fail, there would be no need to even discuss this plumbing. But, of course, things don't always work right and, when they don't, it is both useful and practical to have a basic understanding of the working principals of the foundation upon which Web services are built.

The goal is to empower you with enough knowledge that you can effectively troubleshoot any problems you might encounter when working with Web services.The key to the broad-reach capabilities of Web services on the Internet is a foundation built on Internet standards that does not rely on any platform-specific technology.

This foundation supplies standards-based services that provide the following capabilities to Web services:
  1. A standard, portable method for describing data
  2. A standard, extensible message format for communicating requests and responses
  3. A standard, extensible method for describing the capabilities of Web services
  4. A method to discover what Web services are available at any particular site
  5. A method to discover what sites provide Web services

Representing Data

Web services enable consumers to programmatically request and obtain structured data.

To promote the ability of Web services to communicate their data unambiguously, efficiently, and effectively, a common, portable, and standard method for describing data must be used.The simple (and logical) answer is XML.

What is XML?

XML provides a standards-based method for describing data (also known as metadata).

XML has the ability to describe data using a simple grammar that is highly interoperable among the many heterogeneous systems that are connected to the Internet. Using the basic elements of the XML language, you can describe simple as well as complex data types and relationships.

XML has several key strengths that have helped it to become the de facto method for describing data (especially over HTML and other binary formats):

XML is a text-based language, which makes it easily readable and more portable than binary data formats.

XML gives you the ability to define your own tags to describe data and its relationships to other data (hence, the word extensible in its name).

XML strictly enforces its language syntax, unlike HTML.
Parsers are widely available to accurately parse and validate XML structures that you define, which means you don't have to do it yourself!

Of course, XML is not without it's weaknesses. Among these is the fact that XML can be more "wordy" than an equivalent binary format. In addition, data interoperability can be difficult to achieve due to differences in naming conventions from one application to another.

XML syntax

XML is a markup language that, at first glance, looks very much like HTML. In fact, XML and HTML are both derived from the Standard Generalized Markup Language (SGML).

XML (like HTML) uses a set of human-readable tags and declarations to create a document. The major difference is in the meaning implied by these tags and declarations. Whereas HTML is concerned with describing how to format information on a page, XML is concerned with describing data and its relationship to other data.

XML uses tags enclosed in <> angle brackets to define elements that form element structures and hierarchies within an XML document.

XML document structure

An XML document consists of a prolog, document elements, and optional attributes that model a logically related set of data. An invoice is one example of such an information model. The prolog contains information that applies to the document as a whole and appears at the top of the document before the first document tag. The prolog usually contains information about the character encoding and document structure as well as other possible information. XML parsers use the prolog to correctly interpret the contents of an XML document.

XML namespaces

When developing XML documents, it is common to refer to element and attribute names that share a common context as a vocabulary. Thus, we might say that our previous sample XML document belongs to a weather vocabulary. Given that an XML document consists of a vocabulary that you define, the possibility arises that an element or attribute in that vocabulary may have a name that is identical to an element or attribute used by someone else in a different vocabulary.

XML namespaces solve this ambiguity problem by associating an explicit namespace (or vocabulary) with elements and attributes in an XML document. Thus, a namespace is essentially a set of names in which all the element and attribute names can be guaranteed to be unique.

Default namespace declaration

Default declaration defines a namespace whose scope includes all elements contained within the element where the declaration was specified. Default declaration is typically used when a document contains elements from a single namespace. Our weather Example used a default namespace declaration because all the elements shared the same context or vocabulary (in other words, none of the elements refers to elements from other namespaces).

XML schemas

In our coverage of XML thus far, it was mentioned that the XML parser uses strict rules to ensure that the XML document is well formed. Recall that a well-formed XML document is one that follows the rules for properly closing tags, nesting tags, enclosing attributes in quotes, and using a unique first element.

However, this does not address the issue of validating that an XML document contains the proper assortment of elements and in valid combinations. What is needed is a language that will allow a generic XML parser to determine that the document conforms to these additional, user-defined rules.

The XSD language defines rules for describing the valid combinations and relationships of elements, attributes, and data types that can appear in an XML document.

RELATED POST

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


ASP.NET Configuration System

When you install a new application, you may be required to configure it. For example,you may need to provide information about the amount of memory to be used by the application. In addition, you may need to specify application-specific information, such as the path for the data source. A configuration system provides all this information for an application, which may be used at the time of or after the deployment of the application.

A Web application should provide a flexible configuration system that allows configuration settings to be easily applied to the application. It should also facilitate easy customization of configuration settings after the deployment of the application so that changes in the configuration settings can be applied to the application without having to recompile the entire code. In addition, the configuration system should provide a rich set of configuration settings to enable different types of Web clients to work with the applications.

The configuration system provided in ASP.NET meets all of these requirements. It provides a flexible configuration system, as well as a rich set of initial configuration settings. A thorough understanding of the configuration system helps you to easily specify the settings for the target computer. You can also easily change the settings after the application is deployed.

In ASP.NET, the configuration file Web.config stores the information about browser capabilities, compilation, custom error messages, security, and globalization. The Web.config file stores the configuration information in an XML format; therefore, it can be easily read and modified by developers by using any standard text editor. Developers can also use scripting languages such as Perl and VBScript to navigate, interpret, and modify the configuration settings specified in the file.


ASP.NET provides a default configuration file for the entire Web server. This file provides the default settings for an ASP.NET application. This file, called Machine.config, is located in the %windir%\Microsoft.NET\Framework\version\CONFIG folder and is available at the machine level. In addition to this machine-level file, you can create your own Web.config file that specifies the settings for a particular application.

When a user makes a request for a resource, ASP.NET determines the configuration settings for the resources by referring to the settings in the Web.config file located in the path of the resource. In the absence of this file, ASP.NET refers to the settings in the Machine.config file.

Deploying Classes and Assemblies

A Windows application is composed of different types of files, such as EXEs and DLLs. When you deploy a new application, it might result in the installation of all the files that comprise the application. However, this may cause a number of problems, especially in case of applications that use COM-based components. COM components need to be registered so that the system can locate them. This requires several Registry settings, in the absence of which the components do not work. In addition, if an application results in installing a newer version of a component, which is shared by a number of applications on a computer, the existing applications might not work as expected.

To overcome the problems of COM-based components and to simplify the process of deploying classes and components, .NET introduces the concept of assemblies. An assembly is a single logical unit of functionality. It is the fundamental unit of class deployment.

An assembly contains an assembly manifest, which contains data about the dependencies of the files that are included in the assembly, their version requirements, security information, and all other information required to resolve references to resources and classes in the assembly.

After you have created an assembly, you can easily deploy it by using Windows Installer (as an MSI file), by using Internet Explorer (as CAB files), or simply by copying the assembly to the target computer. An assembly can be deployed into the local assembly cache or the global assembly cache. The local assembly cache is specific to an application. On the other hand, when you install an assembly into a global assembly cache, it can be accessed by all applications on a computer.

Usually, assemblies are deployed into the local assembly cache of the application. This ensures that the assembly can be accessed only by the code in the application. It also facilitates side-by-side versions of an application to run simultaneously, because the classes of the assemblies are private to a particular application version instance. You can deploy an assembly into the local assembly cache by copying the assembly files in the directory, which is marked as the assembly cache location for an application.

ASP.NET applications are configured to use the bin directory specific to an application as the default local assembly cache. Therefore, you can copy the assembly files to the bin directory of the application.

You can install an assembly into the global assembly cache, using Windows Installer, when you want multiple applications to share the code in the assembly. Windows Installer 2.0 provides the reference-counting feature for assemblies that are shared by multiple applications.

RELATED POST

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


Deploying ASP.NET Applications

After a Web application is developed, it needs to be deployed to make it available as a Web site. A Web application may be made up of a number of files and components. These components may be developed by the application developer or by a third party. Therefore, while deploying a Web application, you must determine the files to be included in the deployment. In addition, you must determine the method to be used for deploying an application.

Deployment is the process of packaging all files that make up an application and distributing them for the purpose of installation on other computers. Deploying an ASP.NET application can be as easy as copying the application files to the machine on which the application needs to be deployed. When you deploy an application by copying files, no Registry entries are made. To deploy more complex applications, which may comprise various components, you may create deployment projects in Visual Studio .NET.

A deployment project enables you to specify the files to be included in the deployment, the method by which the application files will be deployed, and the location where the application is to be deployed. In this section, you will look at the different types of deployment projects, the process of creating a deployment project, adding files to the deployment project, and building the deployment project.

Choosing the type of deployment projects

Visual Studio .NET provides different types of deployment projects. The choice of a particular type of deployment project depends upon the application or the component that you want to deploy and the mode of deployment. For example, you may want to deploy an application in the form of a collection of cabinet (CAB) files for downloading the application.

The different types of deployment projects provided in Vi sual Studio .NET are as follows:

Merge module project: Creates a single package that contains all files, resources, Registry entries, and the setup logic necessary for deploying the package. A merge module is similar to a dynamic link library (DLL), which allows multiple applications to share code. The only difference in this case is that a merge module allows sharing of the setup code. A merge module project file has the extension .msm. You cannot use a merge module file by itself. You must merge the resulting .msm file with another deployment project, which creates a Windows Installer (MSI) file.

You can use a merge module project when you want to deploy a component that will be shared by multiple applications, because a merge module project identifies all the dependencies for a component and ensures that the correct versions of the components are installed. Thus, problems relating to versioning can be avoided with merge module projects. When a new version of a component needs to be deployed, you simply create a new merge module project that contains the dependencies for the new version of the component.

Setup project: Enables you to create a Windows Installer (MSI) file for deploying an application. The resulting MSI file contains the application, dependencies, information about the Registry entries to be made, and installation instructions. A setup project can be used for deploying standard Windows-based applications. When you execute the resulting MSI file, all files related to the application are copied to the Program Files directory on the target computer.

While selecting between a merge module project and a setup project, you must consider the target audience. If the application is intended for use by an end user, you should package all the files for the application in an MSI file. On the other hand, DLLs, controls, and resources that are intended for use by developers should be packaged in a merge module, which can then be packaged by the developer in an MSI file for distribution to the end user.

Web setup project: Is similar to a setup project. This type of project also results in the creation of an MSI file, which can be used for deploying an application. When you execute the MSI file, all files that make up the application are copied to the virtual root directory on the Web server.

This type of project should be used for installing a Web application on a Web server.

Cab project: Enables you to generate CAB files of a specific size. These CAB files can be used to download components to a Web browser. You can create a cabinet project if you want your component to run on the client instead of the Web server.

In addition to these types of projects, Visual Studio .NET also provides the Setup Wizard, which creates a basic setup project. It guides you through the steps of creating a deployment project. During each step, the wizard collects information, such as the files to be included in the deployment project.

User Interface Editor

When you create a deployment project, it automatically creates some dialog boxes that are displayed during the installation of the application on the target computer. The User Interface Editor displays the dialog box names and enables you to specify the properties of the dialog boxes, such as the message to be displayed in a dialog box and the name of the dialog box. In addition, the User Interface Editor enables you to add your own dialog boxes.

The User Interface Editor is divided into two sections, Install and Administrative Install. The Install section contains the dialog boxes that are displayed to the users when they start installation. The Administrative Install section contains the dialog boxes that are displayed when a network administrator moves the installer to a network location, to make it available for installation over a network.

Each section has some predefined dialog boxes, which are categorized as follows:

Start dialog boxes: Displayed to the user before the actual installation process begins. Examples of dialog boxes in this category are the Welcome screen, the dialog box that accepts customer information such as the username and company name, and the dialog box that enables a user to specify the directory in which the files are to be copied.

Progress dialog boxes: Used as a means of providing visual feedback to the user about the progress of the installation process. It typically depicts the progress in terms of the percentage of completion of the process.

End dialog boxes: Used to inform the user about the success or failure of the installation process. They also include the dialog boxes that enable you to launch the newly installed application or to restart the computer.

RELATED POST

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


Localizing ASP.NET Applications

ASP.NET enables you to create applications that are international-ready. These applications can be used in any locale without being modified and recompiled. The process of creating international applications is called internationalization.

When you create international applications, you should consider the following factors:

The language to be used to design the user interface

The locale-specific settings, such as currency formats, date/time formats, and number formats Internationalization is further divided into three subparts: globalization, localizability, and localization. The process of designing and implementing applications that include generic coding and design considerations so that they can adapt themselves according to the locale they are used in is called globalization.

Localizability is an intermediate phase between globalization and localization.

Localizability is a quality-assurance phase, which verifies that a globalized application is ready for localization by separating the resources (that require localization) from the rest of the application. Proper localizability results in a source code that you will not need to modify during localization.

After globalization, the process of working with resources, such as string and image representations for specific locales, is called localization. Localization consists primarily of translating the user interface.

Conceptually, a globalized application can be divided into two parts, a data block, and a code block. The data block part consists of all user interface resources and is localedependent.

On the other hand, the code block part consists of the application code that can work with the data blocks irrespective of locales. Thus, localization involves working with the data blocks for specific locales.

Data can be represented in a number of ways identified as character sets. For localization, you should have a basic understanding of the different character sets.

Character sets

A character set is a set of characters grouped together from different languages. Each character that you input from your keyboard has a code associated with it called a character code. A character code is a unique number that is stored by a computer when you input the character. Thus, a character code is an internal representation of a character in a specific language. Internal tables called code pages, which can include numbers, punctuation marks, and other glyphs, are maintained that are used by operating systems to map keys on keyboards to the characters to be displayed. Some of the different character sets are described as follows:

American National Standards Institute (ANSI): Consists of 256 characters and punctuation codes. Each character is represented as a single byte. This set is sufficient for English applications. However, for most other languages, the ANSI character set is not adequate.
§ Double Byte Character Set (DBCS): A combination of the standard ASCII character set and alphabets from East Asian languages. An ASCII character is represented as a single byte whereas East Asian characters are represented as 2 bytes.

Unicode: Includes characters from almost all major languages that are spoken today. Therefore, multiple code pages are not required to map characters from different languages. Unicode thus provides a single universal code page that includes characters from almost all languages.

Unicode enables you to easily transfer data between different locales. In Unicode, each character is represented as 2 bytes. However, two basic problems are associated with Unicode. First, Unicode increases the file size because it has a large character set. Second, most systems do not support Unicode, which results in problems when Unicode characters are identified on a network.

To address these problems, Unicode Transformation Formats (UTFs) can be used. UTFs use a technique wherein the Unicode characters are encoded as byte values so that they can be understood by systems that do not support Unicode. The most commonly used UTF is UTF-8, which encodes Unicode characters to single-byte characters.

Setting Culture and Region

In addition to the configuration settings, you can use the classes provided by the .NET Framework to create international applications. These classes are contained in the System.Globalization namespace. In addition to these classes, you can use the Thread class of the System.Threading namespace to control the locale-specific settings for each executing instance of an application. The Thread class represents the threads that execute within the runtime.

System.Globalization namespace

The System.Globalization namespace contains classes that enable your applications to determine the locale at run time. This gives you the flexibility of creating applications that can automatically adapt themselves to the locale in which they run. The classes of the System.Globalization namespace define culture-related information, such as the language, the country/region, the calendars in use, the format patterns for dates, currency, and numbers, and the sort order for strings. The following sections describe the CultureInfo and RegionInfo classes of this namespace.

When you make an application, it is a part of an assembly called the main assembly. If any change is made to this main assembly, you need to recompile the application. Because you might need to add the resources to provide support for more cultures, it is advisable to keep only the default set of resources in the main assembly. The other sets of resources can be kept in separate assemblies called satellite assemblies, which contain only resources. Therefore, changes made to these assemblies do not require you to recompile the application.

System.Resources namespace

The .NET Framework provides a class library that uses these resource files to retrieve resources for different languages at run time. The classes that allow developers to create, store, and manage various culture-specific resources used in an application are included in the System.Resources namespace. Some of the classes of this namespace are described as follows:

ResourceManager: Represents a set of all the resources to be used in an application at the time of execution. This class provides many constructors that you can use to create its objects.

The choice of the constructors depends on the need and the scenario in which you want to use resources. For example, when you need to retrieve resources from an assembly, you can use the constructor that takes three parameters: baseName, Assembly, and Type.

RELATED POST

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


ASP.NET Security part two

In addition to the IIS permission levels, NTFS permissions can also be used to secure the files and directories on a Web server.

The following are the different access permissions that can be assigned to users and groups for the files and directories on the server:

Full Control: Allows users to have complete control on files and/or directories.

Modify: Allows users to modify the contents of files and/or directories. However, users will not be able to delete files and/or directories.

Read & Execute: Allows users to read the contents of the existing files and/or directories and execute any application stored in that folder. However, users will not be able to modify the contents of the files and/or directories.

List Folder Contents: Allows users to view the contents of the folder. However, users will neither be able to read the contents of any file in the folder nor modify any contents.

Write: Allows users to make changes to files and/or directories.

No Access: Does not allow any access to files and/or directories. Authentication in Web applications Various ways exist to authenticate user access to Web applications. In intranet applications, it is possible to use Integrated Windows Authentication to authenticate user access and implement access control. But, in most of the Internet applications, it is not possible to use Windows authentication as it puts various restrictions. The following are two of these restrictions:

Number of user accounts: Although Windows Active Directory can scale up to a large number of user accounts, managing all the user accounts for Internet applications (that involve millions of user accounts) can be a big management challenge, if not a nightmare. Therefore, most Web administrators and developers prefer an authentication mechanism that is based on databases, such as SQL databases.

Licensing issues: If millions of users were to be authenticated against an Active Directory database, the Web site would need to procure user licenses for all the users. Thus, to say the least, it can prove to be an expensive proposition.

In classic ASP, authentication issues were addressed by security implementations that relied on cookies or client IP. This approach, typically, meant writing a lot of code and proved to be an unnecessary overhead for developers. The approach is very different from implementing security in Windows applications.

In Windows, applications are developed in a way that maximizes the leverage on the services provided by the operating system. With ASP.NET, however, the days of writing tedious user validation code are gone. Developers can rely on the underlying Microsoft .NET Framework to provide security. They just need to focus on solving business problems and implementing the functionality in the Web site. Let us now explore the various authentication models that are supported by ASP.NET.

ASP.NET authentication options

The security section of the Web.config file contains the information related to the level and type of authentication services that would be provided for a Web application. The Web.config file is an XML file and is located in the root directory of a Web application.Various configuration options for an ASP.NET Web application can be controlled and configured from this XML file.

The system.web section of the Web.config file is used to control the various aspects of security that are provided to the Web application.

An ASP.NET Web application can be provided with one of the following types of security:

Windows: The application is secured by using Integrated Windows Authentication. In this method, access to a Web application is allowed only to those users who are able to verify their Windows credentials.

Credentials can be verified against the Windows authentication database (SAM) or against Active Directory.

Passport: The application is secured by using Microsoft Passport authentication. Passport is a single-sign-on technology developed by Microsoft for use on the Web.

Forms: The application is secured by using a custom authentication model with cookie support.

None: The application is not secured; access to the application does not require authentication.

Forms-based Authentication

ASP.NET includes a built-in feature, called forms-based authentication, which can be used to implement customized logic for authenticating users and authentication handlers without having to worry about session management using cookies. In forms-based authentication, when a user is determined to be unauthenticated, the user is automatically redirected to the login page. Some of the benefits of the forms-based authentication are the following:

Developers can configure forms-based authentication for various parts of the Web site differently, because the Web.config file is a hierarchical XML document.

Administrators and developers can change the authentication scheme quickly and easily in the Web.config file.

Administration is centralized because all the authentication entries are in one place — the Web.config file. You can enable forms-based authentication for a Web application by setting the
Authentication mode property to "Forms" in the Web.config file.

RELATED POST

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


ASP.NET Security

The reasons to secure a Web site are well known and thus do not require a detailed discussion. A few of the reasons for securing a Web site include transfer of sensitive data over the Internet, exchange of sensitive data between Web applications, and risks of hack attacks.

Security is a critical issue for both Web application developers and administrators alike. It is undoubtedly one of the most confusing areas, and hence requires careful planning and designing. Web site developers and administrators must have a clear understanding of the various options, such as authentication, for securing their sites.

Security, in the context of an ASP.NET application, involves three fundamental operations. These operations are carried out during the lifetime of each secure ASP.NET Web application and are described as follows:

Authentication:

This is the process of validating the identity of a user, to allow or deny a request. Typically, authentication is a process of accepting the username and password from a user, and validating the username/password combination in a security database.

In addition to this typical case, the authentication process can be more sophisticated. After the identity is verified and validated, the user is considered to be legitimate, and the resource request is fulfilled. Future requests from the same user, ideally, are not subject to the authentication process, until the user logs out of the Web application.

Authorization:

This is the process of ensuring that users with valid identity are allowed to access only those resources for which they have been assigned access rights. In other words, authorization is a check that is performed at every stage of the request-processing cycle on the Web server. This check ensures that access is given only to the allowed resources.

Impersonation: This process enables an application to assume the identity of the caller, and in turn make requests to the other resources. Access to resources will be granted or denied based on the identity that is being impersonated. If the identity being impersonated has permissions to a resource, the application that impersonates the identity will also have the access permission to that resource.

Before delving deeper into the security system that is available with ASP.NET, let us review the security system that is made available to the Web sites by the underlying Web server. For the ASP.NET applications, the underlying Web server is Microsoft Internet Information Services (IIS). Therefore, every ASP.NET Web application can continue to leverage the security options provided by the IIS server. Let us now look at the security provided by the IIS server.

IIS security

Securing a Web application involves different aspects. The best place to start securing a Web application is by looking at the security methods provided by the Web server that hosts the Web application. The IIS server has built-in support for authentication and authorization of user requests.

Authentication

The IIS server has built-in support for authenticating clients who request the Web content stored in an IIS Web site. Three different types of authentication can be implemented by using the IIS server:

Anonymous Authentication: Allows all users to browse the Web site without prompting for a username and password. The access to the Web site resources is impersonated by the IIS server by using the IUSR_machinename account.

Basic Authentication: Requires the users to enter a username/password combination for accessing the Web site. The major downside to this method of authentication is that the password is sent over the network in an unencrypted form, making it possible for unauthorized users to snoop the network packets and retrieve the password information easily.

Integrated Windows Authentication: Requires the users to be valid Windows users in addition to fulfilling the basic authentication. In this mode, IIS will verify the username and password with a Windows Domain Controller. The access to the Web site is allowed only if the domain controller validates the username and password.

However, this authentication uses a different way of transmitting the authentication credentials. This authentication sends a hash value over the network rather than the password. The hash value cannot be decrypted and hence the original text cannot be deciphered.

Authorization

The IIS server can be configured to control the resources that can be accessed by users. You can control the access permissions on an IIS Web site by marking the allowed operations on the Web site. The different permission levels include the following:

Read: Allows users to retrieve and read the content stored in the virtual directory. This permission is assigned to most virtual directories.

Write: Allows users to retrieve and modify the content stored in the virtual directory. If a Web site is open to receiving content over the HTTP protocol, the virtual directory used to store the received files must have the write permission. A typical example of this would be a virtual directory that stores the files that are uploaded as attachments to e-mail messages.

Script source access: Allows users to view the source code of any server-side program.

Directory browsing: Allows users to view the contents of the entire virtual directory. This is similar to viewing an FTP folder.

Log visits: Keeps track of the number of users who visit the site, and records information about various details, such as the IP address of the client and the resources that are requested for.

Index: Uses Microsoft Index Server to index the virtual directory. The contents of the directory can be retrieved in a search result using the Index Server.

RELATED POST

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


Wireless Applications with ASP.NET

The Internet is constantly evolving, and has moved from the desktop to include the wireless world. As an extension of ASP.NET, Microsoft has released the Mobile Internet Toolkit (MIT). MIT is an intelligent solution to produce mobile applications that detect the browsing device and return the appropriately formatted content. Thus, MIT provides a single application that adapts to Web-enabled cell phones, pagers, and personal digital assistants (PDAs).

Although the technology exists to extend your desktop applications to a mobile environment, you have to be aware of some of the limitations of mobile devices:

Smaller screen size: A typical cell phone can only display 15 to 20 characters across and between 4 to 6 lines of text.

Power: Most mobile devices have limited battery life, memory, and processing power, and do not carry the same capabilities as your desktop PC.

Bandwidth: By nature, wireless applications are more costly to run and, technically, cannot provide the bandwidth found on a wired network.

Luckily, MIT will handle most of the screen size limitations that you will run into when developing wireless applications. MIT will dynamically detect the device being used and provide the appropriate output.

In spite of the difficulties previously mentioned, MIT makes it easy to deploy wireless applications, and it does so intelligently.

Over 80 percent of Internet-enabled, wireless devices consist of cell phones and PDAs. Cell phones have a typical display screen of 15 to 20 characters and between 4 to 6 lines of text. PDAs are a little bit larger, and may be as wide as 20 to 25 characters, and include up to 6 to 10 lines of text.

Testing your applications on wireless devices could get to be expensive over the process of building your software. Therefore, to test your applications, this chapter explains how to use two different emulators: a cell phone emulator by Openwave, and the Pocket PC emulator available from Microsoft.

Openwave is one of the world's largest providers of mobile Internet software.

Because WAP is the protocol used to transfer our data, we need another protocol to format our data. That's where WML, or Wireless Markup Language, comes into play. WML is used to format pages that are delivered using WAP. WML has its roots in XML, and is in fact still XML-compliant.

Building Your First Mobile Application

Now that you understand the foundation of mobile applications, you will build your first application. Your sample application, about bicycling, will demonstrate various techniques of displaying data, and receiving input data from the user.

Static pages

Let's take our layout and convert it to an application. However, before we start coding, we need to make sure our Internet Information Server (IIS) is set up to properly serve WML pages. To configure IIS 5.0 on Windows 2000 to serve up static WML pages, follow these steps:

1. Open Control Panel, then Administrative Tools, then IIS administrator.

2. Right -click your Web site instance and select Properties.

3. Click the HTTP Headers tab.

4. Under Mime Types, click File Types.

5. Under Registered File Types, check to see if .wml is listed.

6. If .wml is not listed, click New Type to show the File Type dialog box.

7. Enter ".wml" (without quotes) in the Associated Extension box.

8. Enter "text/vnd.wap.wml" (without quotes) in the Content Type (MIME) box.

Building your first MIT page

MIT is considered an intelligent solution. It will detect what type of device is requesting data and will return the appropriately formatted data. For example, if a browser is requesting your mobile page, the respective HTML will be returned. If a cell phone is requesting your page, the appropriate WML will be returned. This happens because all mobile pages must inherit from System.Web.UI.MobileControls.MobilePage.

The object MobilePage is the outermost layer of all the containers in a mobile Web application.

Mobile Lists

Now that you've been introduced to some basic mobile controls, you will see how to use mobile lists. Mobile lists are one of the most powerful, and most popular mobile controls. They provide an easy way for the user to input data through their mobile device.

Simple lists

Let's take our example one step further and explore some other controls. This control is much more flexible than the standard tag, because it provides special commands and formatting features.

Pagination

Often times, we want to send more text to the client or device than what can fit on a single screen. After all, most cell phones are only around 15 characters wide and have 4 to 6 lines for text. Some devices have more room for display, some have less. So, how much text should you show at a time and for what device? Fortunately for us, MIT takes care of this by the way of pagination.

Pagination automatically formats the text to fit the device. By default, pagination is not turned on, or set to true.

Validating input

Some of the most powerful features of ASP.NET are the validation controls. MIT also has its own set of validation controls; however, these validation controls are much more limited, due in part to the limitations of the mobile devi ces we are sending content to. In fact, validation controls can only validate and controls.

Validation controls themselves come in four different flavors:

RangeValidator: Validates that another control's value falls within a certain range.
RegularExpressionValiator: Validates another control's value against a regular expression.
RequiredFieldValidator: Makes sure the user enters a value for a control.
ValidationSummary: Displays a summary of all validation errors that occur on a form. When using the ValidationSummary control, usually a separate form is built to display all the errors.

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


Caching in ASP.NET

ASP.NET has introduced various new features to the server-side programming model. These new features have made it easier to cache application data, and hence enhance the performance of Web applications. For example, unlike classic ASP, wherein the code is interpreted, all code in ASP.NET is compiled before execution, resulting in huge performance gains.

After the code for an ASP.NET Web page is compiled, all future requests for that page are handled by the compiled code without requiring any recompilation until a change is made to the original ASP.NET page. Also, when a page is accessed for the first time, the code is compiled depending on user needs. For example, if there are 10 functions in an ASP.NET Web page, only those functions are compiled into native machine code, which are needed to respond to a user's request.

Compilation is a two-stage process in the .NET Framework. First, the code is compiled into the Microsoft Intermediate Language (MSIL). Then, the MSIL is compiled into native code during execution. The entire code in an ASP.NET Web page is compiled into MSIL when the solution is built.

However, during execution, only the portions of the code that are actually needed will be compiled into native code. In addition, the configuration of an ASP.NET Web site is loaded from the Web.config file and stored in a memory cache, thereby preventing expensive disk read operations when a configuration value needs to be retrieved.


ASP.NET provides several caching mechanisms that enhance the performance of Web applications. One of the caching mechanisms involves compiling the ASP.NET page and caching the instance on the server. Afterward, the page can be directly retrieved from the cache. The page in the cache is updated only when a change occurs in the page or when the caching period expires.

Expiring of an object from the cache refers to the object being removed from the cache. When the cache expiry for an object is reached, future requests for that object cannot be fulfilled from the cache. In such a situation, the object needs to be retrieved from the actual Web server, or the code behind file for the ASP.NET page needs to be executed again.

ASP.NET supports two types of expiration policies, which determine when an object will be expired from the cache.

These two policies are described as follows:

Absolute expiration: Determines that the expirations occur at a specified time. Absolute expirations are specified in full-time format (hh:mm:ss). The object will be expired from the cache at the specified time.

Relative expiration: Determines that expirations occur after the specified time window has passed. Relative expiration is specified in seconds. After the specified number of seconds, the item is automatically expired from the cache.

The next few sections describe the Cache API and the Cache Performance Monitor counters. Cache API ASP.NET uses the .NET Framework classes to control the caching services. The caching services are encapsulated in the classes contained in the System.Web.Caching namespace. For example, the Cache class is used for explicitly managing an application cache, and the CacheDependency class is used to define and track dependencies of cache objects.

HttpCachePolicy

The complete implementation of cache policies provided by ASP.NET is encapsulated in the HttpCachePolicy class. Applications that want more control over the HTTP headers related to caching can directly use the functionality provided by the HttpCachePolicy class. This class is used to set the expiration time for cached content in relative or absolute time. This class contains methods that are used by ASP.NET to enforce any expiration policies set by the user.

Some of the public properties and methods include in the HttpCachePolicy class are described as follows:

VaryByHeaders: This property represents the list of HTTP headers used to vary the cache output. The ASP.NET cache can maintain different versions of the same Web page if the HTTP headers received in the request are different. This property, therefore, is used to control the HTTP headers that should result in caching multiple versions of the same Web page.

VaryByParams: This property represents the list of parameters received in a Get or Post request. ASP.NET maintains multiple versions of a Web page if the parameter(s) specified in this property vary.

SetCacheability: This is an overloaded method, which sets the Cache-Control HTTP header. Further, the Cache-Control HTTP header controls how documents are to be cached on the network.

SetExpires: This method sets the Expires HTTP header to an absolute date and time.

HttpCacheability

HttpCacheability is an enumeration of all the possible values for the Cache-Control HTTP header. The Cache-Control HTTP header determines whether or not the output is cached. It also determines the location, such as the Web server, proxy server, or a client machine, where the output is cached. The default cache location is the client machine.

The following are the available values in the HttpCacheability enumeration:

NoCache: Indicates that the output will not be cached at any location.

Public: Indicates that the output can be cached on the proxy server as well as on the client side.

Private: Indicates that the output can be cached only on the client side. This is the default value.

Server:
Indicates that the Web server will cache the output and the clients and proxy servers will receive a no-cache HTTP header value.

@OutputCache

This page-level directive in an ASP.NET page is used to control the cache duration of the page output. To control the cache behavior of an ASP.NET page, you can use either the @OutputCache directive or the HttpCachePolicy class. However, if the ASP.NeT page is parameterized by using QueryString parameters or the Post method, the page cache needs to be maintained by setting the VaryByParam attribute.

HttpCacheVaryByParams

When the output generated by an ASP.NET page depends on the parameters passed by using QueryString or the Post method, it requires ASP.NET to maintain multiple versions of the same page. The HttpCacheVaryByParams class is used to maintain multiple versions of the same ASP.NET page in the cache. When the VaryByParam attribute is set with the @OutputCache directive in a page, ASP.NET internally uses the HttpCacheVaryByParams class.

Most Web sites today use dynamic Web pages, which present information depending on user preferences. This approach requires a template page, such as an ASPX page, to be used by Web applications. When a Web page is presented to a user, the data retrieved from a data store is dynamically merged into the template and displayed to the user. Although this approach allows the same page to be tailored dynamically to incorporate user preferences, it has certain problems. These dynamic Web pages are less scalable.

Storing frequently requested data in memory variables on the server side is a familiar concept for ASP developers. In classic ASP, two intrinsic objects, the Session object and the Application object, are used to store application data in memory variables. The Session and Application objects are available in ASP.NET, but their functionality is not enhanced much. ASP.NET encapsulates the application data caching in the Cache class.

related post

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


Understanding Caching in ASP.NET

Usually, Web sites (Web applications) are accessed by multiple users. On certain days, a Web site can experience an extremely low load and, as a result, provide faster access. However, in just a few hours, the load on the site can increase exponentially, resulting in slow access. Slow access is the most common problem that plagues a Web site when it is accessed by a large number of users simultaneously.

However, load is not the only reason why a Web site is slow. Other physical aspects affect speed, such as the type of modem, Internet connection, and telephone line. Therefore, it might not be good business sense to invest in high-grade hardware that handles the entire load just to improve the access speed, because the heavy load is only temporary and not constant.

It would be better if access speeds could be improved without investing in high-grade hardware. In such a scenario, caching provides a solution. Caching is a technique wherein frequently used data and Web pages are stored temporarily on local hard disks for later retrieval. This technique improves the access time when multiple users access a Web site simultaneously or a single user accesses a Web site multiple times.

Caching allows server-side Web applications to scale better, and improves the overall performance of the Web application. Thus, the ASP.NET code does not need to be executed every time to process the same request from multiple clients or from a single client multiple times. This saves on the CPU cycles at the Web server, resulting in improved response time.

Caching, as a technique for improving system performance, is not a new concept. It has been used successfully in various applications, ranging from relational databases such as Microsoft SQL Server to various operating systems. ASP.NET provides a Web cache to store Web objects.
A Web cache is a temporary storage of Web objects, such as HTML documnts, for later retrieval. You can specify the cache location to be on the client or on the server.

The different locations where caching can be performed are described as follows:

Client: To provide improved performance, client applications (like browsers) perform caching by storing data from the Web in temporary files on the hard drive or system memory of users' computers. However, these caches cannot be shared across multiple users.

Dedicated server: Caching can be performed at the server side so that caches can be shared across multiple users on a network. Most administrators use proxy servers, such as Microsoft Proxy Server, to store frequently used Web pages on the hard disk of the proxy server. The proxy server fulfills all the requests for the Web page without sending out the reques to the actual Web server over the Internet, resulting in faster access.

Proxy caches are often located near network gateways to reduce the bandwidth required over expensive dedicated Internet connections. These systems serve many users (clients) with cached objects from many servers.

The Web objects that are requested by one client are stored in a cache, and can be retrieved later when another client requests the same object. For even greater performance, many proxy caches are part of cache hierarchies, in which a cache can enquire neighboring caches for a
requested document, to reduce the need to fetch the object directly.

Such an organization of multiple cache servers is also referred to as a cache array.

Reverse proxy: Caches can also be placed directly in front of a particular Web server, to reduce the number of requests that they receive. This model allows the proxy server to respond to the frequently received requests and pass the other requests to the Web server. This form of proxying is called a reverse proxy, wherein the proxy server is used by the Web server to speed up request processing.

This model is unique in that it caches objects for many clients, but usually from a single server.
After discussing the various locations where caching can be performed, let us now look at some of the most significant advantages of Web caching:

Reduced bandwidth consumption: Because the frequently used data and Web pages are cached and ASP.NET allows developers to configure the cache location to be on the client machine, most requests are fulfilled from the local cache. Therefore, fewer requests and responses need to go over the network between the client and the server. This results in reduced and width consumption.

Reduced server load: Because frequently used data and Web pages are retrieved from the cache, the server does not need to execute the same ASP.NET code multiple times to produce the same output. This saves valuable CPU time at the server end.

Reduced latency: Because most requests do not need to go to the server for processing, the access time improves significantly. Although Web caching provides many advantages, it is one of the most misunderstood technologies on the Internet. Webmasters, in particular, fear losing control of their sites because a cache can hide their users from them, making it difficult to see who's using the sites.

In addition, the number of hits is not counted correctly, because the cache server(s) might fulfill some percentage of client requests.

However, careful planning and proper location of a proxy server cache will help your Web site load faster, and reduce load on your server and the Internet link. The difference can be dramatic; a site that is difficult to cache may take several seconds to load. Users will appreciate a fast-loading site, and will visit it more often.

Another concern related to Web caching is that the caches might serve outdated content.


related post

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


Interfaces and Classes Used to Create HTTP Handlers in ASP.NET

The .NET Framework provides classes that enable you to handle HTTP requests for the ASP.NET Web pages and services. You can handle HTTP requests by creating a class that implements the IHttpHandler interface contained in the System.Web namespace.

The System.Web namespace contains classes and interfaces that enable you to handle the communication between browsers and Web servers. Before you can use a class that implements the IHttpHandler interface, you need to write the section in the Web.config configuration file to map the class that implements IHttpHandler to a URL request.

Before you create an HTTP Handler, let us look at the IHttpHandler and IHttpHandlerFactory interfaces, and some of the classes contained in the System.Web namespace.

IHttpHandler interface

The IHttpHandler interface must be implemented to create user-defined HTTP handlers to process Web requests. Specific instances of the classes that implement the IHttpHandler interface process the Web requests received by ASP.NET. When you create a class that implements the IHttpHandler interface, you need to implement a method and a property of this interface. The method that needs to be implemented is ProcessRequest, and the property that needs to be implemented is IsReusable.

ProcessRequest

The ProcessRequest method is called whenever an HTTP request is made and has the following Visual Basic .NET syntax:

Sub ProcessRequest (ByVal context As HttpContext)

End Sub

As you can see in the preceding syntax, the ProcessRequest method takes an object of the HttpContext class (discussed later in this section) as a parameter. You use the HttpContext object to handle all Web requests.

IsReusable

The IsReusable property is an overrideable read-only property that gets a value indicating whether the instance of the class that implements the IHttpHandler interface can be recycled and used for other Web requests. The Visual Basic .NET syntax of the IsReusable property is given as follows:

ReadOnly Property IsReusable As Boolean

As you can see in this syntax, the IsReusable property gets a Boolean value. If it gets True, the IHttpHandler instance can be reused for other Web requests. However, if the property gets False, the IHttpHandler instance cannot be reused for other Web requests.

IHttpHandlerFactory interface

As mentioned earlier, the Web requests received by ASP.NET are processed by specific IHttpHandler instances. At run time, the Web requests must be resolved to the IHttpHandler instances. This resolution of the Web requests to the IHttpHandler instances is done by the IHttpHandlerFactory interface. This interface contains two methods, GetHandler and ReleaseHandler.

GetHandler

The GetHandler method returns an IHttpHandler object that processes the Web request from the client. The Visual Basic syntax for the GetHandler method is given as follows:

Function GetHandler( ByVal context As HttpContext, ByVal requesttype As String, ByVal url As String, ByVal pathtranslated As String ) As IHttpHandler End Function The return type of the GetHandler method is IHttpHandler. The different parameters include:

context: Represents the object of the HttpContext class that provides reference to built-in server objects

requesttype: Represents a string value that refers to the method used for HTTP data transfer, such as Get and Post

url: Represents a string value that refers to the URL that is requested by the client

pathtranslated: Represents the string value that refers to the physical path of the application's root directory

ReleaseHandler

The ReleaseHandler method allows releasing an IHttpHandler instance so that it can be reused. The Visual Basic syntax for the ReleaseHandler method is given as follows.

Sub ReleaseHandler( ByVal handler As IHttpHandler)

End Sub

In this code, handler is the IHttpHandler instance that needs to be released.

RELATED POST

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO