Web Services Architecture

Web services make use of the SOAP protocol, which is a standard defined by many companies. A big advantage of Web services is its platform-independence. However, Web services are not only a useful technology when multiple platforms need to cooperate. Web services are also a very useful technology for developing .NET applications on both the client and the server side. The advantage here is that the client and the server can emerge independently. A service description is done with a WSDL document (Web Service Description Language) that can be designed in a way to be independent of new versions of the Web service, and therefore the client needn't be changed.

If you want to use existing Web services, first you have to find one that meets your needs. If you know of a Web service that fits, you have to get the information on how to communicate with it. Figure 20-2 shows important mechanisms for calling Web services.

Figure 20-2

• First, you can find a Web service that has been registered in a registration directory service. This directory service returns information about the Web service. It's not a requirement that a Web service be registered with Universal Description, Discovery, and Integration (UDDI). You can get information about Web services from other sources.

• The description of the service is presented in the Web Services Description Language (WSDL) format. The description specifies the data that can be sent to the Web service, and what data can be received.

• The description of the Web service tells you what methods can be called. The methods will be called using SOAP, so all the method calls including the arguments must be converted to the SOAP protocol.

  Note

  Both SOAP and WSDL are defined with an XML grammar. The UDDI server can be queried program- matically by using a UDDI Web service.

Let's look into the steps of the sequence in more detail.

Search Engine for Web Services

Maybe you can use a Web service that is already supported by another company. To search and find preexisting Web services, Microsoft, IBM, and Ariba got together and initiated the www.uddi.org Website with the UDDI service. UDDI is a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Web as well as an operational registry. A company that wants to advertise its Web service can register it here. With the UDDI business registry and the UDDI API, it is possible to programmatically locate information about Web services.

Since the three companies mentioned earlier initiated UDDI, many more enterprises support the UDDI project; among them are Cisco Systems, Fujitsu, Intel, SAP, and Sun Microsystems.

To find an existing Web service, you can search by business name. After a successful search for a service you get its description, any information about its classification (for example, the groups it belongs to), and binding information.

In addition to using an open UDDI server for registration of services, you can install your own service if the service is only meant to be used within the company or by partners. Windows Server 2003 includes a UDDI server component that just needs to be configured.

In Visual Studio 2005, you can search for Web services by selecting Project Add Web Reference, as shown in Figure 20-3. You can select a Web service from the local solution, search for Web services on the local machine, browse UDDI servers on the local network, access the UDDI Directory from Microsoft, or make use of a Test UDDI Directory. If you know the path to the Web service, you can also enter it directly with the URL text box.

Figure 20-3

When you selecting the UDDI Directory link, Microsoft's UDDI server, http://uddi.microsoft.com, is opened, as shown in Figure 20-4. Here, you can specify search strings to find a registered Web service.

Figure 20-4

If the result of the search has binding information, a reference to the Web service can be added with the Add Reference button.

Entering the string Continental as provider name causes the server to list a Web service from Continental Airlines (see Figure 20-5) from which to get schedule and flight status information.

Figure 20-5

Besides UDDI servers, you can find many existing Web services at these Websites: www.xmethods.net and www.gotdotnet.com.

What Methods Can I Call?

A WSDL document has the information about the methods a Web service supports and how they can be called, parameter types passed to the service, and parameter types returned from the service. Figure 20-6 shows the WSDL that is generated from the ASP.NET runtime. Appending the string ?wsdl to the .asmx file returns a WSDL document.

Figure 20-6

It is not necessary to deal with this information directly. The WSDL document will be generated dynamically with the WebMethod attribute; you look at this attribute later on. Adding the Web reference to the client application with Visual Studio causes a WSDL document to be requested. This WSDL document, in turn, is used to create a client proxy with the same methods and arguments. With this proxy, the client application has the advantage that it only needs to call the methods as they are implemented in the server, because the proxy converts them to SOAP calls to make the call across the network.

The WSDL specification is maintained by the World Wide Web Consortium (W3C). You can read the specification at the W3C Website www.w3.org/TR/wsdl.

Calling a Method

To call a method on a Web service, the call must be converted to the SOAP message as defined in the WSDL document.

A SOAP message is the basic unit of communication between a client and a server. Figure 20-7 demonstrates the parts of a SOAP message. A SOAP message includes a SOAP envelope, which, as you might guess, wraps all the SOAP information in a single block. The SOAP envelope itself consists of two parts: a SOAP header and a SOAP body. The optional header defines how the client and server should process the body. The mandatory SOAP body includes the data that is sent. Usually information within this body is the method that is called together with the serialized parameter values. The SOAP server sends back the return values in the SOAP body of the SOAP message.

Figure 20-7

In the following example, you see what a SOAP message that is sent from the client to the server looks like. The client calls the Web service method ReverseString(). The string Hello World! is passed as an argument to this method. You can see that the method call is inside the SOAP body, it is within the XML element <soap:Body>. The body itself is contained within the envelope <soap:Envelope>. Before the start of the SOAP message, you can see the HTTP header, because the SOAP message is sent with an HTTP POST request.

It is not necessary to create such a message, because that is done by the client proxy:

POST /WebServiceSample/Service1.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: 508 SOAPAction: "http://www.wrox.com/webservices/ReverseString"     <?xml version="1.0" encoding="utf-8"?> <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:Body> <ReverseString xmlns="http://www.wrox.com/webservices">       <message>Hello World!</message> </ReverseString>   </soap:Body> </soap:Envelope> 

The server answers with the SOAP message !dlroW olleH, as can be seen with the ReverseStringResult XML element:

HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: 446     <?xml version="1.0" encoding="utf-8"?> <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:Body> <ReverseStringResponse xmlns="http://www.wrox.com/webservices">       <ReverseStringResult>!dlroW olleH</ReverseStringResult> </ReverseStringResponse>   </soap:Body> </soap:Envelope>

The SOAP specification is maintained by the XML Protocol Working Group of the W3C (www.w3.org/TR/soap).

SOAP and Firewalls

System administrators often ask if the SOAP protocol breaks the security boundaries of the firewalls — in other words, does SOAP violate the concept of firewalls? In reality, there are no more security issues to consider than for normal Web servers. With normal Web server firewalls, the system administrator opens HTTP port 80 to allow the server to communicate with the outside world. Users on the Internet can have direct access to these servers even though they sit behind the firewall. A user can request an HTML file with an HTTP request and the server returns either a static page, or a page created on the fly using ASP or CGI scripts. Web services are just another type of server-side application that communicates using HTTP, though instead of receiving simple HTTP GET or POST requests, it receives an HTTP POST request containing an embedded SOAP message, and instead of returning HTML, it returns an HTTP response containing the SOAP response message. As far as the firewall is concerned, the communication is through HTTP and hence it will be allowed through port 80.

However, if this Web service does not behave as it should, such as leaking confidential data or breaking the server, then there is a problem, but such problems are common to all server-side applications whether they be traditional Web pages, server-side business objects, or Web services.

If the firewall's system administrator is still worried about the security implications of Web services, he or she can use an application filter to not allow SOAP calls with an HTTP request.

WS-I Basic Profile

The SOAP specification emerged over time. That's the reason why sometimes it is hard to get interaction with Web services from different vendors. To cover this issue, the Web Services Interoperability Organization (http://ws-i.org) was formed. This organization defined the requirements for a Web service with the WS-I Basic Profile specification.

You can read the WS-I Basic Profile specification at www.ws-i.org/Profiles/BasicProfile-1.1.html.