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
4. Discuss the following:
• IIS Architecture
• IIS Request Processing Models
 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

2. Discuss the following:

• 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 1

 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 2

 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 3

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 4

(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 5

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 6

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 7

\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/">
<!-- references go here -->
</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/">
<!-- reference to other DISCO document -->
<disco:discoveryRef
ref="related-services/default.disco"/>
<!-- reference to WSDL and documentation -->
<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 8

<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 9

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.

With Lots of Luck 10

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.

With Lots of Luck 11

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:

With Lots of Luck 12

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:

With Lots of Luck 13