ASP.

NET Overview

Talk Agenda

Introduce .NET Introduce ASP.NET Comparison with ASP

Walkthrough of ASP.NET Making it easier to Build Apps Making it easier to Deploy Apps Making it easier to Operate Apps Scalability and Performance The CLR The Framework Class Library ASP.NET Web Forms Web Services Data Access WinForms

Framework

Enterprise Servers

Building Block Services

Compact Framework

.NET Framework

Common Language Runtime

Common Language Runtime

Multi-language runtime environment

Over 21 languages supported today

Managed Execution Environment

CPU Neutral Instruction Format Unified Type and Object System Industrial Strength Garbage Collector Secure Code Execution

Language/Hardware/OS Independent

Compact Framework for Small Devices

Common Language Runtime

Eliminates the complexities of COM:

GUIDs, CLSIDs, ProgIDs, HRESULTS CoCreateInstance, IUnknown, BSTRs QueryInterface, AddRef, Release Type Libraries, IDL, COM Threading Models All these are history.

Enables Clean OO programming

Classes and Interfaces Constructors, Properties, Methods, Events Cross language inheritance

Languages

The .NET Platform is Language Neutral

All .NET languages are first class players You can leverage your existing skills Consumer: Can use the .NET Framework Extender: Can extend the .NET Framework VB, C++, C#, JScript APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk

Common Language Specification

We are providing

Third-parties are building

.NET Framework

Web Applications

Windows Applications

Data & XML Libraries Base Class Libraries

Common Language Runtime

Framework

Single consistent set of object oriented class libraries to enable building distributed web applications
Built using classes arranged across logical hierarchical namespaces

For example: System.Data.SQL

Work with all CLR languages

Unify Programming Models

Consistent API availability regardless of language and programming model

.NET Framework
RAD, Composition, Delegation Subclassing, Power, Expressiveness Stateless, Code embedded in HTML pages

VB Forms

MFC/ATL

ASP

Windows API

Framework

System System.Collections System.Data System.Drawing System.Diagnostics System.DirectoryServices System.Globalization System.IO System.Messaging System.Net System.Threading

System.Text System.Reflection

System.Security
System.WinForms System.Web System.XML

ASP

The leading web app development platform

Nearly 1 million developers using ASP today

Simple and approachable model for web developers to get started

No compilers required just hit save Easy to use languages and object model

Well established developer support base

Good book/consulting/conference support

ASP, JSP, PHP, etc.

Way too much code required

Simple tasks often not easy Poor re-use/encapsulation model

Applications contain spaghetti code

Intermixed html/code Messy include files for re-use Hacky page activation techniques
Latebound scripting only JSP Java only

Limited language support

ASP, JSP, PHP, etc.

Weak tools

Poor layout, debuggers, profilers, etc Doesnt work well for Internet apps COM components a nightmare Metabase configuration options confusing No web farm or caching infrastructure

Confusing security architecture

Poor deployment

Scalability challenges

Introducing ASP.NET

ASP.NET is a revolutionary advance of ASP

Your existing ASP skills still work fine But lots more features to leverage

Core themes that ASP.NET has focused on:

Making it easier to build web apps Making it easier to deploy web apps Making it easier to operate web apps Providing great performance and scalability Windows NT 4 / IIS 4, Windows 2000 / IIS 5, ++ Open hosting APIs

Supported platforms

ASP.NET Pages (1 of 2)

Makes it dramatically easier to build dynamic web pages Simplify common tasks done today

Validation, Data Manipulation, PostBack, State

Enable better support for different clients

Enable better uplevel/downlevel scenarios Enable rich support for small devices

Enable cleaner code organization

Code no longer has to be mixed with HTML Developers/designers can work independently

ASP.NET Pages (2 of 2)

Declarative server-side UI control model:

<asp:datagrid id=List1 backcolor=red runat=server>

Great way to encapsulate functionality Zero coding required for common scenarios Can automatically Render HTML to client

Rich extensibility model for 3rd party innovations

Extend from our server controls Replace features, e.g. SessionState

ASP.NET Web Services

