The web service protocols

From
Jump to navigation Jump to search

SOAP

SOAP is...

  • the abbreviation for Simple Object Access Protocol

The protocol serves as a distributed object protocol such as RMI or CORBA-IIOP. Thus, whereas RMI is based on the Java platform, and CORBA-IIOP requires the CORBA infrastructure to exchange messages, SOAP is platform and language independent.

  • a standard, proposed to the W3C consortium in May 2000 by companies like Ariba, HQ, IBM, Microsoft
  • an opportunity to support different transport protocols.

Originally, SOAP was accomplished to transfer messages via http and therefore take advantage of the internet. (Firewalls and proxi servers normally do not block http traffic via port 80) Nevertheless, SOAP can be used with other protocols such as ftp, smtp as well.

A SOAP message is...

  • an ordinary XML document, which integrates the SOAP XML Schema by using namespaces.

It consists of three basic elements:

<envelope>: Root, identifies XML documents as a SOAP message

<header>: (optional) infrastructure data

<body>: application data 

<?xml version='1.0' encoding='UTF-8'?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header />
 <env:Body>
   <reservation xmlns="http://www.taxi.com/TaxiReservation">
      <customer>
  	...
      </customer>
   </reservation>
 </env:Body>
</env:Envelope>


WSDL

WSDL stands for Web Service Description Language. As the name already indicates, it is a XML markup language that describes a Web Service. Comparable to the IDL (Interface Definition Language) in CORBA, it can be used for generating web services interfaces, stubs and deployment information.

Just like the advantage of SOAP is its independence of transfer protocols, programming language and platform, WSDL promises to be protocol agnostic. Though wsdl files are normally generated automatically by tools such as AXIS, bugs and deployment problems force developers to understand the different WSDL pieces.

A WSDL document itself comprises the elements described in the following.

<definitions>

This element is the root element. It declares all needed namespaces.

The default namespace is the WSDL Schema. Furthermore, the prefix “soap” is assigned to the SOAP Schema and “xsd” to the XML Schema Language. Therefore, you can integrate SOAP relevant elements and the XML Schema elements (e.g. <complexType> in the wsdl document. Finally the wsdl schema itself needs an identifier, which is declared with the targetNamespace attribute. 

<? xml version = '1.0'?>
 <definitions name = "TaxiAgent"
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:titan="http://www.taxi.com/TaxiAgent"
     targetNamespace="http://www.taxi.com/TaxiAgent"
 ...

<message>

Definition of parameters and return values. 

<message name ="RequestMessage">
  <part name="taxiId" type="xsd:int" />
  <part name="customerId" type="xsd:int"/>
  <part name="carId" type="xsd:int"/>
  <part name="price" type="xsd:double"/>
</message>
<message name="ResponseMessage">
  <part name="reservationId" type="xsd:string" />
</message>

<types>

Allows to declare complex types. Other parts of the WSDL document as well as different WSDL documents can refer to them. 

<types>
  <xsd:schema
     targetNamespace="http://www.taxi.com/TaxiAgent">
     <xsd:complexType name="ReservationType">
        <xsd:sequence>
           <xsd:element name="taxiId" type="xsd:int"/>
           <xsd:element name="carId" type="xsd:int"/>
           <xsd:element name="customerId" type="xsd:int"/>
           <xsd:element name="price" type="xsd:double"/>
        </xsd:sequence>
     </xsd:complexType>
  </xsd:schema>
</types>

<portType>

Describes the web service operations (Java methods) that are available.

The element <operation> declares the method, <input> and <output> refer to the parameters declared in the <message> part. SOAP error messages (analogously to Java exceptions) can be expressed by the <fault> element.

You can distinguishes different messaging styles:

Request/Response: the <operation> element contains a single input and output element, eventually fault element.

Single input: Can be used for asynchronous messaging to send XML documents; just a single input is defined. 

<binding name ="TaxiAgentBinding" type="taxi:TaxiAgent">
  <soap: binding style = "rpc"
    transport="http.//schemas.xmlsoap.org/soap/http"/>
  <operation name="makeReservation">
     <soap:operation soapAction="" />
     <input>
       <soap:body use="literal"
         namespace="http://www.taxi.com/TaxiAgent"/>
     </input>
     <output>
      <soap:body use="literal"
        namespace="http://www.taxi.com/TaxiAgent"/>
    </output>
   </operation>
</binding>

UDDI

The “Universal Description, Discovery and Integration” Protocol describes a standard for publishing and discovering web services. Though from a J2EE perspective, the protocol is not considered as fundamental as SOAP and WSDL, it is still a constituent of web services.

You can imagine UDDI as a registry containing white (identification by the company’s name), yellow (searching by business/product category) and green pages (look up using technical entities). The registry itself is a web service which can be accessed, searched and updated via SOAP messages.

Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=The_web_service_protocols&oldid=3207"