Master of Computer Application (MCA) – Semester 5

MC0081 – (DOT) Net Technologies – 4 Credits

Assignment Set – 1 (40 Marks)

Answer all Questions Each question carries TEN

marks

1. Explain the features of .Net Platform.

The Microsoft’s .Net platform encompasses a virtual machine that abstracts away much of the windows API from development. It includes a class library with more functionality than any other created to date, and a development environment that spans multiple languages. It provides an architecture that makes multiple language integration simple and straightforward. This is the first development platform designed from the ground up with Internet in mind. .Net is designed and intended for highly distributed software, making Internet functionality and interoperability easier and more transparent to include in systems than ever before. Microsoft has taken many of the best ideas from the industry, combined with some ideas of their own, and brought them altogether into one coherent package.Features of .Net Platform

The .NET Framework is an integral Windows component that supports building and running the

next generation of applications and XML Web services. The .NET Framework is designed to fulfill

the following objectives:

To provide a consistent object-oriented programming environment whether object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely.

To provide a code-execution environment that minimizes software deployment and versioning conflicts.

To provide a code-execution environment that promotes safe execution of code, including code created by an unknown or semi-trusted third party.

To provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments.

To make the developer experience consistency across widely varying types of applications, such as Windows-based applications and Web-based applications.

To build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code.

The .NET Framework has two main components: the common language runtime and the .NET Framework class library. The common language runtime is the foundation of the .NET Framework. You can think of the runtime as an agent that manages code at execution time, providing core services such as memory management, thread management, and remoting, while also enforcing strict type safety and other forms of code accuracy that promote security and robustness. In fact, the concept of code management is a fundamental principle of the runtime. Code that targets the runtime is known as managed code, while code that does not target the runtime is known as unmanaged code. The class library, the other main component of the .NET Framework, is a comprehensive, object-oriented collection of reusable types that you can use to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by ASP.NET, such as Web Forms and XML Web services. The .NET Framework can be hosted by unmanaged components that load the common language runtime into their processes and initiate the execution of managed code, thereby creating a software environment that can exploit both managed and unmanaged features. The .NET Framework not only provides several runtime hosts, but also supports the development of third-party runtime hosts.

2. With the help of a suitable example, explain the steps involved in editing, compiling

and running a C# program.

Creating C# Program

To create, compile and run a C# program by following the steps illustrated in the following topics

Compiling and Executing

The minimum requirements for getting started with C# programming are: 1. A text editor (like Windows Notepad) 2. The Microsoft .NET Framework The text editor allows you to type in the C# code that will be compiled.

Example:

Public class classtest

