Web Services Infrastructure IN ASP.NET part two

ASP.NET is a unified Web development platform that provides advanced services for building Web applications and Web services. ASP.NET provides a new programming model and infrastructure that enables you to create powerful Web applications with unprecedented speed, flexibility, and ease. ASP.NET is fully supported by the .NET Framework, enabling you to take full advantage of the CLR, type safety, inheritance, and all the other features of that platform.

Unlike Active Server Pages (ASP), ASP.NET is a compiled, .NET-based platform. ASP.NET applications can be built using any .NET-compatible programming language. Also, because ASP.NET is built on top of the .NET Framework, your ASP.NET applications have access to the entire range of functionality provided by the framework. Among the major advantages of the ASP.NET environment are the following: § ASP.NET applications are fully compiled .NET applications, providing superior performance characteristics.

ASP.NET supports WYSIWYG HTML editors and programming environments such as Visual Studio .NET. This enables you to be very productive when developing ASP.NET applications and enables you to leverage the many features of these tools.

ASP.NET applications support extensive configuration capabilities based on XML configuration files.

ASP.NET provides flexible, advanced, and easy-to-use application and session state management features that can be extended or replaced with custom schemes.
ASP.NET implements multiple authentication and authorization schemes that can be extended or replaced with custom schemes.

ASP.NET provides two programming models that can be used to create Web applications: Web Forms and Web Services. Web Forms enable you to build formsbased Web applications using a technology called server controls, which enable you to create user interfaces from common UI elements such as text boxes, list boxes, and so on.

ASP.NET Web Services can take advantage of all ASP.NET features as well as the features of the .NET Framework and CLR. Let's take a look at some of these features, because you will likely interact with many of them when implementing your Web service applications. ASP.NET leverages the classes found in the .NET Framework Class Library to support Web services and the many other features this environment provides to developers.

ASP.NET applications

An ASP.NET application consists of all the files, pages, handlers, modules, and executable code that reside in a Web server virtual directory (and any subdirectories). Web services are also ASP.NET applications and, therefore, are governed by the same configuration rules as any other ASP.NET application. Each ASP.NET application can include an optional Global.asax file in the root virtual directory. This file contains handlers for application-level events that can be raised by ASP.NET. For example, you can handle such events as Application_OnStart and Application_OnEnd in the Global.asax file.

In addition to these events, you have access to any events exposed by HTTPModules. An HTTPModule is a class that can process information from any HTTP requests made to your ASP.NET application. You can customize or extend modules supplied by ASP.NET or create your own. Any events raised by HTTPModules are handled within the Global.asax file.

ASP.NET applications also support a hierarchical application configuration architecture. Application configuration settings are stored in an XML file named Web.config. The settings stored in this file are applied hierarchically as follows:

Web.config files supply their settings to the directory in which they are located as well as to all subdirectories.

Configuration settings for a Web resource are supplied by the Web.config file located in the same directory as the resource and by all configuration files in all parent directories.

The default, global configuration file is named Machine.config and is stored at %SYSTEM_ROOT%\Microsoft.NET\Framework\version\CONFIG. If no developersupplied
configuration files are found, the settings in this file will apply to your Web application.

State management

HTTP is a stateless protocol. This means that HTTP does not retain any information or knowledge from one request to the next even though those requests may come from the same user session and may even be related to each other. Of course, if you are building Web applications, the lack of such state information can make it extremely difficult to develop applications that require such information.

ASP.NET provides both application state and session state management capabilities for Web applications. Application state is used to store data that applies to the application as a whole and is available to all sessions using the application. Session state is used to store data that is specific to each browser session using the application. Session state is not visible across different sessions (unlike application state). Both application and session state information is stored in key/value dictionary objects.

Access to this information is supplied through an Application object (for application state) and a Session object (for session state).

Application state is essentially a global variable-storage mechanism for ASP.NET applications. Experienced developers know that global variables come with specific issues and must be considered and used sparingly. This is even more important in a server-based scenario, such as ASP.NET applications. In particular, you should be aware of the following when considering the use of application state in ASP.NET applications:

Memory used by application variables is not released between requests. Thus, it can have extended effects on server memory use.

Therefore, you should be a good custodian of application state memory.

Application variables have concurrency and synchronization issues. Because multiple requests can be executing simultaneously, any changes to application-scoped variables must be synchronized. This can cause concurrency issues and slow down server performance.

Application state is not shared across a Web farm (where an application is hosted on multiple servers) or Web garden (where an application is hosted on multiple processes on a single server).
These issues are certainly not meant to scare you away from using application state. On the contrary, used properly, application state can be a very valuable tool for Web applications.

Session state permits you to automatically identify requests that come from the same browser client as well as store information specific to that session. ASP.NET session state provides the following features:

Session state can survive IIS and worker-process restarts without losing session state information.

Session state can be used in both Web farm and Web garden configurations.

Session state can be used even if the client browser does not support cookies.

ASP.NET session state can be fully configured to meet your specific needs via the Config.web configuration files. For Web applications that require session state, ASP.NET provides excellent, reliable, and scalable support for maintaining session state.

Caching

One of the most important factors in creating highly scalable, high-performance Web applications is through the use of caching. Essentially, caching permits the Web application to supply the results of a previous request to other requests for the same information without having to involve the server in regenerating this information. This can greatly increase the performance of your Web application.

ASP.NET provides two types of caching capabilities. Output caching supplies the output of previous requests from the output cache instead of re-executing the server code necessary to generate the output a second time. The application cache is a programmatic cache that applications can use to store objects and other resources that can take a lot of time to re-create.

Transactions

A transaction is a set of related tasks that either succeed or fail as a unit. By combining a set of related operations into a unit that either completely succeeds or completely fails, you can simplify error recovery and make your application more reliable. ASP.NET Web Services support declarative, attribute-based transactions at the method level. This means that you can specify, via a property of the WebMethod attribute, what, if any, type of transaction support is required for your Web service method.

Subsequently, any resource managers that you interact with during the execution of the Web method (such as SQL Server, Message Queue Server, SNA Server, Oracle Server, and so on) will be transacted.


Security

ASP.NET provides a comprehensive, flexible, and extensible security framework that enables you to secure your Web services. The security framework addresses four fundamental security needs:
  1. Authentication: To determine that a user is who he/she claims to be
  2. Authorization: To control access to resources based on the identity of a user
  3. Impersonation: To assume the identity of the requesting user when accessing resources
  4. Code Access Security: To restrict the operations that a piece of code can perform

In addition to the authentication services provided by IIS, ASP.NET supports two additional types of authentication: Forms and Passport. Forms authentication enables custom authentication to occur via support provided by the application. For example, you may use a custom SQL Server database of defined users and passwords to identify users. Passport authentication is a centralized authentication service provided by Microsoft that offers a single sign-on feature along with basic profile services.

ASP.NET security is configured in the ASP.NET application configuration file (named Web.config). Using this configuration file, you can specify how users are authenticated, control access to resources via authorization settings, and determine impersonation settings.


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


No comments:

Post a Comment