WEB SERVICES

• Web services are application components
• Web services communicate using open protocols
• Web services are self-contained and self-describing
• Web services can be discovered using UDDI
• Web services can be used by other applications
• XML is the basis for Web services

How Does it Work?

The basic Web services platform is XML + HTTP.
XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.
The HTTP protocol is the most used Internet protocol.
Web services platform elements:

• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)

Interoperability has Highest Priority

When all major platforms could access the Web using Web browsers, different platforms could interact. For these platforms to work together, Web-applications were developed.
Web-applications are simple applications that run on the web. These are built around the Web browser standards and can be used by any browser on any platform.

---

Web Services take Web-applications to the Next Level

By using Web services, your application can publish its function or message to the rest of the world.
Web services use XML to code and to decode data, and SOAP to transport it (using open protocols).
With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server.

---

Web Services have Two Types of Uses

Reusable application-components.
There are things applications need very often. So why make these over and over again?
Web services can offer application-components like: currency conversion, weather reports, or even language translation as services.
Connect existing software.
Web services can help to solve the interoperability problem by giving different applications a way to link their data.
With Web services you can exchange data between different applications and different platforms.

What is SOAP?

SOAP is an XML-based protocol to let applications exchange information over HTTP.
Or more simple: SOAP is a protocol for accessing a Web Service.

• SOAP stands for Simple Object Access Protocol
• SOAP is a communication protocol
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP is a W3C standard

What is WSDL?

WSDL is an XML-based language for locating and describing Web services.

• WSDL stands for Web Services Description Language
• WSDL is based on XML
• WSDL is used to describe Web services
• WSDL is used to locate Web services
• WSDL is a W3C standard

What is UDDI?

UDDI is a directory service where companies can register and search for Web services.

• UDDI stands for Universal Description, Discovery and Integration
• UDDI is a directory for storing information about web services
• UDDI is a directory of web service interfaces described by WSDL
• UDDI communicates via SOAP
• UDDI is built into the Microsoft .NET platform

Difference between machine.config and Web.config

ASP.NET configuration files are XML-based text files--each named web.config--that can appear in any directory on an ASP.NET
Web application server. Each web.config file applies configuration settings to the directory it is located in and to all
virtual child directories beneath it. Settings in child directories can optionally override or modify settings specified in
parent directories. The root configuration file--WinNT\Microsoft.NET\Framework\\config\machine.config--provides
default configuration settings for the entire machine. ASP.NET configures IIS to prevent direct browser access to web.config
files to ensure that their values cannot become public (attempts to access them will cause ASP.NET to return 403: Access
Forbidden).
At run time ASP.NET uses these web.config configuration files to hierarchically compute a unique collection of settings for
each incoming URL target request (these settings are calculated only once and then cached across subsequent requests; ASP.NET
automatically watches for file changes and will invalidate the cache if any of the configuration files change).
http://samples.gotdotnet.com/quickstart/aspplus/doc/configformat.aspx

Data Caching

<%@ OutputCache Duration="60" VaryByParam="none" %>
<%@ OutputCache Duration="60" VaryByParam="*" %>
<%@ OutputCache Duration="60" VaryByParam="name;age" %>

The OutputCache directive supports several other cache varying options
VaryByHeader - maintain separate cache entry for header string changes (UserAgent, UserLanguage, etc.)
VaryByControl - for user controls, maintain separate cache entry for properties of a user control
VaryByCustom - can specify separate cache entries for browser types and version or provide a custom GetVaryByCustomString method in HttpApplicationderived class

SQL injection

An SQL injection attack "injects" or manipulates SQL code by adding unexpected SQL to a query.
Many web pages take parameters from web user, and make SQL query to the database. Take for instance when a user login, web page that user name and password and make SQL query to the database to check if a user has valid name and password.
Username: ' or 1=1 ---
Password: [Empty]
This would execute the following query against the users table:
select count(*) from users where userName='' or 1=1 --' and userPass=''

Diffrent types of Authentication modes in the .NET environment

 <authentication mode="Windows|Forms|Passport|None">
       <forms name="name"
                          loginUrl="url"
                          protection="All|None|Encryption|Validation"
                          timeout="30" path="/" >
                          requireSSL="true|false"
                          slidingExpiration="true|false">
          <credentials passwordFormat="Clear|SHA1|MD5">
             <user name="username" password="password"/>
          </credentials>
                    </forms>
       <passport redirectUrl="internal"/>

