oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: soap

gSOAP toolkit SOAP per C/C++

Reading time: 4 – 6 minutes

gSOAP, després de perdre-li la pista durant molt de temps aquesta llibreria de C i C++ crec que és la millor de codi obert i GPL que he trobat. Així doncs, ús la vull recomenar. El nom ve de “SOAP generator” i el va fer un professor, la versió 1.0 va sortir l’any 1999, per tant, podriem dir que l’eina esta més que provada si tenim en compte que va per la versió 2.7.1 que va sortir al gener del 2008.

Per entendre una mica que ofereix aquest toolkit esta molt bé fixar-se en aquest parell de gràfics que donen una visió de l’eina quan l’usem com a servidor SOAP:

gSOAP schema for server mode

i com a client SOAP:

gSOAP schema for client mode

Si haguessim de fer una llista de funcionalitats més detallada i tècnica em quedaria amb la que ofereix la pàgina de l’aplicació:

  • All-in-one package. Independence from third-party tools and libraries ensures successful builds and reliable runtime execution.
  • Open source with several license options.
  • gSOAP supports both pure ANSI C application development and mixed C/C++ application development.
  • gSOAP is the only toolkit that supports XML-to-C/C++ mapping for native C and C++ data types, which means that you can serialize your application data directly instead of having to use wrappers or SOAP/XML-specific data types. Any C or C++ data type can be serialized when it can be specified in a C/C++ header file (except unions). The toolkit automatically serializes pointer-based data structure graphs, including cyclic graphs and pointers to derived class instances to support polymorphism.
  • The toolkit follows the WS-I Basic Profile 1.0a compliance recommendations. It warns about potential interoperability issues before building a new Web service application, so you don’t have to go through another development cycle to make your services compliant. In addition, a report is available to check compliance.
  • Complete support for industry-standard Web services protocols SOAP 1.1/1.2 (RPC and doc/lit), WSDL 1.1, and UDDI v2. Supports XML schema with primitive XSD types, simpleTypes, complexTypes, extension, restriction, elements, attributes, groups, attributeGroups, and arrays (including polymorphic data types and SOAP 1.1 encoding of multi-dimensional sparse arrays). Extensive interoperability testing with other SOAP toolkits resulted in a toolkit release that has proven to be stable, robust, and reliable.
  • Supports SOAP-over-UDP, MIME (SwA), DIME (streaming), MTOM (streaming), HTTP1.0/1.1, IPv4, IPv6, RSS, XML-RPC, WS-Addressing, WS-Enumeration, and many other WS-* protocols.
  • Supports WS-Security: authentication, tokens, digital signatures (XML encryption will be added in the near future).
  • gSOAP is the only toolkit that implements streaming techniques for DIME and MTOM binary attachment transfers. It also supports SOAP with Attachements (SwA) Multipart/related MIME attachments.
  • Fast and efficient because gSOAP uses streaming XML parsing techniques. Typical round-trip SOAP service invocation latencies are below 1ms. Shown to be the fastest SOAP1.1/1.2 compliant C/C++ implementation available (wrt. most common uses we tested).
  • Very portable: Windows, Linux, Unix, Mac OS X, Solaris, HP-UX, AIX, FreeBSD, TRU64, Irix, QNX, VxWorks, MS-DOS. Also portable to handheld devices such as WinCE (Pocket PC), Palm OS, Symbian, and embedded Linux. Clients and server applications can be created that are under 100K with a total memory footprint under 150K.
  • The gSOAP WSDL parser automates server and client application development. gSOAP also generates WSDL documens to publish your services.
  • gSOAP Web Services and clients are just as easy to program as C# and JavaRMI, see How To section below.
  • Serialization of native C and C++ data types allows you also to store and retrieve application data from XML repositories.
  • Includes stand-alone HTTP/1.1 and HTTPS secure Web Server.
  • Offers Apache_mod, IIS, WinInet, CGI, and FastCGI interfaces.
  • Supports HTTP/1.1 POST/GET SOAP/XML messaging with compression, chunking, keep-alive, logging, and SSL encryption.
  • The gSOAP compiler can be conveniently integrated in an IDE. For example, MSVC++ 6.0 project examples with gSOAP integrated in MSVC++ are included in the gSOAP distribution for Windows.
  • Security: supports HTTPS and WS-Security. In addition, the source codes have been carefully written to avoid security holes such as buffer overruns. Also, gSOAP is open source which means that the gSOAP implementation can be verified.
  • gSOAP’s memory management uses garbage collection so (deserialized) data can be cleaned up without a hassle.
  • Company backup for support, licensing, and consulting.
  • Extensive documentation.