{

Public static void Main ()

{

System.console.writeLine (“Welcome to c#”);

}

}

The sample program typed in Notepad

The Microsoft .Net Framework

In addition to the text editor, you should have the Microsoft .Net Framework installed on your PC or Laptop.Steps for writing and compiling the C# code:

Step – 1: Type the C# code in the notepad as shown below:

Public class classtest

{

Public static void Main ()

{

System.console.writeLine (“Welcome to c#”);

}

}

Step – 2: Save the file into the folder containing the folder corresponding to C#. In my machine it is:

C:\Program Files\Microsoft Visual Studio\SDK\V2.0>

Step – 3: Open the command prompt (Start -> Run and type cmd and click OK) and navigate to the folder where you have saved the file. Alternatively you can start the command window from Windows Start Menu

Step – 4: Now we are ready to compile the program from the C# command line. The compiler used here is called csc.exe and is in the folder v2.0 of SDK. The syntax for compiling the sample C# program is:csc.exe <filename>.csThe name of our C# program is classtest.cs. The syntax for compilation of the above program file is:csc.exe classtest.cs

Step – 5: The source code is now compiled into an executable format. The name of the executable file thus generated is hello.exe, which is having the same name as the source code file name, except that the .cs extension is replaced by the .exe extension.To run the executable file, the following command should be typed at the command prompt:classtest .exeThe executable file gets executed by the environment and the string message “Welcome to C#” would be displayed on the console window.

3. Describe the Web Form Life Cycle.

Web Form Life Cycle Every request for a page made from a web server causes a chain of events at the server. These events, from beginning to end, constitute the life cycle of the page and all its components. The life cycle begins with a request for the page, which causes the server to load it. When the request is complete, the page is unloaded. From one end of the life cycle to the other, the goal is to render appropriate HTML output back to the requesting browser. The life cycle of a page is marked by the following events, each of which you can handle yourself or leave to default handling by the ASP.NET server:

Initialize: Initialize is the first phase in the life cycle for any page or control. It is here that any settings needed for the duration of the incoming request are initialized.

Load ViewState: The ViewState property of the control is populated. The ViewState information comes from a hidden variable on the control, used to persist the state across round trips to the server. The input string from this hidden variable is parsed by the page framework, and the ViewState property is set. This can be modified via the LoadViewState( ) method: This allows ASP.NET to manage the state of your control across page loads so that each control is not reset to its default state each time the page is posted.

Process Postback Data: During this phase, the data sent to the server in the posting is processed. If any of this data results in a requirement to update the ViewState, that update is performed via the LoadPostData ( ) method. Load: CreateChildControls ( ) is called, if necessary, to create and initialize server controls in the control tree. State is restored, and the form controls show client-side data. You can modify the load phase by handling the Load event with the OnLoad method.

Send Postback Change Modifications: If there are any state changes between the current state and the previous state, change events are raised via the RaisePostDataChangedEvent ( ) method. Handle Postback Events: The client-side event that caused the postback is handled.

PreRender: This is the phase just before the output is rendered to the browser. It is essentially your last chance to modify the output prior to rendering using the OnPreRender ( ) method.

Save State: Near the beginning of the life cycle, the persisted view state was loaded from the hidden variable. Now it is saved back to the hidden variable, persisting as a string object that will complete the round trip to the client. You can override this using the SaveViewState () method.

Render: This is where the output to be sent back to the client browser is generated. You can override it using the Render method. CreateChildControls ( ) is called, if necessary, to create and initialize server controls in the control tree.

Dispose: This is the last phase of the life cycle. It gives you an opportunity to do any final cleanup and release references to any expensive resources, such as database connections. You can modify it using the Dispose ( ) method.

4. Describe the theory of Server Controls in ASP.Net

ASP.NET Server ControlsASP.NET Web Server controls are objects on ASP.NET Web pages that run when the page is requested and render markup to a browser. Many Web server controls are similar to familiar HTML elements, such as buttons and text boxes. Other controls encompass complex behavior, such as calendar controls, and controls that manage data connections.

ASP.NET Web Server Controls Overview

When you create ASP.NET Web pages, you can use these types of controls:HTML Server Controls: They are the HTML elements exposed to the server so you can program them. HTML server controls expose an object model that maps very closely to the HTML elements that they render.

Web Server Controls: They are the Controls with more built-in features than HTML server controls. Web server controls include not only form controls such as buttons and text boxes, but also special- purpose controls such as a calendar, menus, and a tree view control. Web server controls are more abstract than HTML server controls in that their object model does not necessarily reflect HTML syntax.

Validation Controls: They are the Controls that incorporate logic to enable you to what users enter for input controls such as the Textbox control. Validation controls enable you to check for a required field, to test against a specific value or pattern of characters, to verify that a value lies within a range, and so on. User Controls: They are the Controls that you create as ASP.NET Web pages. You can embed ASP.NET user controls in other ASP.NET Web pages, which is an easy way to create toolbars and other reusable elements. HTML Server Controls HTML server controls are HTML elements (or elements in other supported markup, such as XHTML) containing attributes that make them programmable in server code. By default, HTML elements on an ASP.NET Web page are not available to the server. Instead, they are treated as opaque text and passed through to the browser. However, by converting HTML elements to HTML server controls, you expose them as elements you can program on the server. The object model for HTML server controls maps closely to that of the corresponding elements. For example, HTML attributes are exposed in HTML server controls as properties.

Any HTML element on a page can be converted to an HTML server control by adding the attribute runat="server". During parsing, the ASP.NET page framework creates instances of all elements containing the runat="server" attribute. If you want to refer to the control as a member within your code, you should also assign an id attribute to the control.

The page framework provides predefined HTML server controls for the HTML elements most commonly used dynamically on a page: the form element, the input elements (text box, check box,

Submit button), the select element, and so on. These predefined HTML server controls share the basic properties of the generic control, and in addition, each control typically provides its own set of properties and its own event.

HTML Server Control Features: An object model that you can program against on the server using familiar object-oriented

techniques. Each server control exposes properties that enable you to manipulate the control's markup attributes programmatically in server code.

A set of events for which you can write event handlers in much the same way you would in a client-based form, except that the event is handled in server code.

The ability to handle events in client script. Automatic maintenance of the control's state. When the page makes a round trip to the server,

the values that the user entered into HTML server controls are automatically maintained and sent back to the browser.

Interaction with ASP.NET validation controls so you can verify that a user has entered appropriate information into a control.

Data binding to one or more properties of the control. Support for styles if the ASP.NET Web page is displayed in a browser that supports cascading

style sheets. Pass-through of custom attributes. You can add any attributes you need to an HTML server

control and the page framework will render them without any change in functionality. This enables you to add browser-specific attributes to your controls.

Working with Web Server Controls Web server controls are a second set of controls designed with a different emphasis. They do not necessarily map one-to-one to HTML server controls. Instead, they are defined as abstract controls in which the actual markup rendered by the control can be quite different from the model that you program against. For example, a RadioButtonList Web server control might be rendered in a table or as inline text with other markup. Web server controls include traditional form controls such as buttons and text boxes as well as complex controls such as tables. They also include controls that provide commonly used form functionality such as displaying data in a grid, choosing dates, displaying menus, and so on. The controls use syntax such as the following:

<asp: button attributes runat="server" id="Button1" />The attributes in this case are not those of HTML elements. Instead, they are properties of the Web control. When the ASP.NET Web page runs, the Web server control is rendered on the page using appropriate markup, which often depends not only on the browser type but also on settings that you have made for the control. For example, a Textbox control might render as an input tag or a textarea tag, depending on its properties. You add controls to an ASP.NET Web page much the same way you add any HTML element. You can either use a visual designer or add a control from the toolbox, or you can type the element representing the control into the page's markup.

February 2010

Master of Computer Application (MCA) – Semester 5

MC0081 – (DOT) Net Technologies – 4 Credits (Book ID: B0974)

Assignment Set – 2 (40 Marks)

Answer all Questions Each question carries TEN marks

1. Describe the following with respect to ASP.Net:

A) Session StateASP.NET allows you to save values by using session state – which is an instance of the HttpSessionState class – for each active Web-application session.Session state is similar to application state, except that is is scoped to the current browser session. If different users are using your application, each user session will have a different session state. In addition, if a user leaves your application and then returns later, the second user session will have a different session state from the first.Session state is structured as a key/value dictionary for storing session-specific information that needs to be maintained between server round trips and between requests for pages.You can use session state to accomplish the following tasks:

Uniquely identity browser or client-device requests and map them to an individual session instance on the server.

Store session-specific data on the server for use across multiple browser or client-device requests within the same session.

Raise appropriate session management events. In addition, you can write application code leveraging these events.

Once you add your application-specific information to session state, the server manages this object. Depending on which options you specify, session information can be stored in cookies, on an out-of-process server, or an a computer running Microsoft SQL Server.

B) Application StateASP.NET allows you to save values using application state – which is an instance of the HttpApplocationState class – for each active Web application. Application state is a global storage mechanism that is accessible from all pages in the Web application. Thus, application state is useful for storing information that needs to be maintained between server round trips and between requests for pages.

