PA165/WebServices (English)

Z FI WIKI
Verze z 3. 12. 2013, 10:42; 232464@muni.cz (diskuse | příspěvky)

(rozdíl) ← Starší verze | zobrazit aktuální verzi (rozdíl) | Novější verze → (rozdíl)
Přejít na: navigace, hledání


Web Services

The English term Web Services is equivalent to the Czech "webové služby" and it is still used historically, although today it can be misleading, because services are not only provided via web. In addition, such term can create confusion for the fact that a company can create and manage a website for the provision of services for its own business activities. Still, web services is the main term used.

The main aim of Web Services was to increase the interoperability on the web, making possible for programs running on different platforms (JavaScript, Java, C, MS. NET, mobile phones) to communicate together and provide global services.

The Web Services technology is composed of three parts:

  • a protocol for remote procedure call, called SOAP, that transmits data written as XML;
  • a description language for services, called WSDL;
  • a mechanism for finding services;

1  SOAP

SOAP (Simple Object Access Protocol - in Czech jednoduchý protokol pro přístup k objektům) is perhaps best explained by following the process of creation as it historically occurred. Since the beginning of the WWW (around 1993) to call a program on the web server and pass some text parameters to the URL we could use the character ?, separating the different parameters with the & character, for example:

http://nekde.cz/cgi/p.exe?param1=hodnota1&p2=h2

This method has one big limitation, that is the maximum length of the URL, considering in practice a limit of 2048-4096 characters (2KB-4KB) - although many browsers and libraries will fail way before reaching this limit. For this reason, there was the usage of the POST method of the HTTP protocol, so that the parameters are passed within the body of the HTTP request. Here it is an example of how such a call looks like:

POST /cgi/p.exe HTTP/1.0

Content-Type: application/x-www-form-urlencoded
Content-Length: 21

param1=hodnota1&p2=h2

With the POST method, it is possible to transmit any data of any length. The standard format at the time was called application/x-www-form-urlencoded, with the same representation of parameters as the one passed directly to the URL.

Over the time (around 1997) browsers started supporting the multipart/form-data content type, that allows to add as text parameters also file contents.

With the introduction of XML, that allows to write arbitrarily complex structured data to a text file and in a platform-independent manner, it was only a matter of time before someone thought to send with the POST method data in XML format. XML has the advantage that the transmitted data may not only limited to the text but it is possible to pass a complex object or collection of objects (XML Schema, XML Namespaces). We have now libraries such as JAXB, Java API for XML Binding that can support programmatically the marshalling and unmarshalling of Java classes to XML representation.

1.1  Creation of the Standard

The first of such protocols based on XML data, was called SOAP and was developed by Microsoft starting in 1998. The project was later joined by many other companies, including IBM. Other firms have developed similar protocols with names such as XML-RPC, WDDX and XMI. The W3C consortium took note of the SOAP 1.1 specification in May 2000 and immediately set up a working group called XML Protocol Working Group for the development of a unifying protocol with name XMLP. This group produced a protocol called SOAP 1.2, that was set in 19.12.2002 in form of a candidate recommendation status.

Currently, there are dozens of different implementations of SOAP on a variety of platforms, from C/C++, to Java.NET, Perl and Mozilla JavaScript in your browser. Their mutual compatibility is regularly tested at SOAPBuilders Interoperability Lab.

1.2  Example of a Call

Here is an example of how a SOAP call actually looks like. For example, assume boolean jePrvocislo(long cislo), which has a numerical parameter named cislo and returns true depending on whether the parameter is a prime number or not. Since the Web service can be implemented in any programming language, types long and boolean types are defined in XML Schema and not necessarily present in a particular programming language.

SOAP requires that the name of each function is related to a certain namespace. In object-oriented languages ​​that namespace corresponds to object and its function to a method, this namespace does not have a direct sense, but it is necessary to define a context. The namespace URI is determined by a <a href="#pozn10" name="zpet10" class="pozn">10</a>, so let us choose it to be urn:mojeURI. An example of SOAP messages calling such a function is shown below.

<env:Envelope
  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
  env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:xs="http://www.w3.org/1999/XMLSchema"
  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
 <env:Header/>
 <env:Body>
  <m:jePrvocislo xmlns:m="urn:mojeURI">
    <cislo xsi:type="xs:long">1987</cislo>
  </m:jePrvocislo>
 </env:Body>
</env:Envelope>
Figure 1: Example of SOAP messages to call the function
 

This message is transmitted to the server usually using POST with the HTTP protocol. The process that the server uses to identify the function to be called depends on the implementation of the server - the function is usually identified by its name and namespace. Other possible options are: using the URL that came from the HTTP request, using the content of the special HTTP header SOAPAction, using a user-defined tag content env:Header, or something else. SOAP is open and does not prescribe a compulsory way.


