WEB SERVICES word wide web www In the

WEB SERVICES

word wide web (www) • In the past years the www had a very large success basically for two reasons: - Simplicity - Ubiquity • . • • For a service provider is simple to contact a great number of users. For a user is simple to access a service everywhere it is located. However, www is strongly oriented to the interaction among users and systems.

Interaction among distributed computing applications • The evolution of the internet and web utilization made necessary the demand of interactions among applications in different scenarios: – A program of business management must be able to integrate the local informations with those made available on Internet by suppliers, banks or public administrations. – An application used by estate agents must access real time informations caming from wordwide finantial markets. – The library management system can look for a book either in the local catalog or in those of a larger library management system (University, local goverment, …)

Web limitations • The web model is not suitable to the management of the interactions among applications. • It is based on a very simple model: - the user, using a browser, sends a URL to a server. - the web server returns a HTML page that is graphically displayed by the browser. • In a interaction between two applications this scheme presents two critical aspects: – The URL are a very simple tool in order to express complex and articulated requests. – HTML is a language basically used to describe how documents may be displayed.

URL (Uniform Resource Locator) Every resource accessible over the web has a URL that identifies the location of the resource ( a file if the resource is a document or a program if the resource is a program that will produce the document) and describes how to access it. The URL provides the name of a protocol to be used to access the resource, an address (which can be a domain name or an IP address) of a machine where the resource is located and a hierarchical description of the location of the resource on the machine (directory path)

A new model • In order to overcome the previously described difficulties a new model has been developped: web services. • An evolutive approach has been choosen: - HTTP as application protocol in order to reuse the previous infrastructure and to maintain the interaction model simplicity. - XML as a tool able to better describe the foundamental elements of the interaction, the request and the response.