Application state is stored in a key/value dictionary that is created during each request to a specific URL. You can add your application-specific information to this structure to store it between page requests.Once you add your application-specific information to application state, the server manages it.

2. Describe the theory of the following concepts in ADO.Net:

A) Connection StringsThe .NET Framework 2.0 provides new capabilities for working with connection strings, including the introduction of new keywords to the connection string builder classes, which facilitate creating valid connection strings at run time. A connection string contains initialization information that is passed as a parameter from a data provider to a data source. The syntax depends on the data provider, and the connection string is parsed during the attempt to open a connection. Syntax errors generate a run-time exception, but other errors occur only after the data source receives connection information. Once validated, the data source applies the options specified in the connection string and opens the connection. The format of a connection string is a semicolon-delimited list of key/value parameter pairs:

kkeeyywwoorrdd11==vvaalluuee;; kkeeyywwoorrdd22==vvaalluuee;;

Keywords are not case sensitive, and spaces between key/value pairs are ignored. However, values may be case sensitive, depending on the data source. Any values containing a semicolon, single quotation marks, or double quotation marks must be enclosed in double quotation marks.

Valid connection string syntax depends on the provider, and has evolved over the years from earlier APIs like ODBC. The .NET Framework Data Provider for SQL Server incorporates many elements from older syntax and is generally more flexible with common connection string syntax. There are frequently equally valid synonyms for connection string syntax elements, but some syntax and spelling errors can cause problems. For example, "Integrated Security=true" is valid, whereas "IntegratedSecurity=true" causes an error. In addition, connection strings constructed at run time fromunvalidated user input can lead to string injection attacks, jeopardizing security at the data source. To address these problems, ADO.NET 2.0 introduces new connection string builders for each .NET Framework data provider. Keywords are exposed as properties, enabling connection string syntax to be validated before submission to the data source. There are also new classes that simplify storing and retrieving connection strings in configuration files and encrypting them using protected configuration.

