What Are Web Services?
| only for RuBoard |
Web services are pieces of programming logic that provide functionality to a variety of potentially disparate systems through the use of Internet standards. These pieces of logic can include such things as mathematical calculations, data look-up logic, authorization services ”virtually any type of programming function you can think of. Through the use of Internet standards like XML and SOAP, your Web services can be used by any number of disparate systems, or locally by your own applications.
As you look at what Web services are, you must remember that three things are required for Web services to be successful:
-
Systems must be loosely coupled .
Two systems must be able to exchange data or functionality with each other, understanding no more than what inputs are required, and what outputs to expect.
-
Systems must provide ever-present communication.
For a Web service to be successful the provider of the service must be available at all times. As Internet technology has grown, the capability to provide a constant online presence has become easier, nearly to a point of being assumed that a constant online presence is available.
-
Web services must use a universal data format.
Because Web services are intended to enable disparate systems to interact and exchange data, universally understood data formats are required. The use of common standards like XML enables any system capable of understanding the standards to make use of Web services.
Common Standards
Web services are designed to work with common Internet standards. Following is a brief overview of these standards.
SOAP
SOAP, or Simple Object Access Protocol, is an XML-based data exchange protocol. SOAP uses XML's structure to represent objects and their properties and methods . Since SOAP uses existing Internet architecture, such as HTTP, the integration of SOAP into Web services is nearly seamless. SOAP is a lightweight, message-based protocol that is built on XML and Internet standards. Every SOAP message is a one-way transmission, but SOAP messages can be combined to implement patterns such as request/response.
WSDL
WSDL, or Web Service Description Language, is an XML-based document that describes the format of messages that the Web service understands. Every Web service must have a WSDL. The WSDL is basically an agreement that the provider and the consumer use to describe the behavior, inputs, outputs, and data types exchanged in the Web service. The WSDL describes, conceptually, what will happen when the consumer provides a properly formatted message to the Web service.
DISCO
DISCO, or Web service discovery, is the process of locating and interrogating Web service descriptions (WSDLs). This is a preliminary step to actually consuming a Web service. The discovery process enables consumers to find a Web service, learn its capabilities, and learn how to properly interact with the Web service. Providers of Web services can create a *.disco file, which is an XML document that contains links to other files that describe the Web service, such as the location of the WSDL. Providers are not required to provide a means for public discovery of their Web services. Often the provider can design the Web services for their use only. The discovery process is used only for Web services that are meant to be consumed publicly .
UDDI
UDDI, or Universal Description Discovery Integration, is analogous to the Yellow Pages of Web services. UDDI is a project put forth by technology leaders such as Microsoft, IBM, and Ariba to standardize how Web services are found on the Internet. UDDI creates a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet. UDDI defines how companies can expose their business applications as Web services. The UDDI project involves the shared implementation of a Web service, the UDDI Business Registry, which acts as an Internet directory of businesses and the applications they have exposed as Web services. Businesses will use the UDDI Web service to find other Web services in a manner similar to how people use Internet search engines today.
Note
You can learn more about UDDI by visiting the Microsoft UDDI Web site at http://uddi.microsoft.com, or the UDDI community Web site at http://www.uddi.org.
Usable Protocols
Web services are designed to be as accessible as possible. One of the primary goals of the Web service architecture is to exchange data in a common format that is not tied to a single operating system or language. Binary protocols like DCOM, RMI, and COBRA work by riding on top of a proprietary communication protocol. Although they can be used with Web services, because of their proprietary nature, they limit the acceptance of the Web service only to consumers who support the protocol.
Using Internet standard protocols enables Web services to be widely accepted and used. By using common protocols, businesses can exchange data, such as purchase orders and order-tracking information, without the hassles of cross-system data exchange. I once worked in a shop where we struggled with RMI calls to exchange data between a COM system and a Java class system. It was painful to say the least. We spent an excessive amount of time opening a VPN and making RMI calls ”activities that could have been done easily and in much less time using Web services and standard HTTP-based protocols.
Http-Get and Http-Post
Http-Get and Http-Post are standard HTTP-based protocols that use name/value pairs to pass data to the Web service. Http-Get passes its name /value pairs as UUencoded text appended to the URL of the server handling the request. Http-Post also passes the name/value pairs as UUencoded text; however, the name/value pairs are passed in the request header, rather than in the URL.
Web services can be accessed using either Http-Get or Http-Post. For example, to implement a Web service exposed on the DotNetJunkies.com Web site, you simply type in the URL and append it with the name/value pairs expected as input by the Web service:
http://www.dotnetjunkies.com/services/TrivialFunTools.asmx/RandomNumberGenerator?LowNumber=1&HighNumber=7
In this example, you use Http-Get to execute a Web service exposed by DotNetJunkies.com. The Web service, RandomNumberGenerator , is an exposed method of the TrivialFunTools Web service. The Web service expects two input parameters, LowNumber and HighNumber . These parameters are appended to the URL in the form of a QueryString :
http:// server ? name = value & name = value
The actual HTTP request header looks like this:
GET /services/TrivialFunTools.asmx/RandomNumberGenerator? LowNumber=1&HighNumber=7 HTTP/
The result of making this call is an XML document representing the results:
<?xml version="1.0" ?> <int xmlns="http://tempuri.org/">5</int>
Using Http-Post works much in the same manner, but the name/value pairs are passed in the HTTP request header:
POST /services/TrivialFunTools.asmx/RandomNumberGenerator HTTP/1.1 Host: http://www.dotnetjunkies.com Content-Type: application/x-www-form-urlencoded Content-Length: length LowNumber=1&HighNumber=7
SOAP
SOAP, like Http-Get and Http-Post, can be used to invoke a Web service and return the results. SOAP defines XML grammar for identifying the Web service method name and wrapping the method parameters. It also defines an XML grammar for returning results. SOAP is the most extensible mechanism of the three protocols (Http-Get, Http-Post, and SOAP). Although Http-Get and Http-Post enable the exchange of multiple data types and value classes, SOAP also enables the exchange of classes, structs, and DataSet s. The offset is that the payload of a SOAP message is much larger than the Http-Get and Http-Post request headers.
A call to the RandomNumberGenerator Web service will look like the following as a SOAP message:
POST /services/TrivialFunTools.asmx HTTP/1.1 Host: http://www.dotnetjunkies.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://www.dotnetjunkies.com/RandomNumberGenerator" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://
The returned result is a SOAP message that encapsulates the return value in a SOAP envelope:
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://
Figure 14.1 shows how a Web service provider and a Web service consumer interact using HTTP, DISCO, WSDL, SOAP, and XML.
Figure 14.1. A provider exposes a Web service that a consumer uses.
Figure 14.1 shows how a Web service provider and consumer interact. A Web service provider (1) makes a Web service publicly available on the Internet. The consumer (2) goes through the discovery process (3) to find out what Web services are available from the provider. The discovery process returns a link to the WSDL document. When the consumer knows where to find the WSDL, she can request it by appending the URL with ?WSDL (4). The WSDL can be used to build classes for consuming the Web service. The consumer then can call the Web service with an Http-Get, Http-Post, or a SOAP message (5). The data is returned to the client as either an XML document, or XML-formatted data in a SOAP message.
| only for RuBoard |
EAN: 2147483647
Pages: 170