PHP: notes sobre arrays i tres classes (myCurl, barcodes, WSSoapClient)

Reading time: 2 – 3 minutes

A HowtoForge han publicat un howto (local) sobre com funcionen els arrays en PHP que esta molt bé. Realment el que més valoro són les notes sobre les funcions que menys s’acostumen a usar i per tant, les menys documentades o més mal documentades. Tot i que sovint quan les descobreixes ja no pots viure sense elles, funcions de búsqueda, de push, pop, var_dump per depurar, etc.

A més a través de phpClasses he trobat tres classes que els hi he de donar un bon cop d’ull ja que tenen molt bona pinta:

  • MyCurl This class provides an alternative implementation of the cURL extension functions in pure PHP. It automatically detects whether the cURL library is available. If it is not available, it defines several functions with the same names of the cURL extension that use the class to emulate part the original functionality. Currently it implements the functions: curl_init, curl_exec, curl_setopt and curl_close. Several of the most important options can be set with the curl_setopt function.
  • HTML Bar Codes This package can be used to display bar codes using only HTML with CSS styles. It takes a code to represent and generates CSS style definitions and HTML tags to render that code in an HTML page. There are two classes that can render bar codes using the Code39 and Interleave 2 of 5 standards respectively.
  • WSSoapClient This class can add WSSecurity authentication support to SOAP clients implemented with the PHP 5 SOAP extension. It extends the PHP 5 SOAP client support to add the necessary XML tags to the SOAP client requests in order to authenticate on behalf of a given user with a given password. This class was tested with Axis and WSS4J servers.

SOAP amb Symfony

Reading time: 2 – 3 minutes

symfony.gif

Fa uns mesos vaig implementar una aplicació amb força connexions SOAP tan a nivell de client, com de servidor contra aplicacions .NET i aplicacions SOAP fetes en Symfony mateix. Malgrat funcionen prou bé, he de reconeixer que la implementació SOAP de PHP fins a la versió 5.2.0 que és la última que he provat dona alguns problemes. Ja no quan es comunica amb .NET sinó quan parlo amb ella mateixa. Puc assegurar que no és culpa del codi, perquè l’estructura client servidor de la que parlo feia més de 200 transaccions diaries de les quals unes 10 o 20 fallaben, per errors de l’estil Error Fetching http headers. De fet, investigant vaig trobar algún que altre BUG intern de PHP que comentava el problema, però segons deien a PHP ja estava solucionat. Doncs a mi em continuaven donant. Finalment el que vaig fer per solucionar-ho va ser eliminar SOAP a tot arreu d’on vaig poder, ara mateix no tinc ni un error d’aquest estil i es continuen fent unes 200 transacions diaries o més.

Malgrat aquesta no massa bona experiència, continuo pensant que la idea és boníssima i que cal seguir treballant amb ella. Doncs bé, quan vaig implementar el servidor SOAP via Symfony no vaig trobar cap tipus de documentació que parles de com fer-ho bé. Així doncs vaig improvisar i vaig repartir el codi entre les actions i els templates amb tan bon criteri com vaig saber, tan per publicar el fitxer WSDL com per publicar el servei SOAP. Ara esta apunt de sortir la versió 1.0 de Symfony i curiosament també s’ha publicat un snippet on es parla de com publicar un servei SOAP desde Symfony. Així doncs, he de reconeixer que la implementació que es fa de la idea en aquest snippet és molt millor que la meva. Per tant, el recomano: Code Snippets: Soap server (local).

Qt SOAP – provant els webservices

Reading time: 1 – 2 minutes

A l’article Client SOAP genèric ja vaig parlar d’una pàgina web que a partir de la URL del WSDL ja podiem atacar el webservice d’una forma molt senzilla. El problema que té això és que quan estem dintre de la xarxa de l’empresa potser no tenim el webservice publicat a l’exterior d’internet. Doncs amb aquesta simple eina programada en Qt podem tenir una eina similar a la oferida per la pàgina web.

qtsoap.png

De moment encara no l’he provada però de ben segur ho hauré de fer aviat, així doncs si hi trobo algún inconvenient o avantatge descatbles, amplicaré aquest article sobre el Qt SOAP. Una cosa que ja he vist i que té molt bona pinta és que ens permet veure les HTTP headers de la petició i la respostes SOAP. A més podem definir el content-type de la petició cosa realment útil.

