MC0081 – .(DOT) Net Technologies – 4 Credits

February 2011

Master of Computer Application (MCA) – Semester 5

MC0081 – .(DOT) Net Technologies – 4 Credits

(Book ID: B0974)

Assignment Set – 1 (40 Marks)

Answer all Questions Each question carries TEN marks

1. Describe the steps involved in creating classes and objects with the help of a program in

C#002E

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

running a C# program.

3. Discuss the following:

• Web.config file

• Global.asax Application File


• IIS Architecture

• IIS Request Processing Models

With Lots of Luck 1

February 2011

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. With a labeled diagram, explain the ASP.NET Architecture


• ASP.NET Compilation system

• Components of ASP.NET Web pages

3. Describe the following Web Services:

A) Web Service Discovery – DISCO

B) Web Service Discovery – UDDI

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

With Lots of Luck 2

Assignment Set – 1 (answer - 1) A class is a construct that enables you to create your own custom types by grouping together variables of other types, methods and events. A class is like a blueprint. It defines the data and behavior of a type. If the class is not declared as static, client code can use it by creating objects or instances which are assigned to a variable. The variable remains in memory until all references to it go out of scope. At that time, the CLR marks it as eligible for garbage collection. If the class is declared as static, then only one copy exists in memory and client code can only access it through the class itself, not an instance variable. For more information, see Static Classes and Static Class Members (C# Programming Guide). Unlike structs, classes support inheritance, a fundamental characteristic of object-oriented programming. Declaring classes public class Customer { //Fields, properties, methods and events go here... } Creating object Customer object1 = new Customer(); Class Inheritance public class Manager : Employee { // Employee fields, properties, methods and events are inherited // New Manager fields, properties, methods and events go here... } EXAMPLE public class Person { // Field public string name; // Constructor public Person() { name = "unknown"; } // Method public void SetName(string newName) { name = newName; } } class TestPerson { static void Main() { Person person = new Person(); Console.WriteLine(person.name); person.SetName("John Smith"); Console.WriteLine(person.name); // Keep the console window open in debug mode.

With Lots of Luck 3

Console.WriteLine("Press any key to exit."); Console.ReadKey(); } } /* Output: unknown John Smith */

Assignment Set – 1 (answer - 2) The “Hello C#” Program: you can use any editor to code the program. It’s up to your convenience as to which editor to use. Listing 1 shows the coding for our “Hello C#” program: – Listing 1 – using System; class Hello { public static void Main() { Console.WriteLine("Hello C#"); } } After entering the above code in an editor, you have to perform the following steps Save the file as Hello.cs. cs is an extension to indicate C-Sharp like .java for a Java source file. You have to supply this extension while saving your file, otherwise the code will not compile correctly. The saved file will be of the extension .cs.txt. Compile the code by giving the following command at the command prompt: csc Hello.cs If there are compile errors you will be prompted accordingly. Otherwise, you will be viewing a command prompt along with the copyright information as shown in Figure 4. As a final step, you have to execute the program in order to view the final output. For that purpose, you have to simply give a command as shown below at the command prompt. See Figure 4. If everything goes on well, then you can be able to view the message “Hello C#” as shown in the figure above.

Assignment Set – 1 (answer – 3a) Web.config is the main settings and configuration file for an ASP.NET web application. The file is an XML document that defines configuration information regarding the web application. The web.config file contains

With Lots of Luck 4

information that control module loading, security configuration, session state configuration, and application language and compilation settings. Web.config files can also contain application specific items such as database connection strings. ASP.Net Applications of XML have been integrated into such an extent that XML format for the exchange of data, it's also used to store configuration settings. 1. A Web application can contain more than one Web.config file. The settings in a file apply to the directory in which it's located, and all child directories. Web.config files in child directories take precedence over the settings that are specified in parent directories. 2. Web.config files are protected by IIS, so clients cannot get to them. If you try to retrieve an existing http://?????.com/Web.config file, you'll be presented with an "Access denied" error message. 3. IIS monitors the Web.config files for changes and caches the contents for performance reasons. There's no need to restart the Web server after you modify a Web.config file.

