Skip to content

Web Services#

What Is The Web Services?#

  • Different books and different organizations provide different definitions to Web Services. Some of them are listed here.

    • A web service is any piece of software that makes itself available over the internet and uses a standardized XML messaging system. XML is used to encode all communications to a web service. For example, a client invokes a web service by sending an XML message, then waits for a corresponding XML response. As all communication is in XML, web services are not tied to any one operating system or programming language - Java can talk with Perl; Windows applications can talk with Unix applications.

    • Web services are self-contained, modular, distributed, dynamic applications that can be described, published, located, or invoked over the network to create products, processes, and supply chains. These applications can be local, distributed, or web-based. Web services are built on top of open standards such as TCP/IP, HTTP, Java, HTML, and XML.

    • Web services are XML-based information exchange systems that use the Internet for direct application-to-application interaction. These systems can include programs, objects, messages, or documents.

    • A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards.

  • To summarize, a complete web service is, therefore, any service that:

    • Is available over the Internet or private (intranet) networks
    • Uses a standardized XML messaging system
    • Is not tied to any one operating system or programming language
    • Is self-describing via a common XML grammar
    • Is discoverable via a simple find mechanism

Components of Web Services#

  • The basic web services platform is XML + HTTP. All the standard web services work using the following components
    • SOAP (Simple Object Access Protocol)
    • UDDI (Universal Description, Discovery and Integration)
    • WSDL (Web Services Description Language)

SOAP#

  • Simple Object Access Protocol (SOAP) is a lightweight XML-based protocol that is used for the exchange of information in decentralized, distributed application environments. You can transmit SOAP messages in any way that the applications require, as long as both the client and the server use the same method. The current specification describes only a single transport protocol binding, which is HTTP.

  • SOAP perfectly fits into the world of Internet applications and promises to improve Internet inter-operability for application services in the future. In essence, SOAP packages method calls into XML strings and delivers them to component instances through HTTP.

  • SOAP XML documents are structured around root elements, child elements with values, and other specifications. First an XML document containing a request (a method to be invoked and the parameters) is sent out. The server responds with a corresponding XML document that contains the results.

  • SOAP is not based on Microsoft technology. It is an open standard drafted by UserLand, Ariba, Commerce One, Compaq, Developmentor, HP, IBM, IONA, Lotus, Microsoft, and SAP. SOAP 1.1 was presented to the W3C in May 2000 as an official Internet standard. Microsoft is one of the greatest advocates of SOAP and has incorporated SOAP as a standard interface in the .NET architecture.

  • A SOAP stack, an implementation of the SOAP standard on the client side, is comprised of libraries and classes that offer helper functions. A significant Web service testing challenge is that there are a number of SOAP stack implementations that are not compatible with one another. So although SOAP is intended to be both platform- and technology-independent, it is not. Web services written in .NET are however always compatible with .NET clients—they use the same SOAP stack, or library. When testing a .NET Web service however, you need to confirm if the service is compatible with other SOAP stack implementations, for example Java SOAP stack, to avoid interoperability issues.

  • SOAP client requests are encapsulated within HTTP POST or M-POST packages. The following example is taken from the Internet draft-specification.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml;
charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<?xml version="1.0"?>
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetLastTradePrice xmlns:m="Some-URI">
      <symbol>DIS</symbol>
    </m:GetLastTradePrice>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

  • The first four lines of code are standard HTTP. POST is the HTTP verb which is required for all HTTP messages. The Content-Type and Content-Length fields are required for all HTTP messages that contain payloads. The content-type text/xml indicates that the payload is an XML message to the server or a firewall capable of scanning application headers.

  • The additional HTTP header SOAPAction is mandatory for HTTP based SOAP messages, and you can use it to indicate the intent of a SOAP HTTP request. The value is a URI that identifies the intent. The content of a SOAPAction header field can be used by servers, for example firewalls, to appropriately filter SOAP request messages in HTTP. An empty string ("") as the header-field value indicates that the intent of the SOAP message is provided by the HTTP Request-URI. No value means that there is no indication on the intent of the message.

  • The XML code is straightforward. The elements Envelope and Body offer a generic payload-packaging mechanism. The element GetLastTradePrice contains an element called symbol, which contains a stock-ticker symbol. The purpose of this request is to get the last trading price of a specific stock, in this case Disney (DIS).

  • The program that sends this message only needs to understand how to frame a request in a SOAP-complient XML message and how to send it through HTTP. In the following example, the program knows how to format a request for a stock price. The HTTP server that receives the message knows that it is a SOAP message because it recognizes the HTTP header SOAPAction. The server then processes the message.

  • SOAP defines two types of messages, calls and responses, to allow clients to request remote procedures and to allow servers to respond to such a request. The previous example is an example of a call. The following example comes as a response in answer to the call.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