Client SOAP genèric

Reading time: < 1 minute

A SOAPClient.com tenen un munt d’aplicacions i eines via web per provar els serveis SOAP que programem o que hem d’usar. Concretament volia descatar el client genèric SOAP, al qual només cal passar-li la direcció URL del WSDL i ell ens mostra un formulari per llençar una petició SOAP contra el servidor i després podem veure la sortida en format XML o HTML. Realment útil per saber si el nostre SOAPService funciona correctament.

PHP5: passant i tornant objectes com a paràmetre en una crida SOAP (Part II)

Reading time: 5 – 8 minutes

El mes de març vaig escriure un article titulat gairebé igual que aquest, en aquell article explicava com s’ho feia el PHP5 per rebre i retornar tipus complexes (p.e. objectes) com a paràmetres de crides SOAP. Doncs bé havia trobat una cosa que em tenia una mica mosca i és que quan enviava una objecte del client cap al servidor o alrevés en perdia el tipus. Doncs bé aquesta tarda he descobert com aconseguir fer això sense perdren el tipus. Ja sabeu que quan se’m posa una cosa al cap…

El tema no és senzill i el generador de WSDL del ZendStudio és una mica tiquis-miquis fent aquestes coses així doncs s’ha de fer tot molt maco perquè ho entengui el generador WSDL. De fet, la gràcia esta en definir el tipus complexe dins del fitxer WSDL, per això el generador necessita que li donem tota la informació com ell vol sinó no és capaç de generar bé el fitxer.

En l’exemple que us poso a continuació he creat la classe persona amb tres atributs dos de públics i un de privat. El privat al contrari del que comentava en l’article anterior no perd el seu valor. Així doncs, en principi tenim l’objecte 100% replicat amb el mètode que ara us explicaré.

La classe persona:

<?php
/**
 * classe persona
 *
 */
class persona {
	/**
	 * propietat nom
	 *
	 * @var string $nom
	 * @var string $cognom
	 * @var string $dni
	 */
	public $nom;
	private $cognom;
	public $dni;
	/**
	 * setter function
	 *
	 * @param string $nom
	 */
	function set($nom) {
		$this-?>nom=$nom;
	}
	/**
	 * setter cognom
	 *
	 *  @param string $cognom
	 */
	function setCognom($cognom)
	{
		$this-?>cognom=$cognom;
	}
	/**
	 * getter function
	 *
	 * @return string valor a tornar
	 */
	function get()
	{
		return $this-?>nom;
	}
	/**
	 * getter cognom
	 *
	 * @return string valor a tornar
	 */
	function getCognom()
	{
		return $this-?>cognom;
	}
}
?>

Fixeu-vos que comentem el codi segons la sintaxis del phpDoc això es fa perquè és d’aquests comentaris d’on el generador WSDL extreurà els tipus de les variables per poder-les exportar sense perdre informació. La propietat dni no té ni getter ni setter perquè hi accedirem directament. Per la resta de coses és una classe completament normal i senzilla.

El servidor és força simple:

<?php
require_once("persona.class.php");
/**
 * servidor soap
 *
 */
class soapservice {
	/**
	 * funcio soap publicada
	 *
	 * @param persona $per
	 * @return persona
	 */
	function peticion($per) {
		$per->dni="38147000x";
		return $per;
  }
}
	$server = new SoapServer("server.wsdl",array("classmap"=>array("persona"=>"persona")));
$server->setClass("soapservice");
$server->handle();
?>

Comentar que la classe soapservice rep un objecte de tipus persona afegeix un valor a la propietat dni i retorna el mateix objecte. Aquí també hem de documentar el codi segons la sintaxis del phpDoc així el model WSDL ens dirà explicitament el tipus dels objectes que rep i torna el mètode peticion.

Pel que fa a la creació de l’objecte server del tipus SoapServer fixeu-vos que mapegem amb l’opció classmap l’objecte de tipus persona que es passa com a paràmetre amb la classe local també anomenada persona. Gràcies a aquest mapeig quan rebem l’objecte per al soapservice aquest ja és del tipus persona.

Ara toca veure el codi del client, aquest codi també té un mapeig igual que el servidor de SOAP, però en aquest cas serveix per capturar la sortida del servidor i com que l’objecte que es torna a la sortida també és del tipus persona el classmap és igual que el del servidor.