B) Connection String BuildersIn previous versions of ADO.NET, compile-time checking of connection strings with concatenated string values did not occur, so at run time, an incorrect keyword would generate an ArgumentException. Each of the .NET Framework data providers supports different syntax for connection string keywords, making constructing valid connection strings difficult if done manually. To address this problem, ADO.NET 2.0 introduces new connection string builders for each .NET Framework data provider. Each data provider provides a strongly typed connection string builder class that inherits from DbConnectionStringBuilder. The following table lists the .NET Framework data providers and their associated connection string builder classes.

Provider ConnectionStringBuilder class System.Data.SqlClient SqlConnectionStringBuilder System.Data.OleDb OleDbConnectionStringBuilder System.Data.Odbc OdbcConnectionStringBuilder System.Data.OracleClient OracleConnectionStringBuilder

3. Describe the following Web Services:

A) Web Service Discovery – DISCOOnce a client has a WSDL contract describing a Web service’ it has all the information it needs to make calls to that Web services. But when you publish a web service by making it available on a Web server , how do clients find out where to get a WSDL contract? For that matter, how do clients know that your Web service exists in the first place? The answer comes in two parts: DISCO and universal Description, Discovery, and Integration ,better know as UDDI . The Former is a file-based information mechanism for local Web Service discovery – that is, for getting a list of available Web services from DISCO file developed on Web severs. The latter is a global web service directory that is itself implemented as a Web service. UDDI is discussed in the next section. The DSICO (short for “discovery”) protocol is a simple one that revolves around XML-based DISCO file .The idea is that you publish a DISCO file on your Web server that describes the Web server that describes the Web services available on it and perhaps on other servers as well .Clients can interrogate the DISCO file to find out what web services are available and where the services’ WSDL contracts can be found .As an example , suppose you publish two web services and their URLs are follows:

http://www.wintellect.com/calc.asmxhttp://www.wintellect.com/locator.asmx

To advertise these Web services , you can deploy the following DISCO file at a well –known URL on your server. The contractRef element identifies the URLs of the Web services’WSDL contract. URLs can be absolute or relative . The optional docRef attributes identify the locations of document describing the Web services, which, because of the self-documenting nature of web services built with the .NET Framework are typically the ASMX file themselves:

<?xml version =’1.0’?><discovery xmlns=http://schemas.xmlsoap.org/disco/xmlns:scl=http://schemas.xmlsoap.org/disco/scl/”><scl:contractRef ref =http://www.wintellect.com/calc.asmx?wsdl”docRef=http://www.wintellect.com/calc.asmx”/><scl:contractRef ref=”http://www.wintellect.com/locator.asmx?wsdl”docRef=http://www.wintellect.com/locator.asmx/></discover>

If you’d prefer ,you can write DISCO files for individual Web services and reference Them in master DISCO file using discoveryRef element . Here’s a DISCO file that points to other DISCO file that points to other DISCO files .Once more URLs can be absolute or relative:

A third

option is to deploy a VSDISCO to enable dynamic discovery . The following VSDISCO file automatically exposes all ASMX and DISCO files in a host directory and its subdirectories ,with the exception of these subdirectories noted with exclude element:

How does dynamic discovery work ? ASP. NET maps the file name extension.vsdisco to an HTTP handler that scans the host directory and subdirectory for ASMX and DISCO files and returns a dynamically generate DISCO document .A client that request a VSDISCO file gets back what appears to be static DISCO document For security reasons ,Microsoft disable dynamic discovery just before version 1.0 of the .NET Framework shipped .You can re-enable it by un-commenting the line in the httpHandlers section of Machine .config that maps *.vsdisco to System.WebServices.DiscoveryRequestHandler and granting the ASPNET account permission to access the IIS metabase Microsoft highly discourages dynamic discovery for fear of compromising your Web server ,and a bug in version1.0 of the .NET Framework SDK prevent most DISCO-aware tools from working with VSDISCO anyway . My advice is to forget that VSDISCO files even exist and use static DISCOFiles instead.

To further simplify Web services discovery , you can link to a master DISCO file from your site’s default HTML document . For example ,suppose the default HTML document at www.wintellect.com is default .html and that the same directory also holds a directory document named Default.disco. Including the following HTML in Default.html enables most tools that read DISCO files to accept the URL ww.wintellect.com

<html><head><link type=”text/html”rel=”alternate”href=”Default.disco”></head></html>

<?xml version=”1.0”?><discovery xmlns=http://schemas.xmlsoap.org/disco/”><discoveryRef ref =”http://www.wintellect.com/calc.disco”/><discoveryRef ref =”http://www.wintellect.com/locator.disco”/></discover>

<?xml version=”1.0”?><dynamic discoveryxmlns=”urn:schemas-dynamicdiscovery:disco .2000-30-17”><exclude path=”_vti_cnf”/><exclude path=”_vti_pvt”/><exclude path=”_vti_log”/><exclude path=”_vti_script”/><exclude path=”_vti_txt”/><dynamic discovery>

Visual Studio.NET reads DISCO files; so does the disco.exe utility that comes with the .NET Framework SDK Discos chief disadvantages is thts at you can’t read Disco file if you don’t have its URL . So how do you find a web service if you don’t even have a URL to start with ?can you spell U-D-D-I?

B) Web Service Discovery – UDDIUDDI is an abbreviation for Universal Description, Discovery, and Integration. Jointly developed by IBM, Microsoft, and Ariba and supported by hundreds of other companies, UDDI is a specification for building distributed databases that enable interested parties to “discover “each other’s Web services. No one company owns the databases; anyone is free to publish a UDDI-based business registry. Operator sites have already been established by IBM and Microsoft and are likely to be the first of many such sites that will come on line in the future.

