Developing Web-Applications with ASP.NET
WebForms and XML Web Services Alex Thissen
Agenda
• Creating Web Forms
– Web Forms and Server controls – Code behind – Session state – Security – Consuming Web Services – Creating Web Services
• Web Services
WebApplications
• Thin client front-end to server application • Web pages behave like forms:
– One page handles all interaction from client – Stateful controls (no reset pages)
• The Challenges:
– Internet is disconnected environment: no lasting connection to server – Internet and security – Large and diverse browser audience
WebForms
• In essence a self-posting page, able to
handle events on client in server-side code • Framework provides an object model • Contains both client and server-side code • Uses Web Controls
WebForm client-server interaction
Browser
on first request HTML is sent
IIS Web Server
file.aspx
server round trips: client-side events trigger server-side event handlers
server control
ASP.NET programming model
• WebForms as the basis of WebApplication • System.Web.UI.Page is base class for
WebForms
• All of the original objects still available as
part of Page object (though enhanced)
– Session, Application, Request, Response, Server
Server controls
• Server-side representations of client-side controls • Server controls are also browser-specific HTML
generators (behavior and rendering) • Distinguishable by attributes id=“…” and runat=“server” • Two main categories:
• Create your own user controls
– HTML Controls – Web Controls: Intrinsic, Validation, Rich and List-bound
Compiled code
• Increased performance through compilation of
code • All .aspx pages are compiled into separate assemblies stored in temporary directories • Shadow copies are made to prevent locking of dll’s • Framework registers File Change notifications on NTFS to detect changes to source files
Code behind
• .aspx page can use a System.Web.UI.Page derived class
stored in separate file
– Use src=“mycode.vb” in Page directive – Such files are automatically built
• No compiler arguments can be provided. Instead use • Visual Studio.NET has its own approach for code-behind
files (single .dll file)
– Click Show All Files button – codebehind attribute – <%@ Import Namespace=“System.Data”%> – <%@ Assembly Name=“System.Data”%>
User controls
• Use .ascx entension • Different directive
<%@ Control Language=“VB” Class=“…”%>
(no or , etc.)
• Contain only HTML that needs to be displayed • Need to be registered on page that uses them
<%@ Register TagPrefix=“twice” TagName=“ScoreWatcher” Src=“file.ascx”%>
• Output caching can be applied at control level
Security
• Security features provided by
– Internet Information Server – NTFS – ASP.NET Framework – Windows Integrated – Passport – Forms Authentication
• Authentication options for ASP.NET
Debugging and tracing
• Server-side debugging • Tracing
– web.config configures entire application – Page level directive (overrules web.config) – Trace object (Warn and Write methods) – When pageOutput=“false” use trace.axd
Session State
• ASP session state more of a burden • ASP.NET solves several problems
– cookieless sessions – Separate process for isolation (WebFarms) – SQL Server database for session storage (durable, survives system crashes)
ASP.NET Session State Architecture
aspnet_isapi.dll (ASP.NET ISAPI Extension)
aspnet_wp.exe (ASP.NET worker process)
HTTP Request handler
inetinfo.exe (IIS 4.0-5.1)
aspnet_state.exe (ASP.NET session process)
Deployment
• Most of time:
– XCOPY deployment in inetpub\wwwroot – Create virtual directory on target folder – Web Setup Project
• Assemblies contain own metadata • Pages and source files compiled on-the-fly • Catches:
– COM+ Application need administration – Global Assembly Cache installation (gacutil.exe) – Security roles and users (OS and/or database)
Where do WebServices fit in?
Visual Studio.NET
.NET Framework
COM+
.NET Enterprise Servers
Building Block Services
Windows.NET
Web Services
• A Web Service is programmable application logic
accessible through standard Web protocols
– “Web site functionality and data without UI” – – – – –
• Several open industry standards (Platform and
Vendor independent)
XML (eXtensible Markup Language) SOAP (Simple Object Access Protocol) WSDL (Web Service Description Language) UDDI (Universal Description, Discovery and Integration) DISCO (Discovery)
Web Services in practice
Find a Service
http://www.uddi.org Link to DISCO or WSDL document
UDDI
Discovery
Web Service Client
http://yourservice.com HTML or XML with link to WSDL
How do we talk? (WSDL)
http://yourservice.com/?WSDL
XML with service descriptions
Web Service
Let me talk to you (SOAP)
http://yourservice.com/svc1 XML/SOAP BODY
Design-Time or Dynamic
Runtime
Anatomy of WSDL document
… … …
describes SOAP parameters describes messages parameters/return values
defines method calls; pairs together inputs/outputs details on how to communicate with service
defines the service
ways to communicate with service
Building clients for Web Services
• There are many ways to implement a Web
Service client:
• • • •
ASP.NET or VB client (add Web Reference or use wsdl.exe tool) Internet Explorer WebService behavior Old (COM) clients through SOAP Toolkit 2.0 HTTP Post and Get clients
• Standard UI provided by ASP.NET
(uses DefaultWsdlHelpGenerator.aspx)
Proxies for Web Services
• Most client implementations use proxies
Client Application (ASP.NET or WinForm)
proxy
HTTP Get or Post SOAP
Web Service (any OS or platform)
• Proxy wraps method calls and serialization of
generated types (input or return values)
Building a Web Service
• Implement any class • Mark any web service method as
• Add directive to file <%@ WebService Language=“VB”
Class=“MyWebService” %> • Remember:
– Stateless programming paradigm – Use public methods only – member variables – methods
• Again, VS.NET uses code-behind and two separate files
Questions