<?php
require_once("persona.class.php");
// creem objecte tipus persona
$myPersona=new persona;
$myPersona->set("el_nom");
$myPersona->setCognom("el_cognom");
	$client = new SoapClient("server.wsdl",array("classmap"=>array("persona"=>"persona")));
	$localPersona=$client->peticion($myPersona);
	var_dump($client->__getFunctions());
print_r($localPersona);
echo $localPersona->getCognom();
?>

Una de les coses interssants que fem és preguntar quines funcions s’estan publicant al servidor SOAP. Aquesta informació esta descrita al WSDL i la funció __getFunctions() ens la formateja per humans. Així doncs podem veure que hi ha disponible la funció peticion que té com a paràmetre un objecte del tipus persona i que retorna un altre objecte de tipus.

array(1) {
  [0]=>
  string(30) "persona peticion(persona $per)"
}

Després mostrem (print_r) l’objecte localPersona que ens ha tornat la crida al mètode peticion ($localPersona=$client->peticion($myPersona);):

persona Object
(
    [nom] => el_nom
)

Finalment fem una prova de concepte i obtenim el valor de la propietat nom a través del getter, o sigui, echo $localPersona->getCognom();:

el_nom 

Com podeu veure ha quedat ben demostrat que és relativament senzill enviar i rebre tipus complexes a través dels serveis SOAP. Tota la gràcia esta en el fitxer WSDL, a continuació us enganxo el que m’ha generat el Zend Studio per fer aquestes proves fixeu-vos com al prinicipi de tot el primer que fa és declarar el tipus complexe de dades que ha de traspassar, en el nostre cas la classe persona.

<?xml version='1.0' encoding='UTF-8'?>
	<!-- WSDL file generated by Zend Studio. -->
	<definitions name="server" targetNamespace="urn:server" xmlns:typens="urn:server" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:typens0="http://oriol.joor.net/fotoprix/web/cu.php/soap/server">
	<types>
		<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:server">
			<xsd:complexType name="persona">
				<xsd:all>
					<xsd:element name="nom" type="xsd:string"/>
					<xsd:element name="cognom" type="xsd:string"/>
					<xsd:element name="dni" type="xsd:string"/>
				</xsd:all>
			</xsd:complexType>
		</xsd:schema>
	</types>
	<message name="peticion">
		<part name="per" type="typens:persona"/>
	</message>
	<message name="peticionResponse">
		<part name="peticionReturn" type="typens:persona"/>
	</message>
	<portType name="soapservicePortType">
		<documentation>
			servidor soap
		</documentation>
		<operation name="peticion">
			<documentation>
				provem de descriure
			</documentation>
			<input message="typens:peticion"/>
			<output message="typens:peticionResponse"/>
		</operation>
	</portType>
	<binding name="soapserviceBinding" type="typens:soapservicePortType">
		<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
		<operation name="peticion">
			<soap:operation soapAction="urn:soapserviceAction"/>
			<input>
				<soap:body namespace="urn:server" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
			</input>
			<output>
				<soap:body namespace="urn:server" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
			</output>
		</operation>
	</binding>
	<service name="serverService">
		<port name="soapservicePort" binding="typens:soapserviceBinding">
			<soap:address location="http://oriol.joor.net/soap/server.php"/>
		</port>
	</service>
</definitions>

PHP5: passant objectes com a paràmetre en una crida SOAP

Reading time: 2 – 3 minutes

Update: LES CONCLUSIONS D’AQUEST ARTICLE SÓN ERRONEES MIREU: PHP5: passant i tornant objectes com a paràmetre en una crida SOAP (Part II)

Treballant en un projecte que estem programant en PHP5 em va sortir aquest dubte, sobretot després de llegir les limitacions dels servidors SOAP que implementa PHP5. El tema finalment té una resposta positiva: SI, PERO…. A continuació us poso un exemple de com funciona aquest tema amb el PHP5 i quines limitacions té.

Definim el servidor SOAP que com podeu veure és senzillissim, l’únic que fa el servidor és re-enviar el mateix objecte que ha rebut.

<php
class SOAPservice {
        function peticion($per) {
                return $per;
  }
}
$server = new SoapServer("server.wsdl");
$server->setClass("SOAPservice");
$server->handle();
?>

A continuació podeu veure el codi del client, és un codi molt senzill de només dues línies. Com podem veure primer definim la classe persona i abans de cridar el client SOAP instanciem la classe, després usem aquest objecte com a paràmetre a la crida SOAP. Capturem l’objecte que ens retorna el servidor SOAP i a continuació mostrem el seu contingut amb l’ordre print_r.