HTTP/1.1 200 OK
Content-Type: text/xml;
charset="utf-8"
Content-Length: nnnn
<?xml version="1.0"?>
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
  <SOAP-ENV:Body>
    <m:GetLastTradePriceResponse xmlns:m="Some-URI">
      <Price>34.5</Price>
    </m:GetLastTradePriceResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

  • The first three lines of code are standard HTTP. The first line indicates a response code to the previous POST request, the second and third line indicate the content type and the fourth line the lenght of the response.

  • XML headers enclose the actual SOAP payloads. The XML element GetLastTradePriceResponse contains a response to the request for a trading price. The child element is Price, which indicates the value that is returned to the request

UDDI#

  • Universal Description, Discovery, and Integration (UDDI) specification defines a way to publish and discover information about Web services.

  • UDDI has two functions:

    • It is a SOAP-based protocol that defines how clients communicate with UDDI registries.
    • It is a particular set of global replicated registries.

  • UDDI includes an XML schema for SOAP messages that defines a set of documents to describe business and services information, a common set of APIs for querying and publishing information to the directories, and an API for replicating directory entries between peer UDDI nodes.

  • UDDI registries: UDDI manages the discovery of Web services by relying on a distributed registry of businesses and their service descriptions implemented in a common XML format. Before you can publish your business entity and Web service to a public registry, you must first register your business entity with a UDDI registry.

  • UDDI registries come in two forms: public and private.  Both types comply to the same specifications.  A private registry enables you to publish and test your internal e-business applications in a secure, private environment.

  • A public registry is a collection of peer directories that contain information about businesses and services. It locates services that are registered at one of its peer nodes and facilitates the discovery of published Web services. Data is replicated at each of the registries on a regular basis. This ensures consistency in service description formats and makes it easy to track changes as they occur. IBM® maintains two public registries called the IBM UDDI Business Registry and the IBM UDDI Test Registry. The IBM UDDI Test Registry allows you to develop your Web service and experience the UDDI registration process without placing your Web service in an official registry. Use the IBM UDDI Test Registry to experiment with UDDI, and to test and validate your Web service.

  • A private registry allows you to publish and test your internal applications in a secure, private environment.

  • The UDDI Business Registry acts as a B2B directory linking marketplaces, buyers, and sellers. The information provided in the registry consists of three components: white pages, yellow pages, and green pages. White pages include the business name, contact information, and a text description of the business's services. Yellow pages include industrial categorizations based on standard taxonomies such as NAICS, ISO 3166, and UNSPSC. Green pages include references to specifications for Web services and pointers to various file and URL-based discovery mechanisms. This makes it easy for businesses to integrate across marketplaces. Because it is registered, information is made available across all applications.

  • Businesses populate the registry with descriptions of the services that they support. UDDI assigns a unique identifier to each service description and business registration. These become the service and business keys respectively. Search engines, and applications query the registry to discover services. UDDI servers are a directory of available services and service providers.

WSDL#

  • WSDL stands for Web Service Description Language, WSDL is an XML notation for describing a web service. A WSDL definition tells a client how to compose a web service request and describes the interface that is provided by the web service provider.
  • A WSDL definition is divided into separate sections that specify the logical interface and the physical details of a web service. The physical details include both endpoint information, such as HTTP port number, and binding information, which specifies how the SOAP payload is represented and which transport is used.
  • WSDL is an important component for building web applications. It facilitates various applications that are built on multiple languages to interact with each other. WSDL is used as the combination of SOAP and XML schemas that provide communication between the clients and web services over the internet. To read the WSDL file, the client program must connect to the Web service and specify the operation required to connect to the Web server.
  • WSDL Document Elements
