Tài liệu What Is a Web Service? ppt

What Is a Web Service?
A Web service is a business component that provides some useful facility to clients, or
consumers. Just as Distributed Component Object Model (DCOM) is thought of as
“COM with a longer wire,” a Web service can be thought of as a component with a truly
global reach. Web services use a standard, accepted, and well-understood protocol called
HTTP to transmit data, and a portable data format that is based on XML. HTTP and
XML are both standardized technologies that can be used by other programming
environments outside of the .NET Framework. So, you can build Web services by using
Visual Studio 2005, and client applications (called consumers) that are running in a
totally different environment, such as Java, can use them. The reverse is also true; you
can build Web services by using Java, and write consumer applications in C#.
You can use several different languages with Visual Studio 2005 to build Web services.
Currently, Microsoft Visual C++, Microsoft Visual C#, Microsoft Visual J#, and
Microsoft Visual Basic .NET are supported, and it is likely that there will be others in the
future. As far as the consumer is concerned, however, the language used by the Web
service, and even how the Web service performs its tasks, is not important. The
consumer's view of a Web service is of an interface that exposes a number of well-
defined methods. All the consumer needs to do is call these methods by using the
standard Internet protocols, passing parameters in an XML format and receiving
responses also in an XML format.
One of the driving forces behind the .NET Framework and future releases of Windows is
the concept of the “programmable Web.” The idea is that, in the future, systems will be
constructed by using the data and services provided by multiple Web services. Web
services provide the basic elements for systems, the Web provides the means to gain
access to them, and developers glue them together in meaningful ways. Web services are
a key integration technology for combining disparate systems together; they are the basis
for many business-to-business (B2B) and business-to-consumer (B2C) applications.
The Role of SOAP
Simple Object Access Protocol (SOAP) is the protocol used by consumers for sending

requests to, and receiving responses from, Web services.
SOAP is a lightweight protocol built on top of HTTP. It is possible to exchange SOAP
messages over other protocols but, currently, only the HTTP bindings for SOAP have
been defined. It defines an XML grammar for specifying the names of methods that a
consumer wants to invoke on a Web service, for defining the parameters and return
values, and for describing the types of parameters and return values. When a client calls a
Web service, it must specify the method and parameters by using this XML grammar.
SOAP is an industry standard. Its function is to improve cross-platform interoperability.
The strength of SOAP is its simplicity and also the fact that it is based on other industry
standard technologies: HTTP and XML.
The SOAP specification defines a number of things. The most important are the
following:
•
The format of a SOAP message
•
How data should be encoded
•
How to send messages (method calls)
•
How to process replies
For example, consider a Web service called ProductService.asmx (in the .NET
Framework, URLs for Web services have the suffix .asmx) that exposes methods for
accessing the Products table in the Northwind Traders database (you will build this Web
service later in this chapter). One such method called HowMuchWillItCost allows a
client to supply the name of a product and a quantity. The method queries the unit price
in the database to calculate the total cost of buying the specified quantity of the product.
The SOAP request sent by the client might look like this:
POST /NorthwindServices/Service.asmx HTTP/1.1
Host: localhost
Content-Type: application/soap+xml; charset=utf-8

Content-Length: 579

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="
xmlns:xsd="http://
www.w3.org/2001/XMLSchema" xmlns:soap12=" />envelope">
<soap12:Body>
<HowMuchWillItCost
xmlns="
<productName>Chai</productName>
<howMany>39</howMany>
</HowMuchWillItCost>
</soap12:Body>
</soap12:Envelope>
The request contains two parts: a header comprising everything up to the <soap12:Body>
tag, and the actual body of the message in the <soap12:Body> tag. You can see how the
body encodes parameters—in this example, the name of the product is Chai and the
quantity is 39.
The Web server will receive this request, identify the Web service and method to run, run
the method, obtain the results, and send them back to the client as a SOAP result, like
this:
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 546

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="
xmlns:xsd="http://
www.w3.org/2001/XMLSchema" xmlns:soap12=" />envelope">
<soap12:Body>