<?php
/*
 definim classe persona
*/
class persona {
        public $nom;
        function setNom($nom) {
                $this->nom=$nom;
        }
        function setCognom($cognom) {
                $this->cognom=$cognom;
        }
        function getNom() {
                return $this->nom;
        }
        function getCognom() {
                return $this->cognom;
        }
}
/*
 creem objecte tipus persona
*/
$myPersona=new persona;
$myPersona->setNom("el_nom");
$myPersona->setCognom("el_cognom");
/*
 fem una crida SOAP amb un objecte com a parametre
*/
$client = new SoapClient("server.wsdl");
$myObj=$client->peticion($myPersona);
/*
 mostrem objecte generic que retorna la crida SOAP
*/
print_r($myObj);
?>

Si mirem la sortida que ens dona quan cridem el client podem veure que l’objecte que torna no és del tipus persona sinó d’un tipus intern del PHP5 anomenat stdClass. Aquest objecte només disposa dels atributs públics. No podem accedir als atributs privats o protegits i hem perdut tots els mètodes siguin del tipus que siguin.

stdClass Object
(
    [nom] => el_nom
    [cognom] => el_cognom
)

Això és tot el que he pogut aconseguir, no és gaire però com a mínim a mi m’ha estat suficient.

PHP5 – Generant WSDL amb Zend Studio 5.1

Reading time: 3 – 5 minutes

Al programar un webservice amb el PHP5 és més que trivial tal com podem llegir a la documentació sobre SOAP (local) del propi PHP. El problema ve quan volent aprofitar la simplicitat dels serveis SOAP toca programar a mà el WSDL. O sigui, agafa i posat a definir la interficie en XML de la/es classe/s que vols exportar a través del webservice, o sigui, una missión imposible.

La meva sorpresa ha estat veure que després d’adpotar el Zend Studio com a IDE de programació del meu codi PHP he vist que disposava d’un assistent ben senzill d’usar per tal de generar automàticament aquest fitxer WSDL. La cosa és ben senzilla imaginem que usem el codi de l’exemple de la web de Zend, com comentava abans.

El servidor SOAP:

<?php
class QuoteService {
  private $quotes = array("ibm" => 98.42);
	function getQuote($symbol) {
    if (isset($this->quotes[$symbol])) {
      return $this->quotes[$symbol];
    } else {
      throw new SoapFault("Server","Unknown Symbol '$symbol'.");
    }
  }
}
	$server = new SoapServer("server2.wsdl");
$server->setClass("QuoteService");
$server->handle();
?>

El client, encara més simple que el servidor:

<?php
  $client = new SoapClient("server2.wsdl");
  print($client->getQuote("ibm"));
?>

Ara que ja tenim el codi en el nostre Zend, només cal que anem a:

menu.png

Cal seguir l’assistent que no és massa difícil, aquí en teniu els passos capturats per l’exemple del que parlem:

wizard-wsdl-1.png
wizard-wsdl-2.png

Podeu veure com s’exporten automàticament les classes dels arxius que seleccioneu, cal que poseu al costat de cada classe exportada la URL a través de la qual s’accedeix al servei:

wizard-wsdl-3.png

Al final obtenim el fitxer WSDL, en el nostre cas aquest:

<?xml version='1.0' encoding='UTF-8'?>
	<!-- WSDL file generated by Zend Studio. -->
	<definitions name="server2" targetNamespace="urn:server2" xmlns:typens="urn:server2" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/">
	<message name="getQuote">
		<part name="symbol"/>
	</message>
	<message name="getQuoteResponse">
		<part name="getQuoteReturn"/>
	</message>
	<portType name="QuoteServicePortType">
		<operation name="getQuote">
			<input message="typens:getQuote"/>
			<output message="typens:getQuoteResponse"/>
		</operation>
	</portType>
	<binding name="QuoteServiceBinding" type="typens:QuoteServicePortType">
		<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
		<operation name="getQuote">
			<soap:operation soapAction="urn:QuoteServiceAction"/>
			<input>
				<soap:body namespace="urn:server2" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
			</input>
			<output>
				<soap:body namespace="urn:server2" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
			</output>
		</operation>
	</binding>
	<service name="server2Service">
		<port name="QuoteServicePort" binding="typens:QuoteServiceBinding">
			<soap:address location="http://oriol.joor.net/soap/server2.php"/>
		</port>
	</service>
</definitions>