Element Description
Definitions It is the basic element of the WSDL document that contains the definition of one or more services.
Types The Type element is used to give information about the complicated data types used within the WSDL document.
Message It contains abstract data that is being used in communication between client and web server. It also defines the data elements for each operation.
portType It contains the collection of abstract operation supported by one or more endpoints.
Port It is used to define the single endpoint as an address for the binding.
Services It is a collection of endpoint networks that specify the port address for the binding.
Binding It specifies how operations are implemented by concrete protocols and data format features for operation and messaging.
  • Structure of WSDL Document
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<definitions>  
    <types>  
        Definition of types goes here.  
     </types>  

    <message>  
     Definition of a message goes here.  
    </message>  

    <portType>  
        <operation>  
             Definition of an operation goes here.  
        </operation>  
    </portType>  

    <binding>  
     Definition of a binding goes here.  
    </binding>  

    <service>  
    Definition of service goes here.  
    </service>  

</definition>
  • We can also add other elements such as extension elements and service elements combined into a single WSDL document with possible definitions of multiple web services.

  • The following are the four major transmissions of the WSDL that support endpoint in the SoapUI tool.

    • One Way
    • Request and Response
    • Solicit response
    • Notification

  • One way: A one-way service can only receive one-way messages. It means that the client can send a request to the server by executing an operation with a single input element.

1
2
3
4
5
6
7
<wsdl:definitions .... >    
   <wsdl:portType name="getListCountriesSoap">  
      <wsdl:operation name = "getCountries ">   
<wsdl:input message="tns:getCountriesSoapIn"/>  
      </wsdl:operation>   
   </wsdl:portType >   
</wsdl:definitions>
  • Request and Response: The Request and Response service is used to send a request to the server and receive a response from the web server. It has two operation elements. The first input element is followed by another element to send and receive the request and response in the web service.
1
2
3
4
5
6
7
8
<wsdl:definitions ?.>  
<wsdl:portType name="getListCountriesSoap">  
<wsdl:operation name="getCountries">  
<wsdl:input message="tns:getCountriesSoapIn"/>  
<wsdl:output message="tns:getCountriesSoapOut"/>  
</wsdl:operation>  
</wsdl:portType>  
</wsdl:definitions>
  • Solicit Response: A solicit response consists of an operation involving two input elements. The first input element contains a server request for the client, followed by one input element of the client's response back to the server.
1
2
3
4
5
6
7
8
9
<wsdl:definitions ?.>  
<wsdl:portType name="getListCountriesSoap">   
<wsdl:operation name="getCountries" parameterOrder ="getListCountries">  
<wsdl:output name="getCountries"? message="tns:getCountriesSoapOut"/>  
<wsdl:input name="getCountries"? message="tns:getCountriesSoapIn"/>  
<wsdl:fault name = " getCountries " message = "tns:getCountries"/>  
</wsdl:operation>  
</wsdl:portType>  
</wsdl:definitions>
  • Notification: A server sends information or message to a client machine. Therefore, a notification consists of an operation that includes an input element to send a notification to the client.
1
2
3
4
5
6
7
<wsdl:definitions .... >   
   <wsdl:portType name="getListCountriesSoap" >   
      <wsdl:operation name = " getCountries ">   
         <wsdl:output name = " getCountries "? message = " tns:getCountriesSoapOut "/>   
      </wsdl:operation>   
   </wsdl:portType >   