Assignment Set – 1 (answer – 3b) The Global.asax file is an optional file used to declare and handle application and session-level events and objects for an ASP.NET web site running on an IIS Web Server. The file contains ASP.NET program code, and is the .NET counterpart of the Global.asa file used for ASP. The Global.asax file resides in the IIS virtual root of an ASP.NET application. At run time, upon the arrival of the first request, Global.asax is parsed and compiled into a dynamically generated .NET Framework class. ASP.NET is configured so that any direct request for the Global.asax is automatically rejected; external users cannot view or download the code in it. Code to handle application events (such as the start and end of an application) resides in Global.asax. Such event code cannot reside in the ASP.NET page or web service code itself, since during the start or end of the application, its code has not yet been loaded (or unloaded). Global.asax is also used to declare data that is available across different application requests or across different browser sessions. This process is known as application and session state management. The Global.asax file must reside in the IIS virtual root. A virtual root can be thought of as the container of a web application. Events and state specified in the global file are then applied to all resources housed within the web application. If, for example, Global.asax defines a state application variable, all .aspx files within the virtual root will be able to access the variable. The ASP.NET Global.asax file can coexist with the ASP Global.asa file. A Global.asax file is created in either a WYSIWYG designer or as a compiled class that is deployed in an application's \Bin directory as an assembly. However, in the latter case, the Global.asax file must refer to the assembly. Like an ASP.NET page, the Global.asax file is compiled upon the arrival of the first request for any resource in the application. The similarity continues when changes are made to the Global.asax file: ASP.NET automatically notices the changes, recompiles the file, and directs all new requests to the newest compilation.

Assignment Set – 1 (answer – 4a) IIS 6.0 provides a redesigned World Wide Web Publishing Service (WWW service) architecture that can help you achieve better performance, reliability, scalability, and security for your Web sites, whether they run on a single server running IIS or on multiple servers. IIS 6.0 runs a server in one of two distinct request processing models, called application isolation modes. Application isolation is the separation of applications by process boundaries that prevents one application or Web site from affecting another and reduces the time that you spend restarting services to correct problems related to applications. In IIS 6.0, application isolation is configured differently for each of the two IIS application isolation modes. Both modes rely on the HTTP protocol stack (also referred to as HTTP.sys) to receive Hypertext Transfer Protocol

With Lots of Luck 5

(HTTP) requests from the Internet and return responses. HTTP.sys resides in kernel mode, where operating system code, such as device drivers, runs. HTTP.sys listens for, and queues, HTTP requests. For more information about HTTP.sys, see HTTP Protocol Stack. The new request-processing architecture and application isolation environment enables individual Web applications, which always run in user mode, to function within a self-contained worker process. A worker process is user-mode code whose role is to process requests, such as returning a static page or invoking an Internet Server API (ISAPI) extension or filter. Worker processes use HTTP.sys to receive requests and send responses over HTTP. For more information about worker processes, see Worker Processes.

Figure: Architecture of IIS 5.0 Isolation Mode

Assignment Set – 1 (answer – 4b) Worker process isolation mode is the new IIS request processing model. In this application isolation mode, you can group Web applications into application pools, through which you can apply configuration settings to the worker processes that service those applications. An application pool corresponds to one request routing queue within HTTP.sys and one or more worker processes. Worker process isolation mode enables you to completely separate an application in its own process, with no dependence on a central process such as Inetinfo.exe to load and execute the application. All requests are handled by worker processes that are isolated from the Web server itself. Process boundaries separate each application pool so that when an application is routed to one application pool, applications in other application pools do not affect that application. By using application pools, you can run all application code in an isolated environment without incurring a performance penalty. For more information about application pools, see How Application Pools Work. For a visual representation of worker process isolation mode architecture, see Figure. Worker process isolation mode delivers all the benefits of the new IIS 6.0 architecture, including multiple application pools, health monitoring and recycling, increased security and performance, improved scalability, and processor affinity. For example, the new health monitoring features can help you discover and prevent application failures, and can also help protect your Web server from imperfect applications. IIS 5.0 isolation mode provides compatibility for applications that were designed to run in earlier versions of IIS. When IIS 6.0 is running in IIS 5.0 isolation mode, request processing is almost identical to the request processing in IIS 5.0. When a server is working in IIS 5.0 isolation mode, application pools, recycling, and health monitoring features are unavailable.

With Lots of Luck 6

For a visual representation of IIS 5.0 isolation mode architecture, see Figure 2.2. The dashed line in Figure 2.2 indicates the dependency of the worker process on the WWW service, which manages the worker process.

Use IIS 5.0 isolation mode only if components or applications do not function in worker process isolation mode. The latter mode is designed to provide an environment in which most existing applications or sites function correctly.

With Lots of Luck 7

