Overview of ASP.NET
ASP.NET consists of several different technologies, including Web Forms, Web
Services, server controls, HTML controls, and validation controls, as shown
in Figure 6.1. All these technologies, working together, make it possible
(and some might even say "easy") to create robust, maintainable, scalable
Web applications. You'll use Web Forms to lay out the user interface of
your applications, using server controls as the basis for user interaction.
(If you're importing an existing HTML or ASP page, you might use the other
set of controls, HTML controls, which don't provide as rich an experience
for users, nor are they as easy to work with, programmatically, as server
controls. For new pages, you'll most likely want to use the new server
controls.) In addition, the set of validation controls (actually, just a
subset of the total set of server controls) makes it easy for you to
validate user input, either on the client side, on the server side, or
both. Web Services provide a platform for creating distributed
component-based applications, and ASP.NET makes it easy to create and
consume Web Services.
Figure 6.1. ASP.NET includes many different technologies.
You will be introduced to each of these different technologies in this
chapter, and you'll explore them in further detail in subsequent chapters.
Web Forms
Web Forms are the heart and soul of ASP.NET. Web Forms are the user
interface (UI) elements that give your Web application its look and feel.
Web Forms are similar to the .NET Framework's Windows Forms (or even VB6's
forms) in that they provide properties, methods, and events for the
controls that are placed on them. However, these UI elements render
themselves in the appropriate markup language required by the request (in
this case, HTML). If you use Visual Studio .NET, you also get the familiar
drag-and-drop interface for creating the interface for your Web application.
When you create Web applications using Visual Studio .NET, Web Forms are
made up of two files: the visual portion (the ASPX file) and the code
behind the page, which resides in a separate class file. (Microsoft refers
to this separate file containing code as the page's code-behind file. We're
not kidding.) If you create Web applications outside Visual Studio .NET
(yes, it's possible, although it's not terribly productive), you can place
the user interface and the code in the same file. The layout information
will still be separated from the code, but both parts can exist within the
same file.
Web Forms and ASP.NET were created to overcome some of the limitations of
ASP. The new strengths of ASP.NET include the following:
Separation of the HTML interface from application logic
A rich set of server-side controls that can detect the browser and send out
appropriate markup language, such as HTML
Data binding capabilities of the new server-side .NET controls, which means
less code to write
An event-based programming model that is familiar to Visual Basic pro-
grammers
Compiled code and support for multiple languages, as opposed to ASP, which
supported only interpreted VBScript or JScript
Allowing third parties to create controls that provide additional
functionality
XML Web Services
XML Web Services make up the second portion of ASP.NET's functionality.
Developers have, for several years, required some means of executing
methods across the Internet梩hat is, some way to programmatically request
information or an action and then retrieve the results. A Web Service is an
object that can be called remotely (normally using HTTP) that solves this
need.
ASP.NET makes it easy for you to create Web Services, and any application
that understands how to work with XML data can consume the service.
NOTE
When you use an XML Web Service, under the covers, ASP.NET is using the
Simple Object Access Protocol (SOAP) standard for its messaging protocol.
This standard indicates how a Web Service consumer should package up its
method requests, and it specifies how a Web Service should send back its
results. As long as both sides (service and consumer) follow the SOAP
specification, any Web Service should be able to interact with any Web
Service consumer.
These Web Services may be written in any .NET language, or any language
running on any platform, as long as the Web Services follow the SOAP
specification. Web Services can also be called from any .NET language or
any language that has the capability to process SOAP envelopes and call
HTTP interfaces.
A Web Service created in .NET always returns an XML string. When you use
the .NET Framework, you will not need to get your hands "dirty" handling
any of the XML manually; any return value you send back will automatically
be wrapped into an XML string for you. That is, the .NET Framework handles
all the details, packaging and unpackaging the XML necessary for the Web
Service to do its job. All you need to do is create the code that performs
the work, passing in parameters as necessary, and returning the correct
value. The .NET Framework will manage converting XML packets into your
parameters and converting the return value back into an XML string for the
Web Service consumer.
Figure 6.2 shows, in a simplified fashion, how a client application might
consume an XML Web Service. Things don't have to work this way, but if you
take all the default options in Visual Studio .NET, this is the path your
Web Service data will take.
Figure 6.2. A Web Service client receives and sends information to and from
the Web Service.
When you create a Web Service in .NET, you create a class that has public
methods. Each public method may be exposed as a method simply by you adding
a procedure attribute to the method as you create the procedure. (By adding
the <WebMethod()> attribute, you're telling the .NET Framework that it must
expose the procedure as a Web Service method.) The .NET compiler takes care
of creating the necessary files that allow another process to call this Web
Service across an HTTP interface. Figure 6.3 demonstrates, in a simplified
manner, how the translation occurs.
Figure 6.3. NET hides the SOAP implementation.
When you compile a Web Service created in .NET, it will automatically
generate a number of files for you. When a Web Service consumer application
(either created in .NET, or not) needs to determine information about the
Web Service and its available methods, it will use these files:
TIP
It's important to realize that nothing about XML Web Services requires any
Microsoft technology. In this book, we'll focus on creating and consuming
XML Web Services in the context of Microsoft's tools and servers, but none
of these is actually required. If you want to create a Web Service hosted
on a Linux server, using Apache, you're welcome to do so. If you want to
consume a Web Service using a Lotus Notes application, that works fine,
too. That's the beauty of embracing an existing standard. All we can say is
that it's a lot easier creating and consuming Web Services using Visual
Studio .NET than in any other tool we've seen.
.VSDISCO. A Visual Studio Discovery file. This file gives a list of Web
Services available on a particular Web site.
.WSDL. A Web Services Description Language file. This file describes the
method name(s) available for the selected Web Service. For each method,
there is also a list of parameters and a description of the return value.