</authentication>

Attribute	Option	Description
mode		Controls the default authentication mode for an application.
	Windows	Specifies Windows authentication as the default authentication mode. Use this mode when using any form of Microsoft Internet Information Services (IIS) authentication: Basic, Digest, Integrated Windows authentication (NTLM/Kerberos), or certificates.
	Forms	Specifies ASP.NET forms-based authentication as the default authentication mode.
	Passport	Specifies Microsoft Passport authentication as the default authentication mode.
	None	Specifies no authentication. Only anonymous users are expected or applications can handle events to provide their own authentication.

Application and Session Events

The ASP.NET page framework provides ways for you to work with events that can be raised when your application starts or stops or when an individual user's session starts or stops:

Application events are raised for all requests to an application.
For example, Application_BeginRequest is raised when any Web Forms page or XML Web service in your application is requested. This event allows you to initialize resources that will be used for each request to the application. A corresponding event, Application_EndRequest, provides you with an opportunity to close or otherwise dispose of resources used for the request.
Session events are similar to application events (there is a Session_OnStart and a Session_OnEnd event), but are raised with each unique session within the application. A session begins when a user requests a page for the first time from your application and ends either when your application explicitly closes the session or when the session times out.

You can create handlers for these types of events in the Global.asax file.

What is cookie less session? How it works?
By default, ASP.NET will store the session state in the same process that processes the request, just as ASP does. If cookies are not available, a session can be tracked by adding a session identifier to the URL. This can be enabled by setting the following:
http://samples.gotdotnet.com/quickstart/aspplus/doc/stateoverview.aspx

Diffrence between Web User Control and Web Custom Control

Web custom controls are compiled components that run on the server and that encapsulate user-interface and other related functionality into reusable packages. They can include all the design-time features of standard ASP.NET server controls, including full support for Visual Studio design features such as the Properties window, the visual designer, and the Toolbox.
There are several ways that you can create Web custom controls:

You can compile a control that combines the functionality of two or more existing controls. For example, if you need a control that encapsulates a button and a text box, you can create it by compiling the existing controls together.
If an existing server control almost meets your requirements but lacks some required features, you can customize the control by deriving from it and overriding its properties, methods, and events.
If none of the existing Web server controls (or their combinations) meet your requirements, you can create a custom control by deriving from one of the base control classes. These classes provide all the basic functionality of Web server controls, so you can focus on programming the features you need.

If none of the existing ASP.NET server controls meet the specific requirements of your applications, you can create either a Web user control or a Web custom control that encapsulates the functionality you need. The main difference between the two controls lies in ease of creation vs. ease of use at design time.

Web user controls are easy to make, but they can be less convenient to use in advanced scenarios. You develop Web user controls almost exactly the same way that you develop Web Forms pages. Like Web Forms, user controls can be created in the visual designer, they can be written with code separated from the HTML, and they can handle execution events. However, because Web user controls are compiled dynamically at run time they cannot be added to the Toolbox, and they are represented by a simple placeholder glyph when added to a page. This makes Web user controls harder to use if you are accustomed to full Visual Studio .NET design-time support, including the Properties window and Design view previews. Also, the only way to share the user control between applications is to put a separate copy in each application, which takes more maintenance if you make changes to the control.

Web custom controls are compiled code, which makes them easier to use but more difficult to create; Web custom controls must be authored in code. Once you have created the control, however, you can add it to the Toolbox and display it in a visual designer with full Properties window support and all the other design-time features of ASP.NET server controls. In addition, you can install a single copy of the Web custom control in the global assembly cache and share it between applications, which makes maintenance easier.

Web user controls	Web custom controls
Easier to create	Harder to create
Limited support for consumers who use a visual design tool	Full visual design tool support for consumers
A separate copy of the control is required in each application	Only a single copy of the control is required, in the global assembly cache
Cannot be added to the Toolbox in Visual Studio	Can be added to the Toolbox in Visual Studio
Good for static layout	Good for dynamic layout