UDDI sites are themselves Web services. They publish a pair of SOAP- based APIs; an inquiry API for inquiring about companies and their Web services and a published API for advertising a company’s Web services. Anyone can call the inquiry API, but operator site typically limit the publisher API to registered member.

At the time of this writing, Microsoft was beta testing a UDDI .NET SDK featuring managed wrapper classes that simplify interactions with UDDI business registries.

Most developers will never deal with UDDI APIs directly .Instead, they’ll use high-level tools such as Visual Studio .NET to query UDDI business registries and generate wrapper classes that allow them to place calls to the Web services that they find there. The actual placing of UDDI calls will be limited primarily to tools vendors and to clients that wish to locate and bind to web services dynamically.

4. Describe the theory of creating application pools in IIS 6.0.

When you run IIS 6.0 in worker process isolation mode, you can isolate different Web application or Web sites in pools, which are called Application Pools. An application pool is a group of URLs that are routed to one or more worker processes that share the same configuration. The URLs that you assign to an application pool can be for an application, a Web site, a Web directory, or virtual directory.

In an application pool, process boundaries separate each worker process from other worker processes so that when an application is routed to one application pool, application in other application in other application pools do not affect that application .

By using an application pool, you can assign specific configuration settings to a worker process that services a group of applications. For example, you can configure worker process recycling, which offers several configuration options to match the need of each application. If, for example, you suspect that an application has a memory leak ,you might configure the application pools worker process to recycle when its memory use reaches a certain threshold . If another application fails because of the volume of request that it receives, you can set the application pools worker process to recycle when the application exceeds specified number of requests.

By creating new application pools and assigning Web sites and applications to them ,you can make your server more efficient , reliable , and secure, and ensure that your application remain available even when a worker process serving an application pool is recycled because of faulty application.

Configuring Application Pools in IIS6.0(IIS 6.0)

. An application pool is configuration that links one or more application to a set of one or more worker processes. Because applications in an application pool are separated from other applications by worker process boundaries, an application in one application pool is not affected by problem caused by application in other application pools.

By creating new application pools and assigning Web site and applications to them, you can make your server more efficient and reliable, as well as making your other application always available, even when the worker process serving the new application pool has problems.

Guidelines for Creating Application Pools To isolate Web application on a Web site from Web application on other sites worker running

on the same computer, create an individual application pool for each Web site. For enhanced security, configure a unique user account (process identify) for each application

pool. Use an account with the least user right possible, such as Network services in the IIS_WPG group.

If there is a test version of an application on the same server with the production version of the application pools this isolates the test version of the application.

As a design consideration , if you b. Deploying ASP.NET Application to run with its own unique set of properties, create a unique application pool for that application .

Note: You must be a member of the Administrators group on the local computer to perform the following procedures .As a security best practice, log on to your computer by using an account that is not in the administrators group, and then use the runas command to run IIS Manager as an administrator At a command prompt, type runas /user: Administrative_AccountName ”mmc%systemroot%system32\inetsrv\iis.msc”. Step to create a new Application Pool :

1. In IIS Manger, expand the local computer, right-click Application Pools, point to new and then click Application Pool.

2. In the application pool name box, type the new application tool.

3. If the ID that appears in the Application pool Id box is not the ID that you want, type a new ID.

4. Under Application pool setting, click the appropriate setting. If you click Use existing application tool as template, in the application pool name box, right click the application pool that you want to use as a template.

5. Click OK.

Application pool allows you to apply configuration settings to group of applications and the worker processes that service those applications. Any web site, web directory, or virtual directory can be assigned to an application pool.

Assigning an application to an application pool:

In IIS Manager, right click the application that you want to assign to an application pool, and then click properties.

Click the virtual directory, directory and home directory tab. If you are assigning a directory or virtual directory, verify that application name is filled in. If the

application name box is not filled in, click create, and then type a name. In the application pool list box, click the name of the application pool to which you want to assign