<env:Envelope
  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/1999/XMLSchema">
 <env:Body>
  <ns1:jePrvocisloResponse
    xmlns:ns1="urn:mojeURI"
    env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <return xsi:type="xsd:boolean">true</return>
  </ns1:jePrvocisloResponse>
 </env:Body>
</env:Envelope>
Figure 2: Example of SOAP messages returning result

2  WSDL

WSDL (Web Services Description Language, in Czech jazyk popisu webových služeb) is used to describe Web services based on XML standards and by using large XML Namespaces and XML Schema. It was created by merging three languages ​​provided by IBM, Microsoft and Ariba named NASSL, SCL and SDL in one unique language called WSDL 1.1. W3C took note of WSDL 1.1 and established a working group called Web Services Description Working Group, that then released a newer version of WSDL 1.2 and now it is in use since WSDL version 2.0 (2004).


2.1  Structure of a WSDL Document

The WSDL language is very general, in order to maintain platform independence. Let us describe how such a description of the Web service looks by using WSDL. A WSDL document contains a description of one service (keyword service, see Figure 3), which is the largest unit. Each service has one or more ports (port). Each port has a binding, a way to call a specific port (such as SOAP-over-HTTP), and an access address (URL). It is therefore theoretically possible to have one service with more ports with different bindings, ie one service call in various ways, eg first SOAP-over-HTTP, second SOAP-over-HTTP-over-SSL and third SOAP-over-SMTP.

<message name="jePrvocisloRequest">
 <part name="cislo" type="xsd:long"/>
</message>
<portType name="Cisla">
 <operation name="jePrvocislo" parametrOrder="cislo">
  <input message="m:jePrvocisloRequest" name="jePrvocisloRequest"/>
  <output message="m:jePrvocisloResponse" name="jePrvocisloResponse"/>
 </operation>
</portType>
<binding name="cislaSoapBinding" type="m:Cisla"> ... </binding>
<service name="CislaService">
 <port binding="m:cislaSoapBinding" name="cisla">
  <wsdlsoap:address location="http://nekde.cz/cisla"/>
 </port>
</service>
Part of the WSDL file defining jePrvocislo
 

Each operation typically defines two messages, one input and one output, but they can also be less. Each message contains zero, one or more parts, that correspond to the parameters, and the return values.

The types of parameters and return values ​​are defined using the XML Schema. As simple types are available strings (string), floating points number (float) and fixed decimal (decimal), boolean values ​​(boolean), binary data (base64Binary), date (dateTime), time interval (duration) URL (anyURI); further all the derivates are available, enumeration, numeric intervals, negative numbers (negativeInteger), integers of various sizes (int, byte, short, long ). It is possible to define composite types as summaries or variants of other types, simple or complex, you can even define one type as an extension of the other, expressing object inheritance.

2.2  Tools for working with WSDL

The WSDL document fully describes a specific Web service. So, by having a WSDL description of the web service we can start using it. There are automated tools that generate the WSDL description code for calling services in a particular programming language, and this code can then be called in the same manner as a locally implemented function (we refer very often to such code as proxy or stub).

WSDL documents do not need to be written by hand, there are tools for generating code directly from the programming language. It is therefore advantageous to use a procedure in which we first describe only the interfaces of the functions (creating only interface in Java or function declarations in .h filed in the C language) and then use an automated tool to generate a WSDL description for a yet non-existent web services, other automated tool to generate code from a WSDL document and the calls for the implementation of the server. The last step is to just finish by inserting the custom functionality into the generated code.

3  UDDI and WSIL

While SOAP and WSDL are used in practice as the main standards, in the service discovery area the story is quite different. There are two main variants of the protocol for searching the web services.

Historically, the older UDDI (Universal Description, Discovery and Integration, in Czech univerzální popis, objevování a spojování) offers a public database (the so-called registry), where the web service provider can store descriptions of services and the user search. Two of such centralized databases are managed by IBM and Microsoft. But experience has shown that two-thirds of the records in these databases are invalid and therefore around 2006 both databases were abandoned. The second and main problem is that the database does not guarantee the credibility of the service providers.

The opposite mechanism addresses the discovery of web services with the WSIL language (Web Services Inspection Language, in Czech language jazyk přehlídky webových služeb), an alternative approach also developed by IBM and Microsoft. WSIL describes the services provided by a provider using the file name inspection.wsil that is always located in the root directory of the web server. This description is thus in a standard place and scanning services such as Google and Yahoo can offer the possibility to search for those files.

6  Links


Article derived from Martin Kuba, the original version here: http://www.ics.muni.cz/zpravodaj/articles/269.html