ASP.NET makes it dramatically easier to expose programmatic services on the web Simple Programming Model to Understand

Author .ASMX Files with Class Methods Incoming Http Messages mapped to methods No special HTTP or XML knowledge required

Supports Multiple Message Wire Formats

SOAP messaging support Http Get/Post Requests that return XML Payloads Extensible model for innovation

ASP.NET Application Features (Highlights)

Caching Support

ASP.NET provides built-in caching support that enables re-use of work Cache Engine: Extensible Cache API

Enables arbitrary objects to be cached Vary by params, language, user-agent Enables portions of pages to be cached

Full Page Caching

Partial Page Caching

Web Service Caching

Vary by parameters and methods

Deployment

ASP.NET enables a web app to be deployed simply by copying its bits to the server

\bin directory registration

No-nonsense architecture

No local server access required No web server restarts required

Web Pages/ Web Services Compiled Components Configuration Metadata

Works for all web app resources

Configuration

XML configuration file: config.web

Human readable format Edit via notepad or XML based tools

Hierarchical config.web files can be used to apply settings to a web application

Only 1 per directory

No reboots Easily replicated: FTP, DAV, etc.

Improved Reliability

ASP.NET has been designed with assumption that failures will occur on systems

Designing for failure reduced fragility

ASP.NET detects and recovers from problems

Access Violations, Memory Leaks, Deadlocks

ASP.NET supports pre-emptive cycling of apps

Time and Request Based Settings

Net Result: Users should never think that an ASP.NET application is down or unavailable

Web Farm Session State

Session State can now be external from ASP.NET Worker Process

ASPState NT Service SQL Server 7.0

Big reliability wins

Session state survives crashes/restarts

Enables Web farm deployment

Session State can now be shared across a web farm of ASP.NET Servers Applications no longer tied to one machine

Http Runtime

Goal: Factored Low-Level Design

Replacement for ISAPI Extension and Filters

Provide customers with the ability to replace/customize/extend the core product

Eliminate black box magic with ASP/IIS Support other programming abstractions

Run on top of multiple host environments

IIS5, IIS4, IE

ASP.NET HTTP Runtime

HTTP Handler
Application

*.asmx

*.aspx

HTTP Module HTTP Module Global.asax ASP.NET HTTP Runtime Host (IIS 5, IIS 4, IIS 6, cmd.exe)
Native code Managed code

Http Context

Summary

Customer reaction has been fantastic

More than 100,000 downloads already Visit http://www.asp.net to learn more A Preview of ASP+ from Wrox Press

ASP.NET provides a quantum leap in power

Tons of new features/infrastructure

ASP.NET will make building web apps easier

Much less plumbing code required Enable developers to focus on customers

Agenda

The CLR The Framework Class Library ASP.NET Web Forms Web Services Data Access WinForms

What is .NET Three main elements:

The Framework (CLR, FCL, ASP, WinForms) The Products (Windows, Visual Studio, Office) The Services (My Services) Development began in 1998. Framework Goals: Improved reliability and integrated security. Simplified development and deployment. Unified API, multi-language support. New version of COM? XML is the .NET Meta-Language. All MS server products eventually .NET-enabled.

The .NET Framework

ASP.NET
Web Services Web Forms

Windows Forms
Controls Drawing

ASP.NET Application Services

Windows Application Services

Framework Class Library

ADO.NET Network XML Security Threading Diagnostics IO Etc.

Common Language Runtime

Memory Management Common Type System Lifecycle Monitoring

The .NET Framework

Beta 1 released Oct, 2000. Beta 2 released July, 2001. Finalized in Dec, shipping in Feb 2002. SDK and Visual Studio.NET (includes SDK) run on Windows NT 4.0, 2000, and XP. Redistribution Pack (runtime) runs on Windows 98, NT 4.0, 2000, ME, and XP. Framework will ship with Windows .NET Server (mid-2002) and beyond.

The New Languages - C# and VB.NET