Assignment Set – 2 (answer - 4) With IIS 6.0 running in worker process isolation mode, you can group Web applications into application pools. Application pools allow specific configuration settings to be applied to groups of applications, and the worker processes servicing those applications. Any Web directory or virtual directory can be assigned to an application pool. By creating new application pools and assigning Web sites and applications to them, you can make your server more efficient and reliable, and your other applications always available, even when the applications in the new application pool terminate. Procedures To create a new application pool 1. In IIS Manager, double-click the local computer, right-click Application Pools, point to New, and then click Application Pool. 2. In the Application pool ID box, type the name of the new application pool. 3. Under Application pool settings, click either Use default settings for new application pool or Use existing application pool as template. 4. If you selected Use existing application pool as template, from the Application pool name list box, click the application pool to be used as a template. 5. Click OK.

Assignment Set – 2 (answer – 3 A)

Understanding Web Services

Interconnectedness engendered by the World Wide Web has created a pressure to create applications that are

interoperable and distributable over the network. The direction of effort is towards creating applications that

connect to each other regardless of the language or platform in which the application was created.

Web services are externally exposed systems that allow applications to talk to each other and share information

over a network. The web service standards are built upon other standards such as HTTP or XML and are not

reliant upon any proprietary systems. The Web service is itself a collection of methods that can be called from a

remote location so that these methods accept and return parameters and provide for a wide variety of

functionalities that can be used internally in the application that is exposed to the public.

The concept behind web services is not new. The ad hoc methods of tying applications together have merely given

place to organized methods of communications between applications. Standardized specifications have also

lowered costs and shortened development timelines.

Prior to the emergence of Visual Studio.NET in the market a number of technologies attempted to cater to the

needs of the Web based world. Let us briefly look at the various technologies that tried to address these issues.

Discovery with DISCO

In the past, most consumers found out about new Web Services (and their endpoint addresses) by browsing the

Web, receiving an e-mail, or by word-of-mouth. Now, DISCO can define a document format along with an

interrogation algorithm, making it possible to discover the Web Services exposed on a given server. DISCO also

makes it possible to discover the capabilities of each Web Service (via documentation) and how to interact with it

(via WSDL). To publish a deployed Web Service using DISCO, you simply need to create a .disco file and place it

in the vroot along with the other service-related configuration files, like so:

With Lots of Luck 8

\inetpub

\wwwroot

\math (vroot)

math.asmx

web.config

math.disco

\bin

simpleMath.dll

complexMath.dll

The .disco document is an XML document that simply contains links to other resources that describe the Web

Service, much like an HTML file that contains human-readable documentation or a WSDL file containing the

interface contract. The following is a DISCO document skeleton that will serve as a starting point.

<disco:discovery

xmlns:disco="http://schemas.xmlsoap.org/disco/">



</disco:discovery>

Notice that the root element has the name discovery from the http://schemas.xmlsoap.org/disco/ namespace.

The references to other resources are placed within the discovery element:

<disco:discovery

xmlns:disco="http://schemas.xmlsoap.org/disco/"

xmlns:scl="http://schemas.xmlsoap.org/disco/scl/">



<disco:discoveryRef

ref="related-services/default.disco"/>



<scl:contractRef ref="math.asmx?wsdl"

docRef="math.asmx"/>

</disco:discovery>

The main element is contractRef, which belongs to a different namespace than the rest of the DISCO-related

elements. contractRef has two attributes, ref and docRef, which point to the WSDL and documentation files for a

given Web Service.

The discoveryRef element lets you link the given DISCO document to other DISCO documents. This linking

allows you to create a Web of related DISCO documents spanning multiple machines and even multiple

organizations. This is especially useful if the DISCO client utility provides a mechanism to traverse the links.

These are the only elements that you have to be concerned about in the DISCO namespace.

DISCO Redirects

Up to this point, all of the examples have required the client to specify the exact address of the .disco file on

the server. In most situations prospective clients won't know the exact address of the .disco file, so DISCO also

makes it possible to provide hints in the vroot's default page.

If the vroot's default page is an HTML document, you can use the LINK tag to redirect the client to the .disco

file:

With Lots of Luck 9

<HTML>

<HEAD>

<link type='text/xml'

rel='alternate'

href='math.disco'/>

</HEAD>

•••

</HTML>

If the vroot's default page is an XML document, you can use the xml-stylesheet processing instruction to

accomplish the same thing:

<?xml-stylesheet type="text/xml" alternate="yes"

href="math.disco"?>

With these redirects in place, clients can simply point the discovery tools to the vroot and they will be

automatically redirected to the specified .disco file.

.

Assignment Set – 2 (answer – 3 B)

Using UDDI

UDDI includes the shared operation of a business registry on theWeb. For themost part, programs

and programmers use the UDDI Business Registry to locate information about services and, in the

case of programmers, to prepare systems that are compatible with advertisedWeb services or to

describe their ownWeb services for others to call. The UDDI Business Registry can be used at a

