Serveis web

Si Internet ha tingut l’èxit que ha tingut ha estat gràcies a la creació de la World Wide Web. Però quan es va crear la web durant els anys vuitanta, la idea de manera com havien de ser les pàgines era molt diferent de l’actual. En el moment en què es van crear aquestes pàgines, estaven pensades només per mostrar informació estàtica. Per aquest motiu es va implementar un sistema senzill basat en dos protocols simples: HTTP i HTML.

El llenguatge de marques HTML és l’encarregat d’especificar de quina manera s’han de representar les pàgines.

HTTP és un protocol simple basat en ordres simples (GET, POST, PUT, HEAD, DELETE) que permeten recuperar un recurs mitjançant una simple petició. El protocol pot ser tan simple perquè el resultat és representat en local pel navegador. Un client des d’un navegador demana un arxiu i el servidor simplement l’envia (figura).

Figura Esquema de funcionament de la web

Un aspecte clau d’aquestes pàgines és que un cop representada la pàgina és l’usuari el que se l’ha de mirar i interpretar el contingut.

L’èxit d’Internet va començar a fer que la gent cada vegada demanés més de les pàgines web, que van començar a permetre la interacció amb els usuaris mitjançant el que s’anomenen pàgines web dinàmiques. La idea és que, en comptes de limitar-se a enviar un fitxer des del servidor web, es generi la pàgina segons la informació enviada per l’usuari.

Com que la tasca es fa en el servidor això no afecta gens cap dels protocols bàsics. El fet que la pàgina es generi per encàrrec no canvia gens el fet que en realitat es continuï enviant amb el protocol HTTP un arxiu HTML (figura).

Figura Web amb pàgines dinàmiques

Si ens ho mirem bé veurem que en realitat el que estan fent les pàgines web dinàmiques és oferir un servei. Es pot entrar en un cercador qualsevol o en una botiga d’Internet i escriure-hi una paraula i això generarà una llista de resultats. El web fa el servei de cercar i presentar els resultats i evita que sigui l’usuari qui ho hagi de fer.

Així, doncs, el web és un lloc ple de dades (com preus, articles, horaris de trens o imatges) i de serveis (com cercadors, jocs o botigues) que han estat causa de l’èxit d’Internet.

El problema del web actual està en el fet que la majoria de les pàgines que conté comparteixen una idea comuna: estan pensades perquè sigui una persona la que s’encarregui d’interpretar-ne el contingut.

Per a un programa la informació de les webs és realment complicada d’interpretar ja que els que han creat les pàgines les han creades pensant de quina manera es poden representar les dades, i no que aquestes dades s’hagin de processar.

La web programable

El que es coneix com la web programable és el mateix que la web normal però pensada per ser interpretada per programes.

En comptes d’estar basada en HTML està basada en documents de marques que puguin ser processats fàcilment per determinats programes (XML, JSON…) i, per tant, que serveixin perquè els programes puguin fer tasques automatitzades a partir de la informació que han recollit.

La idea és aconseguir que un programa d’ordinador, a partir d’una informació inicial -per exemple que es vol anar a “la platja a Roses”-, s’encarregui automàticament de comprovar quin dia farà, de contractar el bitllet d’autobús i reservar una taula per dinar en un restaurant. I tot sense que calgui intervenció de l’usuari (figura).

Figura Contractar un viatge a Roses amb servei web

La idea és crear una web diferent de l’actual, que algú ha anomenat la web semàntica, que sigui comprensible per a les màquines i per als humans de manera que els programes hi pugin fer tasques automatitzades amb el mínim d’intervenció humana.

Els serveis web ens permeten crear programes amb components distribuïts que no tinguin cap problema per ser executats en qualsevol tipus de plataformes o de sistemes operatius. Això ho aconsegueixen basant-se fonamentalment en protocols estàndard i oberts.

Els serveis web

Microsoft va definir el terme servei web (Web services) l’any 2000 per descriure un conjunt d’estàndards que permetien als ordinadors comunicar-se per una xarxa. El nom prové d’aquí:

  • Web va sorgir perquè, tot i que tal com estan especificats aquests serveis no tenen cap problema per funcionar amb altres protocols, la comunicació es fa sobretot mitjançant el protocol HTTP.
  • La idea que hi ha al darrere de servei és que es pugui aconseguir que el sistema remot faci una tasca de manera que no calgui que aquesta tasca es faci en el sistema local.

Un servei web és un programari que ofereix una interfície per fer una tasca, que pot ser usat per altres sistemes independentment de quina plataforma i llenguatge faci servir.

Fent servir un llenguatge més proper als programadors també es podria definir un servei web com un mètode disponible remotament mitjançant una xarxa, mitjançant un protocol particular que normalment és l’HTTP.

Com que es vol que el sistema sigui multiplataforma cal que tots els sistemes entenguin i puguin interpretar correctament les dades que s’hi transmeten. Per aquest motiu el més corrent és que es faci servir un llenguatge de marques (XML, JSON…) per passar les dades d’un extrem a l’altre de la comunicació.

Característiques dels serveis web

Hi ha unes característiques que distingeixen els serveis web dels altres sistemes distribuïts:

  • Fan servir una infraestructura oberta.
  • Són interoperables.
  • Fan servir un disseny modular.

O sigui que es desenvolupen fent servir estàndards públics que siguin independents del fabricant (com per exemple amb els protocols HTTP o XML) de manera que s’afavoreix que s’hi pugui accedir des de pràcticament tots els sistemes i plataformes.