<HowMuchWillItCostResponse
xmlns="
<HowMuchWillItCostResult>529</HowMuchWillItCostResult>
</HowMuchWillItCostResponse>
</soap12:Body>
</soap12:Envelope>
The client can then extract the result from the body of this message and process it.
What Is the Web Services Description Language?
The body of a SOAP message is XML. The Web server expects the client to use a
particular set of tags for encoding the parameters for the method. How does a client know
which schema to use? The answer is that, when asked, a Web service is expected to
supply a description of it-self. A client can submit a request to a Web service with the
query string wsdl appended to it:
http://localhost/NorthwindServices/Service.asmx?wsdl
The Web service will reply with a description like this:
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:soap="

…
targetNamespace="
xmlns:wsdl="
<wsdl:types>
<s:schema elementFormDefault="qualified"
targetNamespace="
<s:element name="HowMuchWillItCost">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="productName" type="s:string" />
<s:element minOccurs="1" maxOccurs="1"

name="howMany" type="s:int" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="HowMuchWillItCostResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="HowMuchWillItCostResult" type="s:decimal" />
</s:sequence>
</s:complexType>
</s:element>
</s:schema>
</wsdl:types>
…
</wsdl:definitions>
This is known as the Web Service Description (a large chunk has been omitted to save
space), and the schema used is called Web Services Description Language (WSDL). This
description provides enough information to allow a client to construct a SOAP request in
a format that the Web server should understand. The description looks complicated but,
fortunately, Microsoft Visual Studio 2005 contains tools that can parse the WSDL for a
Web service in a mechanical manner, and then use it to create a proxy object that a client
can use to convert method calls into SOAP requests. You will do this later in this chapter.
For now, you can concentrate on building a Web service.
Web Services Enhancements
Not long after Web services became a mainstream technology for integrating distributed
services together, it became apparent that there were issues that SOAP and HTTP alone
could not address. These issues include:
•
Security.How do you ensure that SOAP messages that flow between a Web

service and a consumer have not been intercepted and changed on their way across
the Internet? How can you be sure that a SOAP message has actually been sent by
the consumer or Web service that claims to have sent it, and not some “spoof” site
that is trying to fraudulently obtain information? How can you restrict access to a
Web service to specific users? These are matters of message integrity,
confidentiality, and authentication, and are fundamental concerns if you are
building distributed applications that make use of the Internet.
In the early 1990s, a number of vendors supplying tools for building distributed
systems formed an organization that later became known as the Organization for
the Advancement of Structured Information Standards, or OASIS. As the short-
comings of the early Web services infrastructure became apparent, members of
OASIS pondered these problems and produced what became known as the WS-
Security specification. The WS-Security specification describes how to secure the
messages sent by Web services. Vendors that subscribe to WS-Security provide
their own implementations that meet this specification, typically by using various
encryption mechanisms and certificates.
•
Policy.
Although the WS-Security specification provides enhanced security, developers
still need to write code to implement it. Web services created by different
developers can often vary in how stringent the security mechanism they have
elected to implement is. For example, a Web service might use only a relatively
weak form of encryption which can easily be broken. A consumer sending highly
confidential information to this Web service would probably insist on a higher
level of security. This is one example of policy. Other examples include the
quality of service and reliability of the Web service. A Web service could
implement varying degrees of security, quality of service, and reliability, and
charge the client application accordingly. The client application and the Web
service can negotiate which level of service to use based on the requirements and
cost. However, this negotiation requires that the client and the Web service have a

common understanding of the policies available. The WS-Policy specification
provides a general purpose model and corresponding syntax to describe and
communicate the policies of a Web service.
•
Routing and addressing. It is useful for a Web server to be able to re-route a Web
service request to one of a number of servers. For example, many scalable systems
make use of load-balancing; requests sent to a server are actually redirected by
that server to other computers to spread the load across those computers. The
server can use any number of algorithms to try and balance the load. The
important point is that this redirection is transparent to the client making the Web