the web site.

About Configuring Servers for applications (IIS 6.0)

Internet information services (IIS) 6.0 delivers web hosting services through an adjustable architecture that you can use to manage server resources with improved stability, efficiency, and performance. IIS separates applications into isolated pools and automatically detects memory leaks,

defective processes, and over utilized resources. When problems occur, IIS manages them by shutting down and redeploying faulty resources and connecting faulty processes to analytical tools.IIS can run in either of two mutually exclusive modes of operation:

Worker process isolation mode. This is the default mode of IIS 6.0, isolates key components of the World Wide Web publishing service (WWW service) from the effects of errant applications, and it protects applications from each other by using the worker process component. Use worker process isolation mode unless you have a specific compatibility issue that makes the use of IIS 5.0 isolation mode necessary. Web sites that serve static content or simple ASP applications should be able to move to IIS 6.0 running in worker process isolation mode with little or no modification.

IIS 5.0 isolation mode. With this mode, you can run applications that are incompatible with worker process isolation mode because they were developed for earlier versions of IIS. Applications that run correctly on IIS 5.0 should run correctly on IIS 6.0 in IIS 5.9 isolation mode.

Worker process isolation mode provides better default security for running web applications than IIS 5.0 isolation mode. By default, worker processes run with the Network service identity. The network service account has lower access rights than the default account for IIS 5.0 application mode run as local system. The local system account can read, execute, and change most of the resources on the computer.

The default isolation mode upon installing IIS 6.0 depends on whether you perform a clean installation or an upgrade.

After a clean install of IIS 6.0, IIS runs in worker process isolation mode. After an upgrade from an earlier version of IIS 6.0, the isolation mode is the same as configured on

the previously-installed version of IIS 6.0. After an upgrade from IIS 5.0 or IIS 4.0, IIS 6.0 runs in IIS 5.0 isolation mode by default to

maintain compatibility with your existing applications.

Worker Process Isolation Mode

IIS 6.0 introduces worker process isolation mode, which runs all Web applications in an isolated environment. When you run IIS in worker process isolation mode, applications can be configured to run in separate application pools. Each application pool is a logical representation of a configurable worker process and links to the applications in the pool. Worker processes operate independently of each other, they can fail without affecting other worker processes . The pooling of applications protects applications from the effects of worker processes that support other application pools. In this way, applications are protected from each other.

In worker process isolation mode, Hypertext Transfer Protocol (HTTP) requests are routed directly to an in-kernel application pool queue serving the configured application. Worker processes that serve an application pool pull the requests directly from the queue avoiding process-switching overhead.

To further protect your WWW service, IIS 6.0 isolates critical World Wide Web publishing service (WWW service) components, such as the HTTP protocol stack (HTTP.sys) and WWW service Administration and monitoring, from the effects of third party code running in worker processes. HTTP.sys continues to process requests. Meanwhile, the WWW service detects that the worker process is unhealthy and shuts it down. If there is demand for a new worker process to serve requests (HTTP.sys has requests queued), the WWW service starts a new worker process to pick the queued request form HTTP.sys. Even though a worker process has failed, the WWW service continues to process requests and shields the user from experiencing a loss of service.

IIS 6.0 worker process isolation mode delivers the following specific improvements over earlier versions of IIS:

Robust Performance isolation prevents Web applications and Web sites from affecting each other or the WWW service. Reboots of the operating system and restarting of the WWW service are avoided.

Self-Healing automated management provides auto restart of failed worker processes and periodic restart of deteriorating worker process.

Scalability Web gardens allow more than one worker process to serve the same application pool. Process Affinity enables the connection of worker processes to specific processors on multi-CPU

servers. Automated debugging the debugging feature enables the automatic assignment of failing worker

processes to debugging tools. CPU limiting this monitoring feature enables controlling the amount of CPU resources that an

application pool consumes in a configured amount of time.