CodeToad - How Does ASP.NET Work?.

As with any new technology, there are certain fundamental elements that must be understood in order for developmental success. ASP.NET is no exception to this rule. One of the main problems I've noticed (and experienced first-hand!) in ASP developers who are in the process of switching to ASP.NET is with the sheer breadth of the programming paradigm. Remember, ASP scripts are little more than a vehicle for scripts to be executed on a web server. ASP.NET, on the other hand, presents nothing short of an entirely new programming model, with integrated state maintenance, security, inheritance, and so on. To become well versed as an ASP.NET programmer, you must take a look at all the aspects involved with the technology and develop a more holistic understanding of how all these pieces fit together.

What the .NET Framework Means to Distributed Architectures

From this brief introduction and all that you've probably already heard about the new features of ASP.NET, you've most likely already surmised that it will benefit your development efforts. This section will take a glance at what .NET means to the distributed world and provide a few theoretical arguments of how .NET will affect the process of enterprise development.

Fewer Development Hours

The time you spend developing web-based applications should decrease from the moment you adopt ASP.NET into your developmental regime. Gone are the days of developing custom solution after custom solution; ASP.NET exposes a new object-oriented approach to web development absent in any previous framework.

For starters, the IDE you'll (most likely) use – Microsoft Visual Studio.NET – for writing code is as integrated into the framework as the components you'll assemble within it. With an advanced, feature-rich debugger that can go from HTML through JScript functions to web services and the objects they reflect and back again, you'll be able to track the status of any process you can invent. The improved server explorer window, thread monitoring, and database tools provide literally every degree of control you could need, in one customizable interface.

The .NET Framework was designed to provide information technology professionals a model for development in which applications could be architected as a collection of reusable, independently functional components, accessible from any client. The .NET Framework itself is an extensible object model, so any application deployed into a .NET environment would contain many reusable objects and classes. This feature will provide a self-extending model for enterprise development when coupled with improved support for Internet standards for transmission protocols such as the Simple Object Access Protocol (SOAP), and industry-wide metadata description methodologies such as Universal Description, Discovery and Integration (UDDI). As any enterprise increases its massive collection of distributed applications, certain patterns of functionality – such as sending e-mail messages or saving MSMQ messages to domain queue servers – will be exposed for client-independent access. As a result, the need for these functions' duplication is removed, allowing more time to spend on new development projects (which will, in turn, be reusable and easily accessible from other applications later on, and so on).

Object-orientation and Abstraction

For traditional Visual Basic programmers, the new VB.NET language could conceivably stimulate some surprise. As support of the CTS was one of the largest motivators for language development, it was necessary to add all of the things that Visual Basic has lacked since its introduction. This introduction, though confusing at first, will conceivably earn Visual Basic programmers their object-oriented wings (and some well-deserved respect from our C++ and Java counterparts, who have cited this as the fundamental flaw in the language!).

With a more universal, language-agnostic methodology, developers will have an easier time working together. Once the framework itself is understood, the language barrier that has historically existed within development teams will crumble and the real fun of concentrating efforts on developing more abstract, reusable components will become the common methodology. With this paradigm shift stimulating the focus to application architecture, more stable, reusable, and cost-effective solutions can be deployed within any enterprise foundation.

Fewer Maintenance Complications

From a maintenance perspective, ASP.NET will most likely lessen the burden of administration. As an example, administrators will no longer face the complicated process of DLL registration and registry modification to enable application distribution via the Distributed Component Object Model (DCOM). .NET introduces the concept of remoting, which exposes application components on a network using widely accepted methodologies, such as XML over TCP and HTTP. A single developer using .NET's built-in support for XML and serialization and tools such as the command-line application WSDL.EXE to generate component proxies from an XML representation of their persistence model can expose virtually any component for any other application's usage.

Though these pages will produce HTML pages that contain more HTML code and thus require slightly more network traffic, the addition of output caching in ASP.NET will augment your application performance by allowing content to be stored in the web server's memory. In addition, because the framework – not IIS itself – will perform much of the needed functionality, your IIS resources will end up being better used for other areas. When you introduce IIS 6 and the other .NET servers Microsoft is busy developing, the zero administration concept becomes increasingly more possible.

Distribution via Web Services

When I speak to people about .NET or web services, it seems I always find myself stressing to them that ".NET is not web services and web services don't have to be written in .NET." It seems a common misconception that the two concepts are synonymous with one another. Though this isn't exactly accurate, there are reasons – both marketing related and technically justifiable – for the misconception that the two are interrelated technologies that can't exist without one another.

Web References

.NET is designed with a major focus on the web services methodology. Though many other software vendors have released Web Service toolkits (as Microsoft previously did with its own SOAP Toolkit for COM components), none come close to the support found in .NET, which is built using XML and SOAP as a central component for the framework's very core. The Visual Studio.NET IDE, for instance, contains a UDDI explorer that can be used to search for remote services. Once these services are located – no matter what their underlying architecture may be – you have the option of setting references to these remote components so that your new application can use their already existing functionality. These references, called "Web References", are pointers to remote XML Web Services on a network or the Internet, which are then rendered as usable namespaces in your local application.

Creating Web Services in .NET is Easy

Most importantly to the web service paradigm is the idea that components can easily and quickly be exposed to clients needing their functionality. In order to make things as easy as possible, ASP.NET Web Services can be written in their own file type, ASMX files. Let's take a look at how an existing code method can be modified so that it is exposed as a web service. Consider the following class, which illustrates a very simple function that adds two integers:

public class Calculator

{

public int Add(int X, int Y)

{

Return (X + Y);

}

Not very difficult, but it serves as a good example for demonstrating the simplicity of creating web services from existing component methods. ASMX files are regarded as ASP.NET Web Services, so we'll need to create an ASMX file that contains a single line of code. This line is a directive that simply indicates the language this service has been written in and contains a pointer to the class this service will expose:

<%@ WebService Language="C#" Codebehind="Calculator.cs" Class="Calculator" %>

The class already exists in an assembly, so the ASMX file needs only the ability to reference and utilize the class to expose it as a web service. The final step in this process is to modify the code so that the Add() method is properly exposed as a method accessible via a web service request. This can be done by simply appending the method to be exposed with the <WebMethod()> attribute (and we'll add a reference to the System.Web.Services namespace to suppress a warning message during compilation):

using System.Web.Services;

public class Calculator : System.Web.Services.WebService

{

[WebMethod] public int Add(int X, int Y)

{

return (X + Y);

}

That's it! Now that the component – or class, in .NET-speak – has been exposed with the help of an ASMX file that has a reference to it, all that's left to do is to compile the class, place it in the /bin directory, and then browse to the page itself. The .NET runtime presents you with an easy-to-use interface for the service. In this way, the service can be tested before its WSDL Service Description is referenced in other applications. The following screenshots demonstrate the default look and feel of a web service when it has been pulled up in a browser:

The first window provides you with information pertaining to the service itself, such as description attributes and namespace specific to the service itself. In addition to this information, a link to the web service's Service Description is displayed. By clicking this link, the WSDL definition appears in the browser:

If you pay close attention to the new address in the browser, you'll see that the URL is the same ASMX file as the description (the pretty face of ASMX files) with one added querystring variable, ?WSDL. By providing this URL as an argument for the command-line application called wsdl.exe, generic proxy classes are built that you can use in any other application that needs to reference the web service!