Professional Documents
Culture Documents
Building Web Services
Building Web Services
A Web service is an application component that is remotely callable using standard Internet protocol such as HTTP
and markup language XML. Thus, any system that supports these basic, standard protocols is capable of supporting
Web services. Web services use a text-based messaging model to communicate, allowing them to operate
effectively on many different platforms.
Elements of Web services
Microsoft provides an excellent platform for building and consuming Web services with the .NET Framework, which
virtually eliminates the need to learn about the "plumbing" that is a part of building and consuming Web services. The
standards-based services provide the following capabilities to Web services:
A standard, portable method for describing data.
A standard, extensible message format for communicating requests and responses.
A standard, extensible method for describing the capabilities of Web services.
A method to discover what Web services are available at any particular site.
A method to discover what sites provide Web services.
Representing Data: Web services enable consumers to programmatically request and obtain structured data. To
promote the ability of Web services to communicate their data unambiguously, efficiently, and effectively, a common,
portable, and standard method for describing data i.e. XML used.
Default namespace declaration: Default declaration defines a namespace whose scope includes all elements
contained within the element where the declaration was specified. Default declaration is typically used when a
document contains elements from a single namespace
Explicit namespace declaration: Explicit declaration defines a shorthand reference to an existing namespace. This
method is used when referencing an element or attribute from other namespaces. For
example, we could combine the elements from several namespaces into another XML document by using explicit
namespace declaration.
Exchanging Messages: Web services communicate in the form of messages. A request message delivers
information about an operation to be executed and any data required to carry out that operation. Request messages
flow from clients to Web services. A response message delivers information about the results of the operation
execution. Response messages flow from Web services to clients. Communication via messages is an extremely
effective method for insulating Web service consumers from the implementation details of the service. The Simple
Object Access Protocol (SOAP) is an industry-standard message format that enables message-based
communication for Web services. SOAP implements a message format based on XML to exchange function
requests and responses. Using XML as the basis for SOAP messages makes it possible for these messages to be
understandable and transportable by any system that implements basic Internet communications services. SOAP
simply defines a message format. It does not impose a specific transport protocol for exchanging these messages.
Thus, it is possible to transport SOAP messages over any one of many different and widely available transport
protocols such as HTTP, SMTP, FTP, and so on.
Describing Web Service Capabilities: Given a standard method to encode data (XML) and a standard method to
exchange Web service requests and responses via messages (SOAP), we need a standard way to describe the
specific message exchanges (or capabilities) that a Web service supports. SOAP does not define the specific
methods and results that a Web service may offer. Web services must have a method to describe to potential
consumers the specific capabilities that the service offers. Without this capability, consumers would not be able to
determine how to request some functionality of the Web service or what to expect as a response. A Web service
description is an XML document that defines the capabilities that a Web service offers. This document provides
essential information in a structured form that enables a consumer to understand how to interact with a Web service.
The Web Service Description Language (WSDL) defines a standard, extensible XML grammar that is used to define
these Web service descriptions in the form of an XML document.
The WSDL document defines the message formats and message exchange patterns that a Web service can
process. In addition to these definitions, the WSDL document contains the address of each Web service entry point,
formatted according to the protocol used to access the service (for example, a URL for HTTP or an e-mail address
for SMTP). A WSDL document defines services as a collection of network endpoints, or ports using the elements
endpoints.
Web Services Infrastructure
Microsoft Web Services Platform:
One of the major advantages of the Web services foundation is its simplicity as well as its reliance on existing (or
emerging) Internet standards. This ensures that Web services can be implemented on and available across the
diverse systems of the Internet. The Microsoft .NET platform is specifically designed to provide scalable, robust and
distributed applications, which makes it easy to create world-class Web Services.
The Common Language Runtime (CLR) is built on top of the system platform . Layered on the CLR is the .NET
Framework Class Library, which provides a large set of services via a hierarchically arranged collection of classes
and types. On top of this base is the ASP.NET Web platform and Windows Forms environments. One of the primary
goals of the Microsoft Web Services platform is to make it easy to build Web services that can solve complex,
business-critical issues.
ASP.NET applications
An ASP.NET application consists of all the files, pages, handlers, modules, and executable code that reside in a
Web server virtual directory. Web services are also ASP.NET applications and, therefore, are governed by the same
configuration rules as any other ASP.NET application. Each ASP.NET application can include an optional
Global.asax file in the root virtual directory. This file contains handlers for application-level events that can be raised
by ASP.NET. ASP.NET applications also support a hierarchical application configuration architecture. Application
configuration settings are stored in an XML file named Web.config. The settings stored in this file are applied
hierarchically as follows:
Web.config files supply their settings to the directory in which they are located as well as to all subdirectories.
Configuration settings for a Web resource are supplied by the Web.config file located in the same directory as the
resource and by all configuration files in all parent directories.
State management
HTTP is a stateless protocol. This means that HTTP does not retain any information or knowledge from one request
to the next even though those requests may come from the same user session and may even be related to each
other. ASP.NET provides both application state and session state management capabilities for Web applications.
Application state is used to store data that applies to the application as a whole and is available to all sessions using
the application. Session state is used to store data that is specific to each browser session using the application.
Session state is not visible across different sessions. Both application and session state information is stored in
key/value dictionary objects. Access to this information is supplied through an Application object (for application
state) and a Session object (for session state). Application state is essentially a global variable-storage mechanism
for ASP.NET applications. Experienced developers know that global variables come with specific issues and must be
considered and used sparingly. This is even more important in a server-based scenario, such as ASP.NET
applications. In particular, we should be aware of the following when considering the use of application state in
ASP.NET applications:
Memory used by application variables is not released between requests.
Application variables have concurrency and synchronization issues.
Application state is not shared across a Web farm.
ASP.NET session state provides the following features:
Session state can survive IIS and worker-process restarts without losing session state information.
Session state can be used in both Web farm and Web garden configurations.
Session state can be used even if the client browser does not support cookies.
ASP.NET session state can be fully configured to meet your specific needs via the Config.web configuration files. For
Web applications that require session state, ASP.NET provides excellent, reliable, and scalable support for
maintaining session state.
Caching
One of the most important factors in creating highly scalable, high-performance Web applications is through the use
of caching. Essentially, caching permits the Web application to supply the results of a previous request to other
requests for the same information without having to involve the server in regenerating this information. This can
greatly increase the performance of our Web application. ASP.NET provides two types of caching capabilities.
Output caching supplies the output of previous requests from the output cache instead of re-executing the server
code necessary to generate the output a second time. The application cache is a programmatic cache that
applications can use to store objects and other resources that can take a lot of time to re-create.
Transactions
A transaction is a set of related tasks that either succeed or fail as a unit. By combining a set of related operations
into a unit that either completely succeeds or completely fails, we can simplify error recovery and make your
application more reliable. ASP.NET Web Services support declarative, attribute-based transactions at the method
level. This means that we can specify, via a property of the WebMethod attribute, what, if any, type of transaction
support is required for our Web service method. Subsequently, any resource managers that we interact with during
the execution of the Web method will be transacted.
Security
ASP.NET provides a comprehensive, flexible, and extensible security framework that enables us to secure our Web
services. The security framework addresses four fundamental security needs:
Authentication: To determine that a user is who he/she claims to be
Authorization: To control access to resources based on the identity of a user
Impersonation: To assume the identity of the requesting user when accessing resources
Code Access Security: To restrict the operations that a piece of code can perform
The SOAP envelope: The SOAP envelope element is a required part of a SOAP message. It serves as a container
for all remaining SOAP message elements. Typically, this includes the SOAP header and body elements. In addition
to serving as a container for the header and body elements, the envelope defines the namespaces used by these
elements.
The SOAP header: The SOAP header element is an optional part of a SOAP message. It defines additional
information that can be related to the method request in the body element or, more likely, information that is
independent of the method request that is required or otherwise useful to your application. SOAP does not define the
specific contents or semantics for a SOAP header.
The SOAP body: The SOAP body element is a required part of a SOAP message that contains the data specific to a
particular method call, such as the method name and any input/output arguments or the return values produced by
the method. The contents of the SOAP body depend on whether the message is a request or a response. A request
message contains method call information, whereas a response message contains method call result data.
Example:
<soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<Authentication xmlns="http://example.org">
<Username>JDC</Username>
<Password>pwd</Password>
</Authentication>
</soap:Header>
<soap:Body>
<!-- The SOAP body elements are inserted here -->
</soap:Body>
</soap:Envelope>
SOAP Exceptions
If Web service methods were guaranteed to work at all times, we would not need any form of error notification or
processing capabilities. Unfortunately, things can go wrong. As such, errors or exceptions that occur in a Web
service method call need to be communicated back to the consumer of the Web service in some manner. SOAP
exceptions are used to return error or exception information to the consumer of a Web service as the result of a
failed method call.
Method arguments
The temperature conversion method will accept three arguments
Temperature(Decimal): Any numeric value that can be specified by the Decimal data type
FromUnits(String): Valid values are C for Celsius or F for Fahrenheit
ToUnits (String): Valid values are C for Celsius, F for Fahrenheit, K for Kelvin, and R for Rankine
The method will return a Decimal result, which is the value of the conversion to the units specified in the ToUnits
argument.
Method behavior
If the FromUnits and ToUnits arguments are the same, the method call will be successful and the Temperature
argument will be returned unchanged. If the FromUnits and/or ToUnits do not specify valid unit identifiers, an
ArgumentException exception will be thrown. Likewise, if the conversion specified by the FromUnits and ToUnits
arguments is not supported, an ArgumentException exception will be thrown.
using System;
using System.Web;
using System.Collections;
using System.Web.Services;
using System.Web.Services.Protocols;
[WebService(Namespace = "http://dummy.com/webservices/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Convertor : System.Web.Services.WebService {
[WebMethod]
public double CTemp(double temp, String FUnit,String TUnit) {
double t = 0;
if (FUnit.Equals("F"))
{
if (TUnit.Equals("C"))
t = (temp - 32) * 5 / 9;
else if (TUnit.Equals("K"))
t = (temp - 32) * 5 / 9 + 273.15;
else if (TUnit.Equals("F"))
t = temp;
else
t = 0;
}
else if (FUnit.Equals("C"))
{
if (TUnit.Equals("C"))
t = temp;
else if (TUnit.Equals("K"))
t = temp + 273.15;
else if (TUnit.Equals("F"))
t = (temp * 9 / 5) + 32;
else
t = 0;
}
else if (FUnit.Equals("K"))
{
if (TUnit.Equals("C"))
t = temp - 273.15;
else if (TUnit.Equals("K"))
t = temp;
else if (TUnit.Equals("F"))
t = (temp - 273.15) * 9 / 5 + 32;
else
t = 0;
}
else
{
temp = 0;
}
return t;
}