</wsdl:definitions>
  • Example of an WSDL file is showed as below.
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                  xmlns:tns="http://www.cleverbuilder.com/BookService/"
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                  name="BookService"
                  targetNamespace="http://www.cleverbuilder.com/BookService/">
  <wsdl:documentation>Definition for a web service called BookService,
    which can be used to add or retrieve books from a collection.
  </wsdl:documentation>

  <!--
      The `types` element defines the data types (XML elements)
      that are used by the web service.
   -->
  <wsdl:types>
    <xsd:schema targetNamespace="http://www.cleverbuilder.com/BookService/">
      <xsd:element name="Book">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="ID" type="xsd:string" minOccurs="0"/>
            <xsd:element name="Title" type="xsd:string"/>
            <xsd:element name="Author" type="xsd:string"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="Books">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element ref="tns:Book" minOccurs="0" maxOccurs="unbounded"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>

      <xsd:element name="GetBook">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="ID" type="xsd:string"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="GetBookResponse">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element ref="tns:Book" minOccurs="0" maxOccurs="1"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>

      <xsd:element name="AddBook">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element ref="tns:Book" minOccurs="1" maxOccurs="1"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="AddBookResponse">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element ref="tns:Book" minOccurs="0" maxOccurs="1"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="GetAllBooks">
        <xsd:complexType/>
      </xsd:element>
      <xsd:element name="GetAllBooksResponse">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element ref="tns:Book" minOccurs="0" maxOccurs="unbounded"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:schema>
  </wsdl:types>


  <!--
      A wsdl `message` element is used to define a message
      exchanged between a web service, consisting of zero
      or more `part`s.
   -->

  <wsdl:message name="GetBookRequest">
    <wsdl:part element="tns:GetBook" name="parameters"/>
  </wsdl:message>
  <wsdl:message name="GetBookResponse">
    <wsdl:part element="tns:GetBookResponse" name="parameters"/>
  </wsdl:message>
  <wsdl:message name="AddBookRequest">
    <wsdl:part name="parameters" element="tns:AddBook"></wsdl:part>
  </wsdl:message>
  <wsdl:message name="AddBookResponse">
    <wsdl:part name="parameters" element="tns:AddBookResponse"></wsdl:part>
  </wsdl:message>
  <wsdl:message name="GetAllBooksRequest">
    <wsdl:part name="parameters" element="tns:GetAllBooks"></wsdl:part>
  </wsdl:message>
  <wsdl:message name="GetAllBooksResponse">
    <wsdl:part name="parameters" element="tns:GetAllBooksResponse"></wsdl:part>
  </wsdl:message>

  <!--
      A WSDL `portType` is used to combine multiple `message`s
      (e.g. input, output) into a single operation.

      Here we define three synchronous (input/output) operations
      and the `message`s that must be used for each.
   -->
  <wsdl:portType name="BookService">
    <wsdl:operation name="GetBook">
      <wsdl:input message="tns:GetBookRequest"/>
      <wsdl:output message="tns:GetBookResponse"/>
    </wsdl:operation>
    <wsdl:operation name="AddBook">
      <wsdl:input message="tns:AddBookRequest"></wsdl:input>
      <wsdl:output message="tns:AddBookResponse"></wsdl:output>
    </wsdl:operation>
    <wsdl:operation name="GetAllBooks">
      <wsdl:input message="tns:GetAllBooksRequest"></wsdl:input>
      <wsdl:output message="tns:GetAllBooksResponse"></wsdl:output>
    </wsdl:operation>
  </wsdl:portType>

  <!--
      The `binding` element defines exactly how each
      `operation` will take place over the network.
      In this case, we are using SOAP.
   -->
  <wsdl:binding name="BookServiceSOAP" type="tns:BookService">
    <soap:binding style="document"
                  transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="GetBook">
      <soap:operation
              soapAction="http://www.cleverbuilder.com/BookService/GetBook"/>
      <wsdl:input>
        <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <soap:body use="literal"/>
      </wsdl:output>
    </wsdl:operation>
    <wsdl:operation name="AddBook">
      <soap:operation
              soapAction="http://www.cleverbuilder.com/BookService/AddBook"/>
      <wsdl:input>
        <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <soap:body use="literal"/>
      </wsdl:output>
    </wsdl:operation>
    <wsdl:operation name="GetAllBooks">
      <soap:operation
              soapAction="http://www.cleverbuilder.com/BookService/GetAllBooks"/>
      <wsdl:input>
        <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <soap:body use="literal"/>
      </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>

  <!--
      The `service` element finally says where the service
      can be accessed from - in other words, its endpoint.
   -->
  <wsdl:service name="BookService">
    <wsdl:port binding="tns:BookServiceSOAP" name="BookServiceSOAP">
      <soap:address location="http://www.example.org/BookService"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

References#