business level to check whether a given partner has particularWeb service interfaces, to find

companies in a given industry with a given type of service, and to locate information about how a

partner or intended partner has exposed aWeb service in order to learn the technical details required

to interact with that service.

After reading this paper, the reader will have a clearer understanding of the capabilities defined in the

UDDI specifications and have a clearer understanding of the role ofWeb service registries that

implement these specifications.

UDDI- The technical discovery layer

The Universal Description, Discovery and Integration (UDDI) specification describes a conceptual cloud

ofWeb services and a programmatic interface that define a simple framework for describing any kind of

Web service. The specification consists of several related documents and an XML schema that

defines a SOAP-based programming prot ocol for registering and discoveringWeb services. These

With Lots of Luck 10

specifications were defined over a series of months by technicians and managers from several leading

companies. Together, these companies have undertaken the task of building the first implementation of the UDDI

services and running these services as a publicly accessible,multi-site partnership that

shares all registered information.

The following diagram shows the relationship between the specifications, the XML schema and the

UDDI business registry cloud that provides “register once, published everywhere” access to information

aboutWeb services.

Using the UDDI discovery services, businesses individually register information about theWeb services

that they expose for use by other businesses. This information can be added to the UDDI business

registry either via aWeb site or by using tools that make use of the programmatic service interfaces

described in the UDDI Programmer’s API Specification. The UDDI business registry is a logically

centralized, physically distributed service withmultiple root nodes that replicate data with each other on

a regular basis. Once a business registers with a single instance of the business registry service, the

data is automatically shared with other UDDI root nodes and becomes freely available to anyone who

needs to discover whatWeb services are exposed by a given business.

Assignment Set – 2 (answer – 2a)

The ASP.NET compilation architecture includes a number of features including:

# Multiple language support.

#Automatic compilation.

# Flexible deployment.

#Extensible build system.

Multiple language support.

In ASP.NET 2.0 you can use different languages such as Visual Basic and C# in the same application because

ASP.NET will create multiple assemblies, one for each language. For code stored in the App_Code folder, you can

specify a subfolder for each language.

Automatic compilation.

ASP.NET automatically compiles your application code and any dependent resources the first time a user requests

a resource from the Web site. In general, ASP.NET creates an assembly for each application directory (such as

App_Code) and one for the main directory. (If files in a directory are in different programming languages, then

separate assemblies will be created for each language.) You can specify which directories are compiled into single

assemblies in the Compilation section of the Web.config file.


Flexible deployment.

Because ASP.NET compiles your Web site on first user request, you can simply copy your application's source

code to the production Web server. However, ASP.NET also provides precompilation options that allow you to

compile your Web site before it has been deployed, or to compile it after it has been deployed but before a user

requests it. Precompilation has several advantages. It can improve the performance of your Web site on first

request because there will be no lag time while ASP.NET compiles the site. Precompiling can also help you find

errors that might otherwise be found only when a user requests a page. Finally, if you precompile the Web site

before you deploy it, you can deploy the assemblies instead of the source code.

You can precompile a Web site using the ASP.NET compiler tool (ASPNET_Compiler.exe). The tool that

provides the following precompilation options:

In-place compilation This option performs the same compilation that occurs during dynamic compilation. Use

this option to compile a Web site that has already been deployed to a production server.

Non-updateable full precompilation Use this to compile an application and then copy the compiled output to

the production server. All application code, markup, and UI code is compiled into assemblies. Placeholder files

such as .aspx pages still exist so that you can perform file-specific tasks such as configure permissions, but the

files contain no updateable code. In order to update any page or any code you must precompile the Web site again

and deploy it again.

Updateable precompilation This is similar to non-updateable full precompilation, except that UI elements such

as .aspx pages and .ascx controls retain all their markup, UI code, and inline code, if any. You can update code in

the file after it has been deployed; ASP.NET will detect changes to the file and recompile it. Note that code in a

code-behind file (.vb or .cs file) built into assemblies during precompilation, and you therefore cannot change it

without going through the precompilation and deployment steps again.

Extensible build system

ASP.NET uses BuildProvider classes to build items such as .aspx pages, .ascx files, and global resources. You can

extend and customize the ASP.NET build system to compile custom resources by creating classes that inherit from

the BuildProvider class. For example, you could add a new file type and then write a BuildProvider that builds that

particular type.

Assignment Set – 2 (answer – 2b)

ASP.NET Web pages as the programmable user interface for your Web application. An ASP.NET Web page

presents information to the user in any browser or client device and implements application logic using server-side

code. ASP.NET Web pages are:

# Based on Microsoft ASP.NET technology, in which code that runs on the server dynamically generates Web

page output to the browser or client device.

# Compatible with any browser or mobile device. An ASP.NET Web page automatically renders the correct

browser-compliant HTML for features such as styles, layout, and so on.

# Compatible with any language supported by the .NET common language runtime, such as Microsoft Visual

Basic and Microsoft Visual C#.

# Built on the Microsoft .NET Framework. This provides all the benefits of the framework, including a managed

environment, type safety, and inheritance.

# Flexible because you can add user-created and third party controls to them.

COMPONENTS OF ASP.NET Web pages

In ASP.NET Web pages, user interface programming is divided into two pieces: the visual component and the

logic. If you have worked with tools like Visual Basic and Visual C++ in the past, you will recognize this division

between the visible portion of a page and the code that interacts with it.


The visual element consists of a file containing static markup such as HTML or ASP.NET server controls or both.

The ASP.NET Web page works as a container for the static text and controls you want to display.

The logic for the ASP.NET Web page consists of code that you create to interact with the page. The code can

reside either in a script block in the page or in a separate class. If the code is in a separate class file, this file is

referred to as the code-behind file. The code in the code-behind file can be written in Visual Basic, C#, or any

other .NET Framework language. For more information about how ASP.NET Web pages are constructed, see

ASP.NET Web Page Code Model.

For ASP.NET Web site projects, you deploy Web page source code to a Web server and the pages are compiled

automatically the first time a user browses to any page in the site. (Optionally, you can also precompile the site so

that there is no compilation delay the first time a user browses a page.) For ASP.NET Web application projects,

you must compile the Web pages before deployment and deploy one or more assemblies.

Assignment Set – 2 (answer – 1)

Layered application designs are extremely popular because they increase application performance, scalability,

flexibility, code reuse, and have a myriad of other benefits that I could rattle off if I had all of the architectural

buzzwords memorized. In the classic three tier design, applications break down into three major areas of

functionality:

The data layer manages the physical storage and retrieval of data

The business layer maintains business rules and logic

The presentation layer houses the user interface and related presentation code.

Inside each of these tiers there may also exist a series of sub-layers that provide an even more granular break up

the functional areas of the application.

The Figure outlines a basic three tired architecture in ASP.NET along with some of the sub-tiers that you may

encounter:


The presentation tier

In the presentation layer, the code-behind mechanism for ASP.NET pages and user controls is a prominent

example of a layered design. The markup file defines the look and layout of the web form and the code behind file

contains the presentation logic. It's a clean separation because both the markup and the code-behind layers house

specific sets of functionality that benefit from being apart. Designers don't have to worry about messing up code to

make user interface changes, and developers don't have to worry about sifting through the user-interface to update

code.

The data tier

You also see sub-layers in the data tier with database systems. Tables define the physical storage of data in a

database, but stored procedures and views allow you to manipulate data as it goes into and out of those tables. Say,

for example, you need to denormalize a table and therefore have to change its physical storage structure. If you

access tables directly in the business layer, then you are forced to update your business tier to account for the

changes to the table. If you use a layer of stored procedures and views to access the data, then you can expose the

same logical structure by updating a view or stored procedure to account for the physical change without having to

touch any code in your business layer. When used appropriately, a layered design can lessen the overall impact of

changes to the application.

The business tier

And of course, this brings us to the topic of business objects and the Data Access Layer (also known as the DAL),

two sub-layers within the business tier. A business object is a component that encapsulates the data and business

processing logic for a particular business entity. It is not, however, a persistent storage mechanism. Since business

objects cannot store data indefinitely, the business tier relies on the data tier for long term data storage and

retrieval. Thus, your business tier contains logic for retrieving persistent data from the data-tier and placing it into

business objects and, conversely, logic that persists data from business objects into the data tier. This is called data

access logic.

Some developers choose to put the data access logic for their business objects directly in the business objects

themselves, tightly binding the two together. This may seem like a logical choice at first because from the business

object perspective it seems to keep everything nicely packaged. You will begin noticing problems, however, if you

ever need to support multiple databases, change databases, or even overhaul your current database significantly.

Let's say, for example, that your boss comes to you and says that you will be moving your application's database

from Oracle to SQL Server and that you have four months to do it. In the meantime, however, you have to

continue supporting whatever business logic changes come up. Your only real option is to make a complete copy

of the business object code so you can update the data access logic in it to support SQL Server. As business object

changes arise, you have to make those changes to both the SQL Server code base and the Oracle code base. Not

fun. The Figure depicts this scenario:

Documents

MC0081 – .(DOT) Net Technologies – 4 Credits