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

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.. You

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:

• 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="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://

www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">

<soap12:Body>

<HowMuchWillItCost

xmlns="http://www.contentmaster.com/NorthwindServices">

<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="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://

www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">

<soap12:Body>

<HowMuchWillItCostResponse

xmlns="http://www.contentmaster.com/NorthwindServices">

<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="http://schemas.xmlsoap.org/wsdl/soap/"

…

targetNamespace="http://www.contentmaster.com/NorthwindServices"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

<wsdl:types>

<s:schema elementFormDefault="qualified"

targetNamespace="http://www.contentmaster.com/NorthwindServices">

<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-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

service request Redirecting Web service requests is also useful if an administrator needs to shut down a computer to perform maintenance Requests that would otherwise have been sent to this computer can be re-routed to one of its peers The WS-Addressing specification describes a framework for routing Web service requests

What does all this mean if you are developing Web services using Visual Studio 2005? Well, Microsoft provides its own implementation of the Security, WS-Policy, and WS-Addressing specifications in its Web services Enhancements package (WSE) You can download this package free of charge from the

Microsoft Web site, at

http://msdn.microsoft.com/webservices/building/wse/default.aspx When you install it, it integrates itself into the Visual Studio environment and adds additional project templates and assemblies that you can use For Visual Studio 2005, you need to download WSE 3.0

NOTE

None of the exercises in this chapter require you to install WSE 3.0