web service definition “A WS is a software application described by a URI whose public interfaces and relative bindings are defined and described in XML. Its definition may be used by different software applications. These applications can interact with the WS following the directives present in the service definition, using XML messages and internet transport protocols. “ (“Web Services Architecture” http: //www. w 3 c. org/TR/2002/WD-ws-arch-20021114)

• web services work on assumption that the functionality made available by a company will be exposed as a service. • In middleware terms, a service is a procedure, method, or object vith a stable, published interface that can be invoked by clients. • The invocation, and this very important, is made by a program. Thus, requesting and executing a service involves a program calling another program. • Web services assume that services are loosely coupled, since in general they are defined, developed and managed by different companies

• The interface hides the implementation details of the service (hardware, software, programming language). • A web service corrisponds to a specific action or to a set of actions. • It may be used by oneself or with other web services to implement a complex transaction.

A web service is defined as: a standardized way of integrating Web-based applications using XML, SOAP, WSDL and UDDI open standards over an Internet backbone: XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the service available, UDDI is used for listing what services are available.

Web Services – Technologies • SOAP – Simple Object Access Protocol – Provides a standard packaging structure for transporting XML documents over a variety of standard Internet technologies, including HTTP. • WSDL – Web Services Definition Language – XML thechnology that describes the interface of a web service in a standardized way. WDSL standardizes how input and output parameters can be represented and the function’s structure. WDSL allow disparate clients to automatically understand how to interact with a web service. • UDDI – Universal Description, Discovery and Integration – UDDI provides a wordwide registry of web services. UDDI is used to discover available web services by searching for names, identifiers, categories.

Not every service available through the web is a web service. Examples: bookstores, restaurants or travel agencies. They all provide services. In some cases a customer might even to obtain such services through the web servers of the company. This is not what web services are about. A web service is a software application with a published stable programming interface , not a set of web pages.

Integration problem Each part (customer, supplier, warehouse) exposes its internal operations as web services, which therefore acts as entry points to the local information systems. The interactions between companies occur in peer-to-peer fashion and take place through standardized protocols. Web services and their technology are being developed with one specific use in mind: that of being entry points to the local information systems. The primary use of web services is that of exposing the functionalty performed by internal systems and making it discoverable and accessible through the web in a controlled manner

The Web Services Model Service Description Service Pu b Service Description nd Service Registry Bi lis h Service Producer WSDL, UDDI Find WSDL, UDDI Service Consumer

Roles in a web services architecture Service producer. It is the service owner. From the architectural point of view it represents the node containinig the service. Service consumer It is the application which is calling the service . A service consumer may be a browser or an application (ex. , another web service) Service register It is a register which contains the descriptions of the services published because the request of a producer and requested by the service consumers.

Operations in a web services architecture • Publish To be accessible a service description must be published allowing a service consumer to find. • Find The find operation may happens in two different phases: during the design of the service to look for the interface descrition, at run time to implement the binding of the request service. • Bind It is the operation by which the service is localized

• The service consumer links up to a UDDI register (internet or intranet) • It looks up (by cathegories, providers, ecc…) the requested service (example: web service providing stock rates) • It finds the service description ( its functional aspects, the address of the server containing the service, how it is possible to call it) • It connects himself to the provider server and utilizes the service. • The service consumer is a software application The web services are web applications that provide services to others web applications

• The client queries a UDDI registry for the service either by name, category, identifier. Once located, the client obtains information about the corresponding WSDL document. • The WSDL document contains information about how to contact the web service and the format of request messages in XML schema. • The client creates a SOAP message in accordance with the XML schema found in WSDL and sends a request to the host (where the service is).

Web Services have Two Types of Use • Reusable application-components. There applications needed very often. So why make these over and over again? Web services can offer application-components like: currency conversion, weather reports, or even language translation as services. • Connect existing software. Web services can help to solve the interoperability problem by giving different applications a way to link their data. With Web services you can exchange data between different applications and different platforms.

• Bank Currency Exchange service (Euro/dollar exchange. ) Our application can utilize the service without worrying about the rates in force at the time of the operation. • With a simple connection to the currency exchange service, it’s possible to known the operations made available and how it is possible to use them. • This characteristic of web services is particularly usefull if you consider that the services can be found by using the UDDI directory service , available on the web, where it is possible to register and look for web services.

UDDI • UDDI rougly represents the equivalent of an on line book phone that enable the finding of web services • UDDI offers 3 services whose names are typical of the telephony word. – White pages: finding a service by name – Yellow pages: finding a service by category – Green Pages: give technical informations on the services provided by a particular company. • A UDDI service provider (IBM, Microsoft, SAP ecc. ) manages an register called UBR (UDDI Business Registry) that is accessible for publishing and finding the web services

• • WDSL Trough WSDL the public interface of a web service (based on XML) can be described A WSDL document contains, relatively to the described web service, informations on: What can be utilized (the “operations” provided by the service); How it can be utilized (the communication protocol to access the service, the input, output messages format and the relative types of data). Where the service is located (the service endpoint, that is the service address –URI format- that makes available the web service ). The web service operations and messages are described in an abstract way , that is not bound to a particular network protocol and to a particular format.

The WSDL Document Structure A WSDL document describes a web service using these major elements: Element <types> <message> <port. Type> <binding> Description A container for data type definitions used by the web service A typed definition of the data being communicated A set of operations supported by one or more endpoints A protocol and data format specification for a particular port type

The <port. Type> element is the most important WSDL element. • It describes a web service, the operations that can be performed, and the messages that are involved. The <port. Type> element can be compared to a function library (or a module, or a class) in a traditional programming language. • WSDL Messages The <message> element defines the data elements of an operation. Each message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language. • WSDL Types The <types> element defines the data types that are used by the web service. For maximum platform neutrality, WSDL uses XML syntax to define data types. • WSDL Bindings The <binding> element defines the data format and protocol for each port type.

The main structure of a WSDL document looks like this: <definitions> <types> data type definitions. . . . </types> <message> definition of the data being communicated. . </message> <port. Type> set of operations. . . </port. Type> <binding> protocol and data format specification. . </binding> </definitions> A WSDL document can also contain other elements, like extension elements, and a service element that makes it possible to group together the definitions of several web services in one single WSDL document.

Example <message name="get. Term. Request"> <part name="term" type="xs: string"/> </message> <message name="get. Term. Response"> <part name="value" type="xs: string"/> </message> <port. Type name="glossary. Terms"> <operation name="get. Term"> <input message="get. Term. Request"/> <output message="get. Term. Response"/> </operation> </port. Type>

• In this example the <port. Type> element defines "glossary. Terms" as the name of a port, and "get. Term" as the name of an operation. • The "get. Term" operation has an input message called "get. Term. Request" and an output message called "get. Term. Response". • The <message> elements define the parts of each message and the associated data types. Compared to traditional programming, glossary. Terms is a function library, "get. Term" is a function with "get. Term. Request" as the input parameter, and get. Term. Response as the return parameter.

WSDL binding and service <binding type="glossary. Terms" name="b 1"> <soap: binding style="document" transport="http: //schemas. xmlsoap. org/soap/http" /> <operation> <soap: operation soap. Action="http: //example. com/get. Term"/> <input><soap: body use="literal"/></input> <output><soap: body use="literal"/></output> </operation> </binding>

• The binding element has two attributes - name and type. • The name attribute defines the name of the binding, and the type attribute points to the port for the binding, in this case the "glossary. Terms" port. • The soap: binding element has two attributes - style and transport. • The style attribute can be "rpc" or "document". In this case we use document. The transport attribute defines the SOAP protocol to use. In this case we use HTTP. • The operation element defines each operation that the port. Type exposes. • For each operation the corresponding SOAP action has to be defined. You must also specify how the input and output are encoded. In this case we use "literal".

The last part of the document describes the service and its web address. <service name=“get. Term. Service"> <port name=“glossary service“ binding="tns: Stock. Quote. Binding"> <soap: address location="http: //www. glossary service. com"/> </port> </service>

SOAP Building Blocks A SOAP message is an ordinary XML document containing the following elements: • An Envelope element that identifies the XML document as a SOAP message • A Header element that contains header information • A Body element that contains call and response information • A Fault element containing errors and status information All the elements above are declared in the default namespace for the SOAP envelope: http: //www. w 3. org/2001/12/soap-envelope and the default namespace for SOAP encoding and data types is: http: //www. w 3. org/2001/12/soap-encoding

Skeleton SOAP Message <? xml version="1. 0"? > <soap: Envelope xmlns: soap="http: //www. w 3. org/2001/12/soap-envelope" soap: encoding. Style="http: //www. w 3. org/2001/12/soapencoding"> <soap: Header>. . . </soap: Header> <soap: Body>. . . <soap: Fault> . . . </soap: Fault> </soap: Body> </soap: Envelope>

<? xml version="1. 0"? > • This line with special symbols and attributes is what is referred to as the XML declaration. It simply states what version of XML you are using and the type of encoding you are using. The SOAP Envelope Element • The SOAP Envelope element is the root element of a SOAP message. This element defines the XML document as a SOAP message. The SOAP Header Element • The optional SOAP Header element contains applicationspecific information (like authentication, payment, etc) about the SOAP message.

The SOAP Body Element The required SOAP Body element contains the actual SOAP messages intended for the ultimate endpoint of the message. Example: <? xml version="1. 0"? > <soap: Envelope xmlns: soap="http: //www. w 3. org/2001/12/soap-envelope" soap: encoding. Style="http: //www. w 3. org/2001/12/soap-encoding"> <soap: Body> <m: Get. Price xmlns: m="http: //www. w 3 schools. com/prices"> <m: Item>Apples</m: Item> </m: Get. Price> </soap: Body> </soap: Envelope>

A SOAP response could look something like this: <? xml version="1. 0"? > <soap: Envelope xmlns: soap="http: //www. w 3. org/2001/12/soap-envelope" soap: encoding. Style="http: //www. w 3. org/2001/12/soap-encoding"> <soap: Body> <m: Get. Price. Response xmlns: m="http: //www. w 3 schools. com/prices"> <m: Price>1. 90</m: Price> </m: Get. Price. Response> </soap: Body> </soap: Envelope>

• XML Namespaces provide a method to avoid element name conflicts. • In XML, element names are defined by the developer. This often results in a conflict when trying to mix XML documents from different XML applications. • Name conflicts in XML can easily be avoided using a name prefix. • When using prefixes in XML, a so-called namespace for the prefix must be defined. • The namespace is defined by the xmlns attribute in the start tag of an element. • The namespace declaration has the following syntax. xmlns: prefix="URI".

Web Services: summary • Web services are autonomous applications, modular and self describing that can be published, retrieved and called. • Allow to implement interactions among applications in. Internet. • A web service is constituded by three elements: – A mechanism of pubblication and research : UDDI – A mechanism of description: WSDL – A mechanism of calling: SOAP

• WSDL stands for Web services description language WSDL is a XML-based language for describing Web services Wsdl is a W 3 C recomandation • SOAP Soap stands for Simple Object Access Protocol Soap is an XML based protocol for accessing web services Soap is a W 3 C recomandation • UDDI stands for Universal Description, Discovery and Integration UDDI is a directory service where companies can search for Web services UDDI described in XML UDDI communicates via SOAP

Principali motivi per utilizzare o sviluppare web services • I web services permettono l’interoperabilità tra diverse applicazioni software e su diverse piattaforme H/S • Utilizzano un formato dei dati di tipo testuale, quindi più comprensibile e più facile da usare per gli sviluppatori • Normalmente essendo basati sul protocollo HTTP, non richiedono modifiche alle regole di sisicurezza utilizzate come filtro dai firewall (porta 80) • Sono semplici da utilizzare e possono essere combinati l’uno con l’altro (indipendentemente da chi li fornisce e da dove vengono resi disponibili) per formare servizi integrati e complessi. • Permettono di riutilizzare applicazioni già sviluppate

• Fintanochè l’interfaccia rimane costante le modifiche effettuate ai servizi rimangono trasparenti • I servizi web sono in grado di pubblicare le loro funzioni e di scambiare dati con il resto del mondo • Tutte le informazioni vengono scambiate attraverso protocolli aperti

Problemi • I web services presentano performance drasticamente inferiori rispetto ad altri metodi di comunicazione disponibili in rete. Questo svantaggio è legato alla natura stessa dei servizi web. Essendo basati su XML ogni trasferimento di dati richiede l’inserimento di un notevole numero di dati supplementari (i tag XML) indispensabili per la descrizione della operazione. Inoltre tutti i dati inviati richiedono di essere prima codificati e poi decodificati ai capi della connessione. Queste due caratteristiche dei web service li rendono poco adatti a flussi di dati intensi o dove la velocità dell’applicazione rappresenti un fattore critico.

• E’ necessario disporre di un’applicazione terza che gestisca le richieste HTTP oppure è necessario includerla direttamente nel codice del nostro programma qualora si desideri la sua totale indipendenza. Va detto comunque che generalmente il codice che implementa un web service viene fatto eseguire da un Web server (es. Apache) tramite CGI (per es. con Pyton) o tramite appositi moduli (es. PHP) Eseguendo il codice del web service attraverso un server web la gestione di HTTP è immediatamente assicurata.