Si sou observadors notareu que aquest fitxer és lleugerament diferent al de la documentació que mostra Zend. Però jo l’he provat i funciona perfectament així doncs no m’hi trencaré el cap en saber a què es deuen aquests petits canvis al implmentar aquest format XML.

SOAP vs XML-RPC

Reading time: 4 – 6 minutes

Abans de començar un detall important sobre el món XML, compte a no acabar com el de la foto:

xml.jpg

Bé doncs ens trobem davant de dos protocols del tipus RPC (Remote Procedure Control), o sigui, que serveixen per intercomunicar dos processos que estan corrent en sistemes dispersos. Si mai ús han donat Sistemes Operatius, segur que us han fet fer la típica pràctica d’RPC d’Unix programada en C. El que acostuma a ser el mal son de tots els alumnes d’informàtica i telemàtica. Doncs bé, tranquils des d’aquella teoria inicial sobre RPC s’ha avançat molt.

De fet, jo fa molt de temps que uso els XML-RPC per implementar web-services senzillets entre les meves aplicacions. Hi ha un protocol que s’usa molt en el món del blogging, es diu ping (no el de tota la vida per mirar si un sistema és viu). Bàsicament el ping el que fa és aprofitar l’XML-RPC per notificar a un altre servei web un event de la nostre web, concretament que hem actualitzat el blog. També s’usa XML-RPC per fer trackback entre articles a diferents blogs. Així podem informar a un altre blog de que hem parlat sobre aquell article que ell ha escrit. Fixeu-vos que tot això és independent del sisteam operatiu, el servidor web, l’aplicació, etc.

Com podeu veure l’XML-RPC esta molt estès i és realment molt útil i senzill d’usar en totes aquestes aplicacions que us comento. Per tant, podriem dir que l’XML-RPC esta orientat a la simplicitat i la senzillesa d’ús, permet passar dades entre processos codificant-les en XML i usant l’HTTP com a protocol de transport. El model de dades que usa l’XML per implementar XML-RPC és molt senzill i si mireu un HTTP-POST que transporti una transacció XML-RPC veureu que és molt senzill entendre les estructures de dades que es monten a partir de les típiques etiquetes.

soap.gif

Llavors ús preguntareu; si l’XML-RPC va tan bé perquè carai vull el SOAP o fins hi tot; què carai és el SOAP. Doncs bé, el Simple Object Access Protocol (SOAP) és un protocol RPC com ja he dit i també es codifica en XML i es transporta sobre HTTP, i encara us diré més també serveix per transportar informació estructurada en el seu interior. La diferència escencial és que és capaç de transportar estructures de dades força complexes i a més permet definir contra quin mètode de quina classe han de ser usades aquestes estructures. Així doncs, el SOAP ens permet oferir infinitat de serveis en un sol biding (publicació) de servei.

Com podeu veure l’escència és la mateixa però la potència és ben diferent. SOAP al suportar models de dades tan complexos fa que quan intentem mirar un XML dels que usa per fer les transaccions ens costi força entendre el que hi ha dintre. Ja que a la mínima que ens compliquem una mica el model de dades a passar pel webservice es fa ben difícil entendre el munt d’etiquetes i d’atributs de les etiquetes que es creen.

A més SOAP disposa de diferents extencions que el fan encara més potent. Bàsicament les més conegudes són SOAP 1.1, SOAP 1.2 i WSDL. Aquest últim és el més usat per implementar WebServices, el seu propi nom ja ens indica aquest fet WSDL: Web Services Description Language. Concretament Microsoft amb .NET, IBM i Sun amb Java fan diverses implementacions del WSDL per tal d’implementar WebServices en les seves arquitectures. Això ens va de perles a la gent que ens agrada el PHP, perquè permet que ens entenguem amb els ASP, JSP, servlets i altres similars des del nostre PHP5 que ja implementa suport de SOAP/WSDL de serie.

Si voleu començar a jugar amb el SOAP i el PHP5, a la pròpia web de Zend podeu trobar aquest document: PHP SOAP Extension. Per una informació més tècnica del WSDL, la gent d’xml.com tenen un munt de documents sobre el tema, concretament us recomano: WSDL first i encara un altre sobre el mateix Examining WSDL. Si ja controleu l’UML és una bona idea que comenceu a veure com es modelen els WSDL des d’UML, un bon document per començar UML for Web Services.

Abans d’acabar l’article si voleu un document seriós que resolgui els vostres dubtes sobre les diferències que hi ha entre XML-RPC i SOAP, sobretot no us perdeu: XML-RPC vs SOAP (local)d’en kate rhodes.