The Composition of Web Services

As you come to understand the Web services model, you are also consistently introduced to a number of its specifications and capabilities. The vendors have done an excellent job by making it relatively easy to build and consume Web services in their development environments. In fact, in this chapter, you learn how to build and consume Web services using both .NET and Java. Whether you are building or consuming Web services, however, guarantee your success by making sure you understand the structure of the Web services model before you begin your first venture.

Understanding a few pillars of Web services development makes your job a lot easier. Not all the specifications or technologies that are used to build and consume Web services are required for every job, but you should review and understand everything before you start using Web services within any of your applications. Building Web services (whether in .NET or Java) gives you the following:

• q An industry-standard way to represent data

• q A way to transfer data in a common message format

• q A way to describe a Web service to potential consumers

• q A path to discovery of Web services on remote servers

Representing and Communicating Data in Web Services

As you are probably quite aware, Web services are heavily dependent upon XML. XML markup is used for data representation purposes, and XML Schemas are used to describe data types utilized by the Web services. XML is simply an excellent way to represent data. XML can be packaged and sent across the wire making the Web services model work. If you use XML, you immediately notice that a large number of platforms support XML, and they can manage it through an even larger set of tools available for XML data reading, writing, and manipulation.

Basing the data on XML and then standardizing the XML to the SOAP specification (discussed earlier in this chapter), make it easy to communicate your defined data representations from one point to another. Many Web services use HTTP to transport an XML document between disparate systems. When you transport your SOAP message in this manner, it flows easily through firewalls without any hindrance. Most firewalls are already configured to allow information from the Internet to flow freely through their walls.

You will find that the Web services communication model is not that different from other models you see in the Web world. When you have an application making a request of a Web service, this client triggers an HTTP Web request to the remote Web service. The request, in turn, most likely triggers a response from the server where the Web service resides. In the request from the client, the request message carries information about the function (WebMethod) to be called and any parameters that are required by the function. After the server that hosts the Web service receives the request message from the client, it initiates the function and returns a response message that contains the data returned by the function. The response message can be a simple statement that some particular action was taken, or it can contain a complete table of data from a database. What you want returned is really up to you.

In the past, it was quite possible to work with DCOM to port data from one point to another to solve almost the same problem that Web services are now addressing. However, with DCOM, requests and responses were required to ride on top of a proprietary communication protocol. This kind of architecture is not an effective way to provide data in a universal format such as XML. If your goal is to allow information to be sent and consumed regardless of the platforms used, DCOM does not achieve it.

Describing Web Services

Think of Web services as remote APIs (since they are basically just that). You have a method that you want to implement. Let's suppose the method wasn't built by you and resides somewhere else in the world on equipment that you have no control over-how can you go about providing that remote method what it needs in order to get instantiated?

When you find a Web service that you want to include in your application, you must first figure out how to supply the Web service with the parameters it needs in order for it to work. That need also extends a bit further. Even if you know the parameters and types that are required for instantiation, you also need to understand the types that are passed to your application in return. Without these pieces of information, using Web services would prove rather difficult.

Just as there are standard ways to represent data as well as standard ways to move this data over the Internet using Web services, there is a standard way to get a description of the Web service you are interested in consuming. Web Services Description Language (WSDL) is a specification of XML that describes the Web services you are interested in consuming. Listing 19-3 shows a sample WSDL file from a simple Calculation Web service that contains a single WebMethod called Addition (a+b).