La interoperativitat garanteix que no importi en quin llenguatge de programació estiguin desenvolupats (C, C#, Java, Python, Perl…) ni tampoc des de quina plataforma es treballi (Windows, Linux…) ja que si poden interpretar les dades (i com que estan en un estàndard públic ho faran) poden operar entre si sense problemes.

El disseny modular és un altre aspecte clau, ja que permet que els serveis web es pugin integrar amb altres serveis per formar-ne de més grans i complexos, de manera que permet crear serveis complexos a partir de components més senzills i a més sense que sigui important en quines plataformes s’estiguin executant cadascun dels components.

Un programa pot ser descomposat en tasques més senzilles, algunes de les quals també les fan altres programes. Si es parteix d’un disseny modular es pot aprofitar el codi que executen aquests serveis per no haver de reprogramar-los una vegada i una altra.

La modularitat dels serveis web és un dels factors bàsics a l’hora de definir el que s’ha anomenat arquitectura basada en serveis (SOA).

Els serveis que s’ofereixen en els serveis web són diferents dels tradicionals a Internet, que principalment es basaven en el contingut, ja que en aquests serveis el que es genera són dades que poden ser usades per uns determinats programes per dur a terme tasques.

Tipus de serveis web

Segons el W3C hi ha dos grans tipus de serveis web: “[E]ls que són compatibles amb REST, que tenen com a objectiu principal manipular representacions XML de recursos fent servir un conjunt uniforme d’operacions sense estat; i els arbitraris, en què el servei exposa un conjunt arbitrari d’operacions.” De manera que tenim dos grans grups de serveis web:

  • Big Web services: serveis que exposen operacions perquè les facin servir els servidors. Estan basats en el protocol SOAP.
  • Web API: serveis basats en l’arquitectura REST -que basa el seu funcionament en els recursos-.

Big Web services

Els coneguts com a big Web services són serveis web que envien i reben la informació empaquetada en un format XML anomenat SOAP. Es poden definir a partir de tres funcions, tot i que no totes són estrictament necessàries per treballar:

  • Una manera de definir i transmetre els missatges.
  • Un llenguatge de definició de la manera com es poden fer servir els serveis.
  • Un sistema de descobriment de serveis.

Funcionament

Els big Web services es basen molt en XML, ja que fer servir aquest llenguatge en sistemes distribuïts aporta alguns avantatges amb els quals no es comptava anteriorment:

  • Es poden comunicar dos sistemes totalment diferents ja que XML garanteix la portabilitat. Com que les dades que s’envien són XML cap sistema no té problemes per entendre’n la informació.
  • En definir el que es vol fer i les respostes en SOAP no importa quin és el protocol de transport que es faci servir sinó la informació continguda en les dades XML.
  • Es poden definir els tipus de dades fent servir XSD (XML Schemas Definition) per definir les dades que s’han de passar entre sistemes. Això permet que es puguin fer comprovacions de tipus, que els programes sàpiguen quins tipus de dades han d’enviar o han de rebre…
  • Es poden expandir les possibilitats del protocol fent servir els espais de noms. Com qualsevol altre document XML es poden expandir les capacitats d’aquests protocols per afegir-hi funcionalitats mitjançant els espais de noms.

Format dels missatges

Per definir el format dels missatges que es transmeten es fa servir el protocol SOAP, que està basat en XML.

Per transportar aquests missatges se sol fer servir HTTP (protocol de transferència d’hipertext o hypertext transfer protocol) tot i que es poden fer servir altres protocols de transport com els de correu electrònic, FTP (protocol de transferència de fitxers o file transfer protocol) o BEEP (blocks extensible exchange protocol).

Definició del servei

Per poder fer servir un servei web que no s’ha fet servir mai i que fins i tot pot haver estat descobert automàticament és molt important disposar d’una manera de conèixer quins serveis ofereix i com s’ha de fer per usar-los.

La manera que tenen aquests serveis web de definir com s’ha de fer per poder usar el servei i quin serveis s’ofereixen és mitjançant un altre protocol anomenat WSDL (Web services description language), que també està basat en XML.

Descobriment de serveis

Si es pretén que els programes funcionin sols cal que tinguin alguna manera de poder descobrir serveis que no coneixien anteriorment de manera automàtica.

Es va definir UDDI (descripció, descoberta i integració universals o universal description, discovery and integration) per proporcionar la capacitat de permetre als programes descobrir serveis web que s’adeqüin a les necessitats que tinguin.

Altres protocols

A part dels que s’anomenen protocols bàsics, els big Web services disposen d’un grup més important de protocols per afegir noves funcions a SOAP.

Aquests protocols, el nom dels quals normalment comença per les lletres WS-, solen ser definits per tres organitzacions d’estàndard:

  • El World Wide Web Consortium (W3C).
  • L’Organization for the Advancement of Structured Information Standards (OASIS).
  • La Web Services Interoperatibility Organization (WS-I).

Aquestes organitzacions han definit més de cinquanta estàndards diferents per permetre definir qualsevol aspecte que afecti els serveis web com seguretat, gestió de serveis, gestió d’errors, o confiança entre els comunicants (taula).

Taula: Alguns dels estàndards serveis web
Estàndard Ús
WS-Discovery Defineix un protocol per descobrir serveis en la xarxa local.
WS-Addressing Defineix un mecanisme per transportar informació d’adreces.
WS-Security És una extensió per afegir seguretat a SOAP.
WS-Resource És una família d’especificacions que permeten manipular estructures de dades remotes.
WS-Reliability Permet assegurar l’enviament de missatges crítics.
WS-Policy Permet als serveis web definir les seves característiques de seguretat, qualitat de servei…
WS-Trust Afegeix extensions de seguretat per gestionar testimonis d’autenticació (Security-Token) i relacions entre els participants en un intercanvi segur.

Interoperativitat

Una de les crítiques que es fan a aquest tipus de serveis web és que el fet d’haver-hi tants estàndards definits per diferents organitzacions crea una dispersió que fa difícil poder oferir productes que garanteixin la tan volguda interoperativitat.

WS-I ara és membre d’OASIS tot i que no ha canviat el seu objectiu fonamental.

Per posar ordre al desgavell, un grup d’empreses el 2002 van crear una organització d’estàndards anomenada WS-I. Es tracta d’una organització que no té com a objectiu definir noves versions dels protocols, sinó que se centra a definir de quina manera es pot aconseguir desenvolupar serveis web interoperables. Per fer-ho va definint el que anomena perfils (profiles), que són una sèrie de normes i estàndards que s’han de fer servir per assegurar que el servei és compatible amb els altres.

Un dels perfils que defineixen i que és més usat és el WSI-BP (WSI Basic Profile) que només fa servir els protocols més elementals: SOAP, WSDL, WS-Addressing, UDDI. Amb el WSI-BP es limiten les possibilitats a l’hora de crear serveis web però s’aconsegueix que aquells que el compleixin siguin interoperables amb total seguretat. Moltes de les plataformes de generació de serveis web només creen Web services compatibles amb WSI-BP.

SOAP

SOAP va ser el primer estàndard de serveis web que es va desenvolupar i actualment és una recomanació del W3C tot i que originalment va ser desenvolupat per un grup d’empreses. És un acrònim de simple object access protocol (protocol d’accés d’objecte simple), però actualment aquest nom ha perdut sentit ja que ha quedat demostrat que SOAP no és simple, i a més no té gaire a veure amb l’accés a objectes.

Han anat sorgint diferents versions de SOAP al llarg dels anys i actualment se’n fan servir dues, les versions 1.1 i 1.2, l’especificació de les quals es pot trobar a la pàgina del W3C (www.w3.org/TR/soap).

És un entorn de missatges que permet la comunicació entre programes que corren en diferents servidors amb independència del llenguatge i del sistema operatiu en què funcionin. Un dels avantatges que aporta SOAP és que fa molt més simple la comunicació entre sistemes que estiguin en xarxes diferents del que es podia fer abans amb altres sistemes com CORBA o DCOM.

Aconsegueix la independència del llenguatge i de la plataforma basant els missatges en XML i s’aprofita que l’èxit de la web ha fet que tots els sistemes tinguin implementat el protocol HTTP (tot i que pot funcionar en altres protocols) per fer-lo servir per l’intercanvi de missatges.

A més de definir el format dels missatges també defineix quines són les regles que han de regir aquest intercanvi, què passa en cas d’error i com s’ha de lligar amb els altres protocols.

Amb els serveis web d’aquest tipus s’exposen tota una sèrie de funcions mitjançant les quals es poden fer programes que poden fer que el servei faci tasques determinades i retorni resultats amb els quals es pugui treballar.

Big Web services a OpenBravo

Per exemple, en el servei de vendes externes de l’ERP OpenBravo accessibles per mitjà de SOAP s’hi exposen les funcions següents:

  • getProductsCatalog (entitat, organització, origen, usuari, contrasenya).
  • uploadOrders (entitat, organització, origen, llistacomandes, usuari, contrasenya).
  • getOrders (entitat, organització, usuari, contrasenya, llistacomandes).

Es pot veure que els noms són prou explicatius de quina és la funció que ofereix cadascun dels serveis: obtenir el catàleg de productes d’una empresa, carregar comandes, i obtenir les comandes i veure en quin estat es troben.

Per tant, no és difícil fer un programa que comuniqui amb OpenBravo i que n’obtingui aquestes dades. Gràcies a això els clients d’OpenBravo poden desenvolupar programes externs que interactuïn amb el sistema.

Per tant, qualsevol missatge que s’enviï cap a un servei web va dins d’un missatge SOAP en el qual s’especifica quin és el servei que es vol fer servir i quines són les dades que s’hi envien.

Missatges SOAP

SOAP és un entorn de missatges basat en XML i per tant necessita definir tot allò que fa referència a la manera com s’han de gestionar els elements següents:

  • Tipus de missatges.
  • Format dels missatges.
  • Protocols de transport.
Tipus de missatges

L’estàndard SOAP defineix dos tipus de patrons de missatges:

El més habitual, que està basat en petició i resposta, que és l’habitual en el protocol HTTP (figura).

Figura Missatge SOAP de petició i resposta

I un altre tipus de només resposta, que l’estàndard anomena SOAP Response. La idea és que el servei respongui quan rep un missatge no SOAP amb una resposta SOAP (figura).

Figura Missatge SOAP de només resposta

Però els dos patrons també es poden combinar per aconseguir altres patrons, com definir missatges només d’entrada, o fins i tot establir una conversa.

Composició dels missatges

Un missatge SOAP és bàsicament un document XML i per tant ha de complir totes les normes de creació de documents XML. Per tant, ha de tenir un element arrel anomenat Envelope que serveix per identificar els missatges SOAP i la versió que es fa servir. La versió s’identifica a partir de l’espai de noms especificat. Vegeu els espais de noms de cada versió en la taula.

Dins de l’element arrel hi pot haver un element <Header> opcional i un <Body>, que és el que representa el contingut del missatge.

L’estàndard no defineix cap funció per a l’element <Header> però generalment se sol fer servir per donar informació o definir el contingut del missatge.

L’exemple següent és un missatge de petició SOAP que crida a una funció anomenada suma de l’espai de noms privat ioc que rep dos paràmetres, in i in2.

  1. <?xml version="1.0" ?>
  2. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  3. xmlns:ioc="http://ioc.xtec.cat/Bencalculat/">
  4. <soapenv:Header/>
  5. <soapenv:Body>
  6. <ioc:suma>
  7. <in>8</in>
  8. <in2>5</in2>
  9. </ioc:suma>
  10. </soapenv:Body>
  11. </soapenv:Envelope>

La resposta del servei web pot ser que el servei s’ha dut a terme i ha retornat el resultat següent:

  1. <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  2. <env:Body>
  3. <ns:sumaResponse xmlns:ns="http://ioc.xtec.cat/Bencalculat/">
  4. <ns:return>13</ns:return>
  5. </ns:sumaResponse>
  6. </env:Body>
  7. </env:Envelope>

O bé un error que es defineix amb l’element <Fault>, que sempre va dins de l’element <Body> i que representa diferents estats d’error:

  1. <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  2. <env:Body>
  3. <env:Fault>
  4. <env:Code>
  5. <env:Value>soapenv:Receiver</soapenv:Value>
  6. </env:Code>
  7. <env:Reason>
  8. <env:Text xml:lang="en-US">
  9. For input string: "A"
  10. </senv:Text>
  11. </env:Reason>
  12. <env:Detail/>
  13. </env:Fault>
  14. </env:Body>
  15. </env:Envelope>

Dins de l’element <Fault> hi ha sempre un codi i un text descriptiu de l’error que s’ha produït. És mitjançant els codis que es pot saber de quin tipus és el missatge d’error rebut (taula).

Taula: Codis d’error de SOAP 1.2
Codi d’error Significat
VersionMismatch Hi ha algun element invàlid o hi ha alguna cosa que no quadra (típic d’enviar missatges 1.1 a servidors 1.2).
MustUnderstand Un fill del Header no ha estat entès o no compleix les regles.
DataEncodingUnknown S’ha enviat la informació en un format amb el qual no és compatible.
Sender El missatge està format incorrectament o hi falten coses (per exemple, hi falta la identificació de l’usuari). En la versió 1.1 el nom era Client.
Receiver El missatge no pot ser processat perquè no s’ha pogut processar (no existeix la funció, per exemple.). En la versió 1.1 era Server.

Com que SOAP és XML, diem que hi ha un format de missatges que es pot expandir mitjançant espais de noms.

Protocol de transport

Els missatges poden viatjar en qualsevol protocol però el més usat és HTTP i per tant és el que explicarem aquí.

Per fer una petició cal enviar un missatge amb el mètode POST al servei web en què s’identifiqui on és el servei, i en el tipus hi ha d’haver application/soap+xml o bé text/xml.

POST http://ioc.xtec.cat:8080/Calculadora HTTP/1.1
Content-Type: application/soap+xml;charset=UTF-8;action="urn:sumar"

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 
...

La resposta també ens donarà informació de què ha passat. Si rebem un codi 200 és que tot ha anat bé.

HTTP/1.1 200 OK
Content-Type: application/soap+xml; action="urn:sumarResponse";charset=UTF-8

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
  ...
</soapenv:Envelope>

I si hi ha algun error hem de rebre un codi 500.

HTTP/1.1 
500 Internal Server Error
Content-Type: application/soap+xml; action="urn:sumarResponse";charset=UTF-8

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
  ...
</soapenv:Envelope>

Problemes

Una de les crítiques que es fa a SOAP és la mateixa que es fa a XML: malgrat tenir molts avantatges té la tendència a fer-se molt gran i això fa que SOAP acabi essent més lent que les altres tecnologies existents com CORBA o DCOM, que fan servir missatges binaris, de manera que són molt més curts i ràpids.

Tot i que aquests problemes són certs, per molta gent els avantatges que aporta -com la facilitat de lectura per als humans, la facilitat de detecció d’errors i el fet que solucioni els problemes de compatibilitat entre plataformes- el fan una opció que s’ha de tenir en compte.

WSDL

El WSDL (Web services definition language) és un llenguatge XML per descriure quins serveis ofereix un servei web i com s’ha de fer per accedir-hi (figura). Normalment l’ús d’un servei web requereix que el client obtingui abans el fitxer WSDL per saber quin servei s’ofereix i com s’ha de fer servir.

Figura WSDL serveix per obtenir les característiques tècniques d’un servei web

S’han desenvolupat diverses versions de WSDL: les originals, basades en el número 1 (1.0, 1.1); i la nova versió 2.0, que és incompatible amb les versions anteriors.

La versió 2.0 és més senzilla que les versions 1.X i ofereix compatibilitat amb un nombre més gran de característiques, però no està totalment implementada per als entorns de desenvolupament.

El format en que està definit el fitxer WSDL, a pesar de ser XML, està pensat per ser llegit i interpretat per una màquina i no pas per una persona. S’hi defineixen un ampli ventall d’aspectes: des de les adreces mitjançant les quals es pot comunicar amb les diferents funcions del servei web, fins al format en què ha d’estar cada tipus de dades.

El WSDL no és necessari per fer la comunicació, de manera que si ja es té informació sobre quins serveis ofereix un servei web i de quina manera s’hi pot accedir es pot desenvolupar un programa que faci servir el servei web sense problemes.

A pesar d’això obtenir el WSDL abans de comunicar amb un servei web pot servir per obtenir més informació sobre la manera com funciona el servei, i per detectar si s’hi han produït canvis.

El fitxer WSDL

El fitxer WSDL és un document XML que té per arrel <definitions> i que fa servir XSD per definir els tipus de dades implicades en el servei. Dins seu conté diferents etiquetes que s’encarreguen de definir quins serveis s’ofereixen i com es pot fer per accedir-hi.

Dins de l’element <definitions> hi podem tenir diferents elements segons si el document correspon a la versió 1 o a la 2. Vegem una comparació entre les versions en la figura.

Figura Comparació entre els WSDL 1.0 i 2.0

L’element <types> es fa servir per definir amb XSD els tipus de dades que s’empren en tots els serveis oferts. Es defineixen tots els tipus de dades, tant paràmetres d’entrada com de sortida, tipus complexos…

L’element <portType>, o <interface> en la versió 2, defineix les operacions que es poden fer en un servei web i els paràmetres que es fan servir per dur-les a terme. En aquesta part d’un document WSDL veiem que el servei web ofereix l’operació suma que rep com a paràmetres d’entrada un sumaRequest i que retorna un sumaResponse. Tots dos tipus han d’haver estat definits en la definició de tipus <types>, o <messages> en les versions 1.

  1. ...
  2. <wsdl:portType name="CalculadoraPortType">
  3. <wsdl:operation name="suma">
  4. <wsdl:input message="ns:sumaRequest" wsaw:Action="urn:suma"/>
  5. <wsdl:output message="ns:sumaResponse" wsaw:Action="urn:sumaResponse"/>
  6. </wsdl:operation>
  7. </wsdl:portType>
  8. ...

L’element <binding> defineix el protocol i el format en què es poden fer les operacions.

L’element <services>, per la seva part, defineix el lloc físic on hi ha el servei web (adreça URL) mitjançant una col·lecció de punts de connexió <binding>.

UDDI

El protocol UDDI (descripció, descoberta i integració universals o universal description, discovery and integration) serveix perquè els creadors de serveis web puguin registrar-los en una base de dades, i alhora permetre als clients localitzar serveis web que facin allò que volen i proporcionar-los el seu WSDL (figura).

Figura Funcionament dels serveis web amb UDDI

Des d’un punt de vista d’automatització això és l’ideal. Es pot fer que els programes automàticament localitzin el servei que busquen sense que ni tan sols en tinguin informació prèvia, simplement accedint al registre UDDI.

Per aquest motiu, UDDI va ser creat per donar servei a un registre anomenat UDDI Bussiness Registry o UBR, amb el propòsit de proporcionar una manera senzilla de localitzar serveis web basats en SOAP a Internet. La idea era crear una mena de “pàgines grogues” que continguessin tots els serveis web de manera que es poguessin localitzar a partir de les funcions que oferien.

Però UBR va fracassar i va tancar el 12 de gener del 2006. Era molt difícil crear categories de serveis que tinguessin prou significat per ser útils; i també s’ha de tenir en compte que UDDI no és necessari per poder fer servir serveis web.

A pesar d’això algunes organitzacions encara fan servir UDDI internament. Però també és cert que altres organitzacions fan servir sistemes diferents per localitzar serveis web: LDAP, bases de dades…

Provar serveis web

Per veure com funcionen els serveis web no hi ha res que vagi tan bé com provar-ne algun. Malauradament el fracàs de crear un sistema de registre ha fet que no sigui fàcil localitzar serveis per fer proves, i moltes de les funcions dels serveis web es fan servir en xarxes locals. Per exemple, molts dels programes de gestió d’empreses ERP permeten interacció mitjançant SOAP.

També hi ha algunes pàgines que contenen enllaços a serveis web públics accessibles per Internet. S’ha de tenir en compte que aquests enllaços no sempre estan totalment actualitzats i que per tant no sempre funcionen.

En aquestes pàgines web s’hi poden trobar serveis web molt diversos, com obtenir la temperatura de diferents ciutats del món, sistemes de conversió de monedes, informació sobre països, valors de la borsa, traduccions de textos o comprovacions de correu electrònic.

Com que per poder fer servir un servei web el primordial és obtenir el seu WSDL per saber com interactuar-hi, les pàgines solen mostrar un enllaç al WSDL de cadascun dels serveis que tenen registrat (figura).

Figura Seekda fa un resum de cada servei

Eines de prova

Per provar els big Web services sense haver de programar ni una línia tenim diverses alternatives, atès que SOAP i WSDL no deixen de ser llenguatges XML, i molts dels editors XML ofereixen alguna manera de depurar el funcionament dels serveis web (figura).

Figura Provar un servei web des d’oXygen XML Editor

Els editors XML normalment es limiten a permetre enviar peticions editables i recuperar les respostes que arriben des del servei web en SOAP. A part dels editors XML també hi ha una sèrie de programes que permeten fer tasques molt més elaborades, com ara fer proves de rendiment o de seguretat, comprovar si el servei compleix les regles d’interoperativitat de WS-I, o fer proves automàtiques de rendiment. Alguns d’aquests programes són:

Els avantatges que aporten aquests programes són prou importants per tenir-los en compte a l’hora de dissenyar serveis web SOAP professionals.

Exemple d'ús

Normalment els serveis web es fan servir des de programes desenvolupats expressament per fer una determinada tasca. Però també es poden fer servir des de programes dissenyats específicament per provar serveis web.

Programes

El funcionament de la majoria dels programes de prova és molt similar, i tots permeten fer més o menys les mateixes coses. En aquest exemple farem servir el SoapUI, una aplicació desenvolupada en Java que permet provar, analitzar, simular i generar codi de serveis web de manera senzilla i àgil a partir del fitxer WSDL, i que conté la possibilitat d’automatitzar les proves funcionals.

El SoapUI es distribueix en dues versions: SoapUI Freeware (GNU LGPL) i SoapUI Pro (comercial), que es poden executar en versió d’escriptori, en línia i mitjançant connectors que permeten treballar-hi des de diferents entorns de desenvolupament com Eclipse, IntelliJ IDEA i NetBeans (figura).

Figura Entorn del SoapUI
Objectiu

Volem fer un programa que pugui mostrar als usuaris quina és la temperatura de Barcelona.

Per fer-ho ens valem d’un servei públic i gratuït que proporciona aquesta informació. Anem a Seekda (http://webservices.seekda.com/browse) i busquem algun dels serveis de temperatura; ens quedem amb GlobalWeather (figura).

Figura GlobalWeather permet mostrar dades meteorològiques de ciutats amb aeroports
Aconseguir el WSDL

Per poder fer servir el servei web ens cal aconseguir quins són els serveis que ofereix. Per fer-ho hi ha dues maneres:

  • Que el creador del servei web proporcioni la informació.
  • Aconseguir el seu fitxer WSDL.

En aquest cas, en el quadre de resum del servei ja tenim el WSDL i per tant podem fer servir aquest sistema (figura).

Figura El quadre de resum del cercador Seekda ens ofereix un enllaç al WSDL
Provar el servei

Inspeccionant el WSDL es veuen els serveis que s’ofereixen, però el SoapUI ho fa automàticament i a més permet provar el servei.

El primer que cal fer és crear un projecte nou, en el qual s’han d’especificar diferents opcions, entre les quals destaca el WSDL (figura).

Figura Crear un projecte amb el SoapUI

Com que volem descobrir els serveis que ofereix GlobalWeather només cal que marquem la primera de les opcions.

Quan el projecte s’hagi creat, en el costat dret hi apareixeran tots els serveis que ofereix el servidor web i les maneres amb què s’hi pot connectar.

Com en aquest cas, és bastant habitual que els serveis web permetin que s’hi treballi fent servir diferents versions de SOAP. En aquest servei es pot fer servir SOAP 1.1 (GlobalWeatherSoap) i SOAP 1.2 (GlobalWeatherSoap12) (figura).

Figura Les marques verdes indiquen diferents maneres de connectar amb el servei

El servei GlobalWeather només ofereix dues funcions:

  • GetCitiesByCountry: com indica el nom, retorna una llista de les ciutats d’un país determinat que funcioni amb el servei.
  • GetWeather: proporciona la informació meteorològica d’una ciutat concreta.

El primer que cal fer és descobrir si Barcelona és entre les ciutats disponibles. Desplegueu la funció GetCitiesByCountry i, si feu doble clic a “Request1”, es crearà la plantilla d’una petició SOAP. Els valors dels paràmetres que s’han d’emplenar estan marcats amb un interrogant (figura).

Figura Els interrogants mostren on s’han de posar els paràmetres

En executar la comanda apareixerà una llista amb el resultat de l’execució del servei en la part dreta de la finestra. Entre els resultats es veu que Barcelona és una de les ciutats amb què funciona el servei, i per tant aquest servei web és útil per als nostres propòsits (figura).

Figura Barcelona és entre els resultats

Un cop descobert que es pot fer servir el servei per consultar les dades meteorològiques de Barcelona, podem provar d’obtenir la temperatura fent servir el procediment anterior però clicant a la funció GetWeather. Aquesta funció necessita dos paràmetres: la ciutat i el país (figura).

Figura GetWeather pot tenir dos paràmetres per treballar

Si empleneu la funció amb Barcelona i Spain obtindreu els valors de temperatura, vent, estat del cel, etc., en un format XML senzill que no costaria gaire que un programa pogués interpretar (figura).

Figura Temperatura a Barcelona

Arquitectures basades en REST

Una de les crítiques que es fan als serveis web basats en SOAP és que s’ha de tractar amb massa protocols per aconseguir qualsevol cosa i això fa que siguin massa complicats.

Els serveis basats en REST (representational state transfer) intenten capturar les característiques que han fet que la web tingués èxit, i en especial la seva senzillesa: resulta fàcil d’entendre i de fer servir. Es parteix de la idea que la web ha revolucionat la manera d’accedir a les dades perquè és simple i fa servir un conjunt petit de tecnologies. Però a més ha passat a ser un sistema distribuït, obert i multiplataforma, i en moltes pàgines web es fan coses tan complexes com en els serveis web sense fer-ho tan complicat com en els sistemes SOAP.

Mentre els big Web services exposen funcions semblants a les dels llenguatges de programació mitjançant interfícies més o menys complexes que són diferents per a cada servei, els serveis web basats en REST exposen les dades mitjançant una interfície que sempre és la mateixa. Aquests serveis intenten aconseguir el mateix èxit que ha tingut la web fent servir les mateixes armes: no es defineixen nous protocols sinó que s’aprofiten els que ja existeixen i tenen èxit. Per què ens hem de complicar la vida? Per què hem de crear nous protocols complexos?

REST no és un protocol sinó un conjunt de regles i principis que permeten desenvolupar serveis web fent servir HTTP, i basant-se en el fet que la web és plena de recursos que es poden manipular mitjançant les seves representacions.

REST obliga a fer que els missatges continguin tot el necessari per poder funcionar, ja que es parteix del fet que no tenen estat, de manera que no poden recordar les peticions anteriors. Això implica que el sistema ha de tractar cadascuna de les peticions com si fos l’única, i per tant ha de tenir tot el necessari perquè el servidor pugui fer la tasca. El servidor mai no tindrà en compte les peticions anteriors per tractar l’actual.

Segurament el fet que REST faci servir tecnologies que ja existien -la qual cosa permet accedir als recursos d’una manera homogènia i simplifica l’ús, ja que no cal interpretar què fan determinades funcions ni què s’ha de posar en els paràmetres-, ha estat clau en el fet que els serveis basats en REST s’hagin convertit en els preferits per desenvolupar serveis web. Molts dels antics serveis basats en SOAP, com per exemple les recerques de Google, s’han abandonat en favor d’altres sistemes que sovint estan basats en REST.

Els recursos

L’accés als recursos és el component bàsic en la web, i per tant també ho és de REST.

Actualment les idees d’URI (identificador uniforme de recursos o uniform resource identifier) i URL (localitzador uniforme de recursos o uniform resource locator) són pràcticament idèntiques i per tant es poden usar indistintament.

Per a REST, qualsevol cosa que es pugui identificar amb un URI o un URL dins d’Internet es considera un recurs, i com que pràcticament tot el que hi ha dins d’Internet es pot identificar mitjançant un URL tenim molts recursos disponibles.

Per a REST tot és un recurs que es pot identificar i que es pot manipular. Per exemple es pot definir un servei web que identifiqués els alumnes d’una classe a partir d’adreces URI formades d’una manera especial.

http://ioc.xtec.cat/classe/programacio/alumne/*

Fent servir aquesta nomenclatura podem accedir al primer alumne de la classe de programació de l’IOC amb http://ioc.xtec.cat/classe/programacio/alumne/1, al segon amb http://ioc.xtec.cat/classe/programacio/alumne/2 i així successivament. Alhora podem definir la classe de programació d’una manera similar: http://ioc.xtec.cat/classe/programacio.

Un recurs és un concepte o una idea que es pot associar a un URL o un URI, però a més per a REST els recursos poden tenir diferents representacions segons l’estat en què es trobin.

Vegem els conceptes gràficament en la figura.

Figura Conceptes de REST

A pesar del que pot semblar, en molts dels exemples de serveis web en REST les jerarquies d’adreces per a REST d’entrada no impliquen cap tipus de relació entre els recursos. Això vol dir que les adreces següents no tenen per què tenir cap tipus de relació:

http://ioc.xtec.cat/classe/programacio/
http://ioc.xtec.cat/classe

La primera podria mostrar la llista d’alumnes i la segona, informació sobre on es fan classes en el centre i quan.

En sistemes REST les relacions reals s’estableixen mitjançant els enllaços que tinguin les pàgines.

Representacions

XML no és l’únic llenguatge de marques que es fa servir en serveis web. Un llenguatge que està tenint molt d’èxit és JSON (JavaScript object notation).

Per a REST no hi ha cap problema a fer servir la web per comunicar programes, ja que en realitat la comunicació d’una pàgina web ja és una comunicació entre programes (el servidor i el navegador). L’única cosa que no està pensada per ser usada per programes és el contingut.

El més habitual és que els recursos de la web estiguin pensats per ser consumits per humans mitjançant navegadors, i per aquest motiu la informació s’hi sol representar en HTML. Si l’objectiu és permetre a les màquines fer servir la web només cal que el contingut de les pàgines estigui en un format més amigable per als programes, com per exemple XML.

Malgrat fer servir la web, REST no està limitat a fer servir missatges en HTML o XML sinó que pot emprar recursos en qualsevol format. Per tant, en un servei web basat en REST es poden generar des de documents en HTML o PDF fins a imatges en JPG o GIF.

La idea és que no es visualitza el recurs en si sinó només una representació d’aquest recurs. Quan algú accedeix a l’adreça http://ioc.xtec.cat/classe/programació/alumne/23 el que està definint és que vol obtenir l’alumne número 23 de la classe de programació, però el que obtindrà no serà l’alumne sinó una representació d’aquest alumne que, segons el context, pot ser una imatge, una pàgina web amb les notes de l’alumne o un fitxer XML amb les seves dades personals.

Hi ha recursos que només tindran una sola representació i d’altres que en tindran diverses i per aquest motiu en REST els programes poden demanar quina és la representació que volen obtenir o els servidors poden enviar la que considerin més adient segons un determinat criteri (per exemple, segons el programa que ha demanat el recurs).

Gràcies a les representacions es pot aconseguir que s’uneixi de manera transparent la web dels humans amb la dels programes.

Per exemple, és habitual que si el servidor detecta que s’hi està accedint amb un navegador retorni una representació en HTML, mentre que si és mitjançant un altre programa retorni la representació en XML.

HTTP

REST fa servir HTTP com a sistema de transport (tot i que també podria funcionar amb altres protocols), però també el fa servir com a sistema de missatges. Per aquest motiu s’ha de definir quin és el paper que han de tenir els diferents mètodes HTTP a l’hora de gestionar un recurs.

S’han definit una sèrie d’equivalències entre els mètodes HTTP i la manera de tractar el recurs especificat, que es veuen en la taula.

Taula: Equivalències dels mètodes HTTP en REST
Mètode Significat
POST Crear un recurs.
GET Obtenir el recurs.
PUT Actualitzar el recurs.
DELETE Eliminar el recurs.

D’aquesta manera es poden fer les operacions bàsiques simplement enviant una petició HTTP a un URI, triant el mètode HTTP adequat. Enviant una petició HTTP GET obtindrem la representació de l’alumne 1:

GET classe/programació/alumne/1

En canvi, enviant un DELETE definim que s’ha d’eliminar de la llista l’alumne 1:

DELETE classe/programació/alumne/1

En HTTP els mètodes POST i PUT s’han definit per poder enviar informació al servidor i per tant, a més de l’ordre, normalment s’hi envia quina informació conté. Això els fa candidats ideals per inserir o modificar recursos.

Desenvolupament de serveis web

Els avantatges que poden aportar els serveis web (web services) no han passat desapercebuts i ràpidament els llenguatges de programació han anat incorporant components per desenvolupar-ne. Per exemple, el JDK (Java development kit) de Java incorpora una API per crear serveis web que s’anomena Java Api for XML Web Services (JAX-WS), però ja anteriorment se’n podien crear fent servir Java API for XML-based RPC(JAX-RPC).

La majoria de les biblioteques o entorns de desenvolupament s’especialitzen en un dels dos grans grups de serveis web, però l’increment de la popularitat dels serveis REST ha fet que molts dels entorns basats en el protocol SOAP també incorporin la possibilitat de funcionar de forma compatible amb REST.

Desenvolupament de serveis basats en SOAP

Les biblioteques SOAP estan pensades per ser transparents amb vista als programadors, i per tant aquests programadors no solen tenir gaires problemes per fer-les servir. És així perquè les llibreries SOAP s’encarreguen de crear i eliminar els missatges SOAP, i al programa només hi arriben les dades que s’han enviat.

Un client demana un servei i internament la biblioteca crea el paquet SOAP per a les dades que ha d’enviar i l’hi envia. Quan la biblioteca rep les dades elimina el paquet SOAP i envia les dades netes al programa (figura).

Figura Les biblioteques SOAP amaguen la implementació als programadors

Per tant, excepte en petits detalls, els programadors es poden despreocupar de l’existència de SOAP i només s’han de preocupar de quins serveis volen oferir.

Tot i que no és absolutament necessari crear un client SOAP, és molt més senzill si es té el WSDL del servei ja que es disposa d’auxiliars que s’encarreguen de preparar els esquelets del programa.

Gairebé sempre es pot obtenir el fitxer WSDL d’un servei web afegint al darrere de l’adreça del servei les lletres ?wsdl. En alguns entorns aquest fitxer es genera automàticament en el moment en què és demanat i en d’altres és simplement un arxiu.

Un exemple d’això el tenim en la figura.

Figura Obtenir el WSDL d’un servei

Els entorns de programació solen oferir auxiliars i eines que simplifiquen al màxim la creació de serveis basats en SOAP, generant automàticament el codi necessari per implementar o fer servir el web i fent que el programador només s’hagi de preocupar de definir què ha de fer el servei web.

Malgrat que els llenguatges més usats per desenvolupar serveis web són sobretot Java i els basats en la plataforma de Microsoft .NET, gairebé tots els llenguatges de programació tenen alguna biblioteca que els permet desenvolupar servidors i clients basats en SOAP. I a més s’ha de tenir en compte que el llenguatge usat és bastant irrellevant, ja que una de les característiques dels serveis web és que no importa en quin llenguatge o en quin sistema s’executin els servidors i els clients que podran operar entre si.

Un dels ajuts més habituals consisteix a fer servir el WSDL del servei per crear automàticament tot el codi que cal per comunicar o generar el servei web. Per exemple, mitjançant el mòdul ZSI de Python es pot fer servir l’eina wsdl2py per crear les plantilles que continguin tot el necessari per implementar un client i un servidor que puguin treballar amb les funcions del servei que defineix el WSDL.

  1. $ wsdl2py http://localhost:8080/axis2/services/Bencalculat?wsdl
  2. import multifile, mimetools, urllib
  3. $ ls
  4. Bencalculat_client.py Bencalculat_server.py Bencalculat_types.py

Moltes biblioteques en diferents llenguatges de programació ofereixen eines similars, que podeu veure en la taula.

Taula: Crear codi a partir del WSDL
Llenguatge Biblioteca/entorn Eina
Java Apache Axis2 java2wsdl wsdl2java
Java Apache CXF java2wsdl wsdl2java
C# .NET wsdl
C gSoap wsdl2h
Perl SOAP::WSDL wsdl2perl
Python ZSI wsdl2py

Desenvolupament de serveis basats en REST

REST està tan integrat en la web que no hi ha gaire diferència entre desenvolupar programes client que funcionin amb REST i desenvolupar programes per connectar i treballar amb servidors web.

Els resultats de fer consultes a serveis REST no es diferencien gens ni mica de les pàgines web excepte en el fet que el resultat obtingut normalment, en comptes de rebre només resultats HTML, està en un llenguatge de marques diferent com XML o JSON (figura).

Per tant, qualsevol biblioteca que permeti crear clients HTTP serveix per desenvolupar un client de serveis web basats en REST. Es pot fer servir qualsevol de les biblioteques estàndard per desenvolupar clients HTTP, com per exemple HTTPClient de Java, la classe WebClient de .NET o httplib de Python.

Els servidors són una mica més complexos però no gaire més, ja que només cal veure quina adreça es vol visitar per localitzar el recurs i quina instrucció ha fet servir el client per saber què hi vol fer. Aquesta tasca és molt més simple que el treball amb SOAP/WSDL i la majoria dels llenguatges de programació ja disposen d’alguna biblioteca per facilitar el desenvolupament d’aplicacions REST: JAX-RS, Restlet, Apache CXF, RESTeasy, RESTSharp, openRASTA…

Figura Desenvolupament REST

Entorns de desenvolupament

Han aparegut tota una sèrie d’entorns de treball que faciliten encara més la creació i desplegament dels serveis web. Amb uns quants clics es pot crear i desplegar un servei web senzill en pocs segons.

Com passa amb moltes de les tecnologies XML, la majoria d’aquests entorns estan basats sobretot en dues tecnologies de programació: Java i .NET. Vegem una llista d’aquests entorns en la taula.

Taula: Entorns de desenvolupament per crear serveis web
Nom Llenguatge Serveis
Apache Axis2 Java / C SOAP, REST
Apache CXF Java SOAP, REST
Spring Web Services Java SOAP
Metro Java SOAP
JAX-WS Java SOAP
JAX-RS Java REST
.NET Framework .NET SOAP, REST
Windows Communication Foundation (WCF) .NET SOAP, REST

Apache Axis2

L’Apache Axis és una implementació de codi obert de serveis web que proporciona un entorn d’execució en Java i C. La implementació Axis2 funciona amb SOAP 1.1 i SOAP 1.2, però també ofereix compatibilitat integrada per a REST.

L’Axis2 ha estat durant molt de temps un dels entorns més usats a l’hora de crear serveis web SOAP.

L’Axis2 proporciona:

  • Un entorn d’execució per a serveis web Java.
  • Eines per crear WSDL a partir de codi Java.
  • Eines per crear clients Java a partir del WSDL.
  • Eines per desplegar, provar i monitorar serveis web.
  • Integració amb servidors d’aplicacions i contenidors de miniaplicacions de servidor (servlets).

L’Axis2 inclou un servidor d’aplicacions que es pot usar directament o bé es pot fer servir com un component integrable en diferents servidors o contenidors d’aplicacions com el Tomcat o el Glassfish.

Proporciona un entorn web des del qual es poden gestionar, consultar i comprovar els serveis web que s’ofereixen (figura).

Figura Web principal de l’Axis2

L’entorn d’administració permet gestionar els serveis web de manera que se’n poden afegir de nous, desactivar-los parcialment o totalment, afegir mòduls de funcionament, etc. (figura).

Figura L’eina d’administració de l’Axis2 permet fer qualsevol cosa amb els serveis web que s’hi instal·lin

De cadascun dels serveis oferts es mostra quines són les funcions que exporta el servei i el seu fitxer WSDL (figura).

Figura Informació dels serveis de l’Axis2

L’Axis2 permet que els mateixos serveis siguin consultats tant des de SOAP com des de REST (figura).

Figura Consulta d’un servei SOAP de l’Axis2 des del SoapUI

Per fer servir una funció en REST es defineix la funció en l’adreça com si fos un recurs (figura).

Figura Consulta d’un servei REST de l’Axis2 amb Firefox

Per exemple, si en el servidor http://www.prova.cat:8080/ on hi ha instal·lat l’Axis2 hi tenim el servei Calculadora que exposa una funció anomenada Suma(), que rep els paràmetres in1 i in2 -els valors que s’han de sumar-, hem de fer una petició com la següent per sumar els nombres 1 i 2:

http://www.prova.cat:8080/axis2/services/Calculadora/Sumar?in1=1&in2=2
Anar a la pàgina anterior:
Exercicis d'autoavaluació
Anar a la pàgina següent:
Activitats