Performance differences very minor. VB.NET introduces long sought-after features: Inheritance Parameterized Class Constructors Function Overloading Multi-Threading Structured Error Handling Creating NT Services VB.NET not backward compatible with VB6. VB6 will be supported until the third release of VB.NET (5-6 years away). C# New modern, object-oriented language Similar to C++/Java High-Fidelity language of .NET

What About Java?

Microsoft is developing JUMP (Java User Migration Path to .NET). A set of conversion tools. Late-Breaking News: Visual Studio.NET will include a Java component called Visual Java.NET (or maybe Visual J# .NET).

.NET vs. J2EE

Both are similar in many ways: Server- and client-side model for building enterprise applications. Virtual machine designed to inspect, load, and execute programs in a controlled environment. APIs for creating both fat- and thin-client models. APIs for foundation services (data access, directory, remote object calls, sockets, forms). Development environment for dynamic web pages. J2EE: Language-Dependent & PlatformIndependent. .NET: Language-Independent & Platform Dependent.

J2EE: Language-Specific, PlatformIndependent

Person.java

Linux
Java VM

Person bytecodes

Java VM
Deploy
Company bytecodes

Windows
Java VM

Address bytecodes

Solaris
Address.java Company.java Java VM

.NET: Language-Independent, Platform- Specific

Person.vb (Visual Basic)

Windows
CLR

Person MSIL

CLR
Deploy
Company MSIL

Windows
CLR

Address MSIL

Windows
Address.cs (C#) Company.cbl CLR

(Cobol)

J2EE

The core (JVM and standard class libraries) are mature. 2 million Java programmers. J2EE implementations are not entirely cross-platform. Javas true potential is realized only when all (or most) development is done in Java. Changing the Java language specification has an enormous impact on the entire platform.

.NET

Being newer, .NET adds improvements such as native XML support. 6 million VB developers. All development and deployment is Windows.

The CLR

What is the CLR

The CLR is at the core of the .NET platform - the execution engine. A Managed Execution Environment. Manages the execution of code and provides services that make development easier. Code developed for a compiler that targets this platform is referred to as Managed Code. Code that relies on COM and the Win32 API is UnManaged Code. VB6 is 100% Un-Managed, VB.NET is 100% Managed.

Key Features and Benefits

Cross-Language Integration Cross-Language Inheritance Cross-Language Exception Handling Enhanced Security Versioning and Deployment Support Debugging and Profiling Services Automatic Memory Allocation and Management A Common Type System Object Lifecycle Monitoring and Garbage Collection

Key Features and Benefits

Key objective is to handle much of the programming infrastructure, such as memory management and object proxies. Much is replaced by metadata. Memory management is self-configuring and selftuning. Many common bugs should be eliminated (such as memory leaks). Tool support - designed to work well with designers, wizards, debuggers, etc. CLR replaces the existing runtime layers of COM, MTS, COM+.

Key Features and Benefits

Language interoperability is built into the Framework by means of a Common Type system. There is a CLR-to-COM interoperability layer. Better debuggers - can jump between source across different languages. Simplified deployment - no more DLL Hell. CLR supports side-by-side execution - the ability to load and execute multiple versions of the same assembly.

Key Features and Benefits

COM provides a way for components to integrate. However, each component must provide the plumbing and objects cannot directly interact.

Key Features and Benefits

CLR

With the .NET CLR, components are built on a common substrate. No plumbing is needed and objects can directly interact.

Application Types

The CLR supports the following types of applications:

Console Windows Forms Web Forms Web Services Service Control Manager Services (NT Services) Tools and Utilities Components

The Common Language Specification

CLR works with multiple languages - including those developed by third parties (approx. 22). Each language compiler may support different subsets of the runtimes functionality. The Common Language Specification (CLS) defines the requirements for a .NET component to be completely usable by other .NET applications. The CLS spec. defines a subset of the CLR types and features. The Framework Class Library (FCL) itself is fully-compliant with the CLS. VB.NET is fully CLS compliant. C# is not - you can create C# components that expose types not usable by VB.NET. There is a compiler directive to force CLS-compliance.

MSIL and JIT Compilation

Source code is compiled into MSIL (Microsoft Intermediate Language). Similar to Java bytecodes - CPU-independent instructions. MSIL allows for runtime type-safety and security, as well as portable execution platforms (all Windows). MSIL code cannot play tricks with pointers or illegal type conversions. The MSIL architecture results in apps that run in one address space - thus much less OS overhead. Compilers also produce metadata: Definitions of each type in your code. Signatures of each types members. Members that your code references. Other runtime data for the CLR.

MSIL and JIT Compilation

Metadata in the load file along with the MSIL enables code to be selfdescribing - no need for separate type libraries, IDL, or registry entries. When code is executed by the CLR, a JIT compilation step occurs. Code is compiled method-by-method to native machine code.

Garbage Collection

COM manages object lifetimes through reference counting. Circular references were a big problem. CLR manages objects through a process of garbage collection. CLR will detect and break down circular references. COM has deterministic finalization - you know that when you release the last reference to an object, that object goes away, and can code accordingly. CLR has non-deterministic finalization.

Metadata

Metadata is generated by the compiler and stored in the executable (EXE or DLL). Similar to a COM type library - contains information that describes the components public types (enums, structures, interfaces, and classes). IDL no longer used. No need to define an interface to program against a class. Interface-based programming still alive and well in .NET. Metadata includes: Assembly - name, version, culture, public key, exported types, security permissions. Base classes and interfaces.

Packaging: Modules, Types, Assemblies, and the Manifest

A module refers to a managed binary, such as an EXE or DLL. Modules contain definitions of managed types, such as classes, interfaces, structures, and enumerations. An assembly can be defined as one or more modules that make up a unit of functionality. Assemblies also can contain other files that make up an application, such as bitmaps and resource files. An assembly is not a physical file. An assembly is the the fundamental unit of deployment, version control, activation scoping, and security permissions.

Packaging: Modules, Types, Assemblies, and the Manifest

An assembly is a set of boundaries: A security boundary - the unit to which permissions are requested and granted. A type boundary - the scope of an assembly uniquely qualifies the types contained within. A reference scope boundary - specifies the types that are exposed outside the assembly. A version boundary - all types in an assembly are versioned together as a unit.

Packaging: Modules, Types, Assemblies, and the Manifest

An assembly contains a manifest, which is a catalog of component metadata containing: Assembly name. Version (major, minor, revision, build). Assembly file list - all files contained in the assembly. Type references - mapping the managed types included in the assembly with the files that contain them. Scope - private or shared. Referenced assemblies. In many cases, an assembly consists of a single EXE or DLL containing the modules MSIL, the component metadata, and the assembly manifest. In other cases, the assembly may consist of many DLLs, with the manifest in its own file. No MSIL code can ever be executed unless there is a manifest associated with it.

Packaging: Modules, Types, Assemblies, and the Manifest

Two types of assemblies: Private - Usually deployed in the same directory as the client application and used only by a single application. Shared - Used by any application and usually installed in a special Global Assembly Cache. Version information from a dependent assembly is recorded in a client manifest.

Packaging: Modules, Types, Assemblies, and the Manifest

Assembly Manifest Module Metadata MSIL Type Type Type

The Common Type System

At the core of the Framework is a universal type system called the .NET Common Type System (CTS). Everything is an object - but efficient. It is this CTS that make cross-language inheritance possible. All types fall into two categories - Value types and Reference types. Value types contain actual data (cannot be null). Stored on the stack. Always initialized. Three kinds of value types: Primitives, structures, and enumerations. Language compilers map keywords to the primitive types. For example, a C# long is mapped to System.Int32.

The Common Type System

Reference types are type-safe object pointers. Allocated in the managed heap. Four kinds of reference types: Classes, arrays, delegates, and interfaces. When instances of value types go out of scope, they are instantly destroyed and memory is reclaimed. When instances of reference types go out of scope, they are garbage collected. Boxing = converting an instance of a value type to a reference type. Usually done implicitly through parameter passing or variable assignments. UnBoxing = casting a reference type back into a value type variable.

The Common Type System

Object

String

Array

ValueType

Exception
Enum

Delegate
Multicast Delegate

Class1
Class2 Class3

Int16
Int32 Int64 Single Double Decimal

Boolean
Byte Char Currency DateTime TimeSpan

Primitive Types

Attributes

Attributes in the CLR allow you to add additional information to the classes you create. This information is read by using the System.Reflection classes defined in the Framework Class Library. One particular example of using attributes is the [WebMethod] attribute used to expose a Web Service method.

Error Handling

Error handling in the CLR is structured and consistent. Uses the TryCatchFinally pattern. Throw enables you to raise an exception.

Delegates

A new concept that is central to the programming model of the CLR. Delegates are like function pointers, but are actually type-safe, secure, managed CLR objects. The CLR guarantees that a delegate points to a valid method. You get the benefits of function pointers without the dangers. Each delegate is based on a single method signature. Commonly used for callbacks. Delegates are basis of event handlers.

Deployment

The CLR does not require registry entries for assemblies or managed types. Assemblies can be deployed using the Windows Installer, Internet Explorer, or XCOPY. Apps can be run from a CD with no installation at all. Side-by-side deployment means you can create new versions of an assembly without having to maintain backwards compatibility with previous versions. Both versions of the same assembly can run together (in the same address space on the same machine) - supporting both old and new clients.

The Bigger Picture?

The CLS and CTS are actually a part of a bigger specification called the CLI (Common Language Infrastructure). The CLI and C# have been submitted to the ECMA for standardization. MSIL and the CLR are simply Microsoft implementations of the CLI for Windows. Open-Source organizations are developing .NET ports for other operating systems. MS is helping Corel with a .NET port to FreeBSD. The Free Software Foundation and Ximian are working on a .NET port to Linux.

The Framework Class Library

What is the Framework Class Library

The FCL is a hierarchical class library that can be utilized across multiple languages (CLS) and platforms (Windows). Enables consistent programmatic access to the .NET runtime environment. Integrates the functionality from existing COM and other runtime libraries. Windows API, Data Access, XML, etc. all accessible in a consistent, simplified, unified way.

What is the Framework Class Library

Contains thousands of reusable classes, interfaces, and components that can be used for: Accessing the file system, text files, and databases. Working with XML. Developing components and Web Services. Managing application configurations. Working with Directory Services, Event Logs, Processes, Message Queues, and Timers. Handling images and strings. Creating and managing threads. Accessing assembly metadata and managing the CLR. Developing Windows Forms applications. Developing Web Forms applications. Managing application security.

Key Features and Benefits

Cross-Language Interoperability Consistent and Unified Programming Model Object-Oriented and Extensible Class Library

Namespaces

A Namespace is a user-defined scope in which managed types are defined. The FCL is organized into 98 namespaces. FCL namespaces are organized in a hierarchy. The System namespace is at the topmost level, and almost all other namespaces are subordinate.

COM InterOp

Classic COM components can be used in a .NET application, and vice-versa. ASP.NET and VB.NET still support CreateObject(). C# can call COM servers via the InteropServices and Reflection routines. Interop layer automatically converts errors (HRESULTS) into ComException exceptions. The Type Library Importer utility takes a standard COM type library and creates an assembly containing the equivalent .NET metadata. The resulting DLL is essentially a manangedcode face on the COM component. Best practice is to recompile the components.

ASP.NET

Key Features and Benefits

Better Performance. Script code replaced by the .NET languages. Code is JIT compiled (or pre-compiled). Early binding, strong typing, better error handling. Better Programming Models. ASP.NET part of the FCL. All ASP code consists of subclassed framework classes. Less Coding. Control state is built-in. More data-bound controls. Easier to use Components. DLLs can be replaced in the procedure cache without stopping the site. No more COM/MTS registration issues. Extensive Caching Features.

Configuration

All configuration is done via an XML file Web.config. Web.config files are stored in the same virtual directory tree as the rest of the application files. Can be changed on the fly, or redeployed using XCOPY, without stopping the site. A Web.config can exist for each application. Config files inherit settings from parent config files. Additional sections and elements can be added for application-specific settings.

Global.asax

Replaces (and is completely compatible with) the Global.asa file. Provides for application-wide event handlers and other global logic for the web application. Applies to both the Web Forms and Web Services programming models. Can contain the following: Application Directives. Code Declaration Blocks. Server-side Object Tags. Server-side Include Directives.

Session State Management

All session state is (by default) stored externally from the worker processes in dedicated .NET State Server processes running as separate NT processes. No end-user code, and no live object references reside in these processes. This process isolation improves ASP.NETs reliability. State Server can be a separate machine available to all web servers in a web farm. Session Id strings are 120-bit keys. Passed between page requests via either an HTTP cookie or a munged URL. State Blobs can be stored in SQL Server database.

Web Forms

What are Web Forms

Web Forms are a new control-based, event-driven execution model for web user interfaces. Features a drag-and-drop designer (Visual Studio 7), more cleanly-encapsulated functionality, and less coding compared to ASP. Web Forms are pages with .aspx extensions and processed by XSPIAPI.DLL. ASP pages still processed by ASP.DLL. Thus old and new ASP apps can run side-by-side in IIS. An ASP.NET page is a class. Inherits from System.Web.UI.Page. Constructed and compiled on first reference, then stored in the procedure cache.

Key Features and Benefits

Stronger separation of content (HTML) and code. Designed to work on any browser. Easier debugging with a trace facility. Page state management handled for you. Event-based programming model is cleaner to code. Coding can be done in any CLR language. Much better performance than ASP.

Coding Structure

Directives appear at the start of the .aspx file. Code Declaration Blocks are blocks of code contained in special <SCRIPT> tags. Code Rendering Blocks are code delimited by the familiar <%%> tags. Code in declaration blocks can alternatively be placed in an external source file, using the Inherits and Src directives. This is called code-behind. External page code can be pre-compiled. Omit the Src directive and place the DLL in the \bin directory.

Event-Based Programming Model

Existing ASP code has little structure. ASP.NET uses an event-based model. Events are defined for the Page class, which you provide code for. Various events are fired, on the server, by the controls. A post-back occurs as a result of a UI event, such as a button click. The state of the pages controls are maintained automatically via a hidden form field.

Page Lifecycle

ASP.NET Web Form pages go through a series of processing stages at which points you can connect event-handler code. Some commonly-used phases: Configuration (Page_Load). Page and control view state are restored (or initialized). You can check the IsPostBack property. Event Handling. Many controls will trigger a postback and their corresponding events are fired. Other controls may not trigger the postback, but their relevant events still fire on the server when the postback occurs. Cleanup (Page_UnLoad). The page has finished rendering.

Server Controls

Server controls are HTML elements contained in a FORM that remember their state between page requests, and generate events which are processed on the server. In some cases, they use new tag names that are recognized by ASP.NET but are substituted with standard HTML tags for the browser. For example, <asp:ListBox> is substituted with <SELECT>. Fall into two broad categories: HTML Controls and Web Controls.

HTML Controls

Defined in the System.Web.UI.HtmlControls namespace. Server-side references to some of the most commonly-used standard HTML elements. Object model for these controls maps very closely to the corresponding HTML element. Declared using the standard HTML tags, but with the addition of the runat=server attribute. Example: <BUTTON OnServerClick=Button_Click RunAt=Server>

Web Controls

Defined in the System.Web.UI.WebControls namespace. These are enhanced server-side controls, and do not necessarily map one-to-one with HTML elements Declared using XML tags such as <asp:Button>. Are rendered to the browser based on the browsers capabilities and other factors. For example, the <asp:Button> control may render as an <INPUT type=submit> or as a <BUTTON>. Can be grouped into five categories: Intrinsic controls, such as the ASP:RadioButton. Rich controls, such as the ASP:Calendar. List controls, such as ASP:DataGrid. Validation controls, such as ASP:RangeValidator. Mobile controls for encapsulating WML for WAP requests (post beta 1).

Validation Controls

Used to validate the contents of other controls. Rendered as client-side script if the browser supports it, else server-side. Server-side validation can be forced by setting the EnableClientScript property to false. Validation controls are: ASP:RequiredFieldValidator ASP:RangeValidator ASP:CompareValidator ASP:RegularExpressionValidator ASP:CustomValidator ASP:ValidationSummary

User Controls

User Controls are formed by encapsulating other ASP.NET server controls into a composite control. Great way of extending ASP.NET, promoting reuse of server-side code, and is more object-oriented than using include files. Controls created in this fashion are identified by a namespace, avoiding name collisions.

Web Services

What are Web Services

Software as a Service. Internet communication is abstracted. Programmable components that provide business logic to web or desktop applications using XML for message formatting and the standard Internet protocols (HTTP, SSL, etc.) for communications (SOAP). Not a new concept - and .NET is not required to build SOAP servers or clients. The MS vision is simply that .NET becomes the easiest way (thus most popular). MS doesnt own the standards. Part of the .NET initiative is My Services (formerly known as Hailstorm), which are a set of Microsoft .NET Foundation Web Services. The first example of this is Passport. Another good example is Microsofts TerraServer.

Why Use Web Services

No physical distribution of software. Less cost, easier maintenance. Easier to implement than DCOM, Suns RMI, CORBA. Web Services do not rely on any proprietary standards or platform. Designed with a loose-coupling between the service provider and the service consumer. One can run without the other. XML is the defacto standard for data interoperability.

Web Service Wire Formats

Web Services use the standard Internet communication protocols. This enables basic communication between providers and consumers, regardless of platform. This is SOAP (Simple Object Access Protocol). SOAP is a messaging protocol that uses XML for formatting service requests and replies. SOAP defines an envelope formatting and processing mechanism for complex message structures and allows for loose coupling.

Web Service Description

A Web Service Description defines all the supported methods that a Web Service provides. This is WSDL (Web Service Description Language). WSDL is an XML grammar that developers and development tools use to represent the capabilities and syntax of a Web Service. The .NET Framework has utilities for dealing with WSDL, such as Wsdl.exe.

Web Service Discovery

This is the aspect of making the presence and capabilities of a Web Service known to the world. This is the UDDI (Universal Discovery, Description, and Integration) business registry service. Initiated by Ariba, IBM, and Microsoft. Supported by more than 130 companies. Provides a standard place to register Web Services. Check out www.uddi.org. UDDI is a specification built on SOAP/XML and defines a document format and protocol for searching and retrieving discovery documents - which in turn link to DISCO documents. DISCO (Discovery of Web Services) is a Microsoft protocol for retrieving the contracts for Web Services (WDSL documents).

Building a Web Service

Incredibly easy using the .NET Framework. Start by opening a new Visual Studio Web Service project, or simply code from scratch in Notepad. Like Web Forms, Web Services are part of ASP.NET. You create your Web Service as an .asmx file with the following directive: <%@ WebService Language=C# Class=MyClass %> Code can be in any .NET language. Code can be in the .asmx file or in a separate module. Your class always inherits from System.Web.Services.WebService. To expose a method, you use the [WebMethod] attribute and make the method public.

Calling a Web Service via HTTP Get

By requesting a Web Service URL from the IE Address field, ASP.NET will respond with a neatly-formatted page that describes the Web Service and its methods. This page even provides a simple means to run the methods. This is not UDDI or DISCO. Just a nicely-formatted page built from the metadata. You can get the WSDL by appending ?wsdl to the URL. To call a method, append the method name and parameters to the URL like this: /MethodName?Parm=Value&NextParm=NextValue Calling the service in this manner will result in a simple XML response containing the return value.

Calling a Web Service via HTTP Post

The WSDL describes the requirements for doing this. The Web Service expects that the incoming parameter values be contained in FORM fields with specific names. Therefore, your FORM has to contain INPUT elements named according to the WSDL. The ACTION attribute names the method: <FORM Method=Post Action=StockTicker.asmx/GetStockPrice> The response is an XML string.

Calling a Web Service via SOAP

Using SOAP is the most comprehensive manner to invoke a Web Service, but can be complicated. Fortunately, the .NET Framework provides utilities to make this easier. You build a proxy class which is a mirror image of the Web Service. It is run locally on your system, and appears to your application as the Web Service. The proxy handles the SOAP communications with the actual Web Service. You generate the proxy class using the Web Services Description Language tool (wsdl.exe). Note that Visual Studio will do this for you simply by adding a Web Reference to your project.

Data Access

ADO.NET

ADO.NET is the primary library for building database solutions within the .NET Framework. ADO.NET does not replace ADO. ADO and OLEDB are still the preferred means for building COM applications. ADO.NET specifically designed to build highly-scalable applications using a 3-tiered, connectionless model. Better support for offline applications. Most of the time in ADO.NET you are working with objects that have no active database connection. ADO.NET is based on XML.

ADO.NET

The ADO.NET objects are implemented in the following namespaces: System.Data - Base ADO.NET objects and types. System.Data.Common - Classes shared by the .NET data providers. System.Data.OleDb - OLEDB .NET data provider. System.Data.SqlClient - SQL Server .NET data provider. System.Data.SqlTypes - Native SQL Server data types. System.Data.OleDb and System.Data.SqlClient contain roughly the same classes. System.Data.OleDb is for using OLEDB data sources, like ADO is used for now. System.Data.SqlClient is specifically for SQL Server, and is highly optimized for performance.

ADO.NET Architecture
.NET Data Provider
Connection Transaction Command Parameters SelectCommand InsertCommand UpdateCommand DeleteCommand DataColumnCollection ConstraintCollection DataAdapter

DataSet
DataTableCollection
DataTable DataRowCollection

DataReader

DataRelationCollection

Database

XML

OleDbConnection / SqlConnection

These classes represent an open connection to a data source. Provide the same service as the ADO Connection object. Feature the familiar properties (ConnectionString, etc.) and methods (Open, BeginTransaction, Close, etc.).

OleDbCommand / SqlCommand

These classes represent a query command to be made against a data source. Mirrors the ADO Command object with one very big difference: Data that is returned from SELECT statements is obtained via an OleDbDataReader or SqlDataReader, which is always a forward-only, read-only stream.

OleDbDataReader / SqlDataReader

Uses streaming methods, such as Read() to fetch data rows. Very fast, efficient object for read-only scenarios.

OleDbDataAdapter / SqlDataAdapter

Represent a set of data commands and a database connection which are used to fill a DataSet and update the corresponding database. These objects are used for stateless batch update scenarios. Select, Insert, Update, and Delete commands are grouped together in one composite object. Used to interface a database with a DataSet object.

The DataSet

The ADO.NET DataSet object can be described as an inmemory database. A DataSet object can contain a hierarchy of objects that represent tables, relationships, columns, rows, and constraints. It is not tied to any database product. The child objects can be manipulated in many ways. Not only can the data be updated, but additional child objects (tables, relationships, rows, etc.) can be created. The DataSet has been designed as the connectionless workhorse for the framework, servicing the need to bridge the Business Logic and Data Access layers in a multi-tiered implementation.

WinForms

What are WinForms

The new way to produce standard Windows desktop applications. Based on the Windows Foundation Class (WFC) produced for Visual J++. All WinForm applications that you create are done by subclassing the .NET base classes. Can be written in any .NET language. Visual Studio 7 supplies designers for RAD. Merges the drag-and-drop RAD spirit of VB with the inheritance/reuse/power of MFC.

Key Features and Benefits

Like any other .NET application, WinForm applications can be deployed with a simple XCOPY. No registration of controls, etc. Full integration with the .NET Framework. You have all the features of the FCL available for your desktop applications, including Web Services. Visual Inheritance. WinForms are .NET classes. Like any other CLR managed type, your classes can inherit from other classes. Can still use ActiveX controls.

The Framework

WinForms begin at the System.WinForms namespace. This namespace contains the Form class and many controls that can be added to forms to create user interfaces. System.WinForms contains the Application class, with a static method called Run. This displays a form and provides the message pump. The Form class is the base class for all forms you create.