Listing 19-3: A sample WSDL file

      <?xml version="1.0" encoding="utf-8"?>      <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"        xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"        xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"        xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"        xmlns:tns="http://www.wrox.com/" xmlns:s="http://www.w3.org/2001/XMLSchema"        xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"        xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"        targetNamespace="http://www.wrox.com/"        xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">          <wsdl:types>            <s:schema elementFormDefault="qualified"             targetNamespace="http://www.wrox.com/">              <s:element name="Addition">                <s:complexType>                  <s:sequence>                    <s:element minOccurs="1" maxOccurs="1" name="a" type="s:int" />                    <s:element minOccurs="1" maxOccurs="1" name="b" type="s:int" />                  </s:sequence>                </s:complexType>              </s:element>              <s:element name="AdditionResponse">                <s:complexType>                  <s:sequence>                    <s:element minOccurs="1" maxOccurs="1" name="AdditionResult"                     type="s:int" />                  </s:sequence>                </s:complexType>              </s:element>          </s:schema>          </wsdl:types>          <wsdl:message name="AdditionSoapIn">            <wsdl:part name="parameters" element="tns:Addition" />          </wsdl:message>          <wsdl:message name="AdditionSoapOut">            <wsdl:part name="parameters" element="tns:AdditionResponse" />          </wsdl:message>          <wsdl:portType name="CalculationSoap">            <wsdl:operation name="Addition">            <wsdl:input message="tns:AdditionSoapIn" />            <wsdl:output message="tns:AdditionSoapOut" />          </wsdl:operation>        </wsdl:portType>        <wsdl:binding name="CalculationSoap" type="tns:CalculationSoap">          <soap:binding transport="http://schemas.xmlsoap.org/soap/http" />          <wsdl:operation name="Addition">            <soap:operation soapAction="http://www.wrox.com/Addition" style="document" />            <wsdl:input>              <soap:body use="literal" />            </wsdl:input>            <wsdl:output>              <soap:body use="literal" />            </wsdl:output>          </wsdl:operation>        </wsdl:binding>        <wsdl:binding name="CalculationSoap12" type="tns:CalculationSoap">          <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />          <wsdl:operation name="Addition">            <soap12:operation soapAction="http://www.wrox.com/Addition"             style="document" />            <wsdl:input>              <soap12:body use="literal" />            </wsdl:input>            <wsdl:output>              <soap12:body use="literal" />            </wsdl:output>          </wsdl:operation>        </wsdl:binding>        <wsdl:service name="Calculation">          <wsdl:port name="CalculationSoap" binding="tns:CalculationSoap">            <soap:address             location="http://www.wrox.com/Calculation/Calculation.asmx" />          </wsdl:port>          <wsdl:port name="CalculationSoap12" binding="tns:CalculationSoap12">            <soap12:address             location="http://www.wrox.com/Calculation/Calculation.asmx" />          </wsdl:port>        </wsdl:service>      </wsdl:definitions> 

From this WSDL document, you can see that the input and output types are defined directly in the document. It also defines the location of the Web services and the different types of SOAP calls you can make to the Web service (using SOAP 1.1 or 1.2). Any client that uses this WSDL document can build the means to communicate with the defined Web service directly.

Discovering Web Services

To use a Web service, you have to be provided with the WSDL document or you have to know the URL endpoint of the WSDL file. How do you find the Web services you are interested in consuming if you don't have access to the location of the WSDL file or if someone or some process hasn't provided it to you?

Note that if you don't want to provide the means for discovering for your Web services, you don't need to build the discovery mechanism around it. If you wish to provide your Web services to the public, however, you must provide a means for users to locate it.

To allow users to discover Web services, various companies, such as Microsoft and IBM, have worked to create the required mechanics of discovery. It is accomplished through another XML specification known as UDDI (known in its full form as Universal Description, Discovery, and Integration).

You will find implementations of the UDDI specification on the Microsoft Windows Server 2003 server.

It is interesting to note that UDDI implementations are themselves Web services that employ the UDDI specifications to define a standard way to publish and discover information about Web services. The XML schemas associated with UDDI define four types of information that enable a developer to use a published Web service. The following table lists the types of information that UDDI provides.

Open table as spreadsheet

Information Provided	Description
Business details	The business contact information for the person or company that is providing the particular Web service.
Service detail	A name and description of the Web service.
Bindings detail	The specific access points for this service instance. It allows for display of additional instance-specific details.
Bindings details	Classifications that specify the field of operation of a business or a service (for example, a geographic location or an industry sector). These enable users of the registry to confirm the importance of a particular Web service.

The UDDI capabilities mentioned here are not the only way to publish and classify your Web services. Other directories that have sprung up on the Internet, and I am sure more will appear as the number of Web services grows. Presently, one of the better Web service directories (besides the one mentioned previously from Microsoft) is XMethods found at http://www.xmethods.com/.