oriolrius.cat

Des del 2000 compartiendo sobre…

Category: Development, Models and Methodologies

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>

php: SimpleXML i xml2array

Reading time: < 1 minute

Dues funcions potentissimes de PHP, sobretot ara que cada dos per tres hem de treballar amb fitxers XML.

$xml = simplexml_load_file('fitxer.xml');

Llegeix el fitxer.xml del disc dur i el converteix en un objecte de la classe SimpleXMLElement. Per veure en què es converteix es pot usar print_r.

Ara que ja tenim les dades en forma d’objecte si encara no ens agraden podem convertir-les en un array amb una sola funció:

$varArray = get_object_vars($objXml);

També amb un print_r podem veure un array dels de tota la vida.

Sovint la potència esta en la simplicitat… val la pena no perdre de vista aquestes funcions.

cookbook: importar projecte de symfony al subversion

Reading time: 2 – 2 minutes

Petit cookbook de com hem d’importar un projecte que estiguem programant amb el framework symfony. Primer creem el directori del repositori on volem pujar el projecte, anem al directori del projecte. Borrem els directoris log i cache del qual no ens interessa mantenir un control de versions. I després importem el projecte.

svn mkdir -m "NOTA: Creem directori on hi posarem projecte" http://exemple.com/svn/repos/projecte/dev
cd directori_projecte_symfony
rm -rf log
rm -rf cache
svn import -m "NOTA: importem primera versio del projecte" . http://exemple.com/svn/repos/projecte/dev

Ara movem el directori actual del projecte i en creem un de nou, que ja tindrà control de versions. Fem un checkout (co) de la versió que em importat abans i defenim que els directoris log i cache no s’importaràn mai quan fem un commit (ci). Després creem els directoris en qüestió i els assignem un propietari igual al del procés d’apache perquè aquest el pugui escriure-hi mentre esta execucutant el nostre projecte symfony.

mv directori_projecte_symfony directori_projecte_symfony.bak
mkdir directori_projecte_symfony_amb_svn
cd directori_projecte_symfony_amb_svn
svn co http://exemple.com/svn/repos/projecte/dev .
svn propedit svn:ignore .
log
cache
mkdir log
mkdir cache
chown apache:apache log
chown apache:apache cache

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.

Aprenent PROPEL amb 30min

Reading time: 2 – 4 minutes

Propel és un framework de PHP que permet accedir a les bases de dades usant objectes, ens ofereix una API molt senzilla que és capaç de filtrar les queries contra la base de dades perquè sigui completament transparents a la nostre aplicació. Perquè ens entenguem estem parlant de coses que de ben segur coneixeu com ara el DAO o el ORM.

grafic-propel.gif

Per fer-nos una idea per definir l’estructura d’una base de dades només cal que escribim un fitxer XML amb els camps de les taules, tipus, relacions, etc i el Propel farà la resta. Llavors el Propel es posa a generar totes les classes automàticament, i els fitxers .sql amb els esquemes de definició de les bases de dades. Amb les classes que ens ha generat el Propel podem accedir a totes les funcions bàsiques d’accés a la base de dades és el que se’n diu CRUD (def.wikipedia).

Si voleu aprofundir en tema us recomano que seguiu els passos que vaig seguir jo i amb 30min us sentireu com de la família:

  • QuickStart – Com crear les BBDD, taules i altre elements al voltant de les dades per tal de poder treballar de forma trivial amb elles
  • CRUD explica com usar les funcions bàsiques de CRUD amb Propel.
  • Esquemes dels fitxers XML. Quan definim l’esquema de la BBDD ens interessa coneixer a fons la sintaxis suportada per tal d’aprofitar al màxim les funcions del propel
  • Relacions entre taules. Donant una mica d’emoció a les dades, usant relacions entre taules senzilles.
  • Captura d’errors. Si ens interessa unificar les sortides d’error de Propel és molt senzill fer-ho.
  • Les relacions many-to-many (molts-a-molts) no estan suportades directament pel propel i s’han de fer a través d’una taula intermitja. Malgrat ens permet sortir del pas és un dels punts a evolucionar dins de propel. Si ens interessa millorar aquesta part podem incloure les nostres classes que implementin això pel nostre codi sense problemes dins de l’estructura estàndard del propel. De moment, si ho volem fer tal i com ens proposa el manual.

PHP4 vs PHP5

Reading time: 2 – 3 minutes

Tot llegint el PHP|Architect’s Guide to PHP Design Patterns (isbn: 0973589825) vaig trobar fa un parell de dies un petit llistat de quines eres les diferencies fonamentals entre PHP4 i PHP5, a part del tòpic que amb el motor de Zend 2.1 ara tenim suport de OOP i de que tothom em digui que el model d’objectes que usa PHP5 encara és molt dolent doncs bé amb això podrem saber fins a quin punt ho és.

  • Object handles
  • Better constructors (uniform name, changing $this not allowed)
  • Destructors now exist
  • Visibility (public, protected, private for methods and attributes)
  • Exceptions (an alternative to triggering errors using the new try{} catch{} syntax)
  • Classconstants (defines using the class for a name space)
  • Reflection (dynamic examination of classes, methods and arguments)
  • Type hinting (specifying expected classes or interfaces for method arguments)

També hi podem trobar altres novetats una mica menys conegudes:

  • New magic methods (__get() and __set() allow you to control attribute access; __call() lets you dynamically intercept all method calls to the object; __sleep() and __wakeup() let you override serialization behavior; and __toString() lets you control how an object represents itself when cast as a string)
  • Autoloading (allows the end user to try to automatically load the class the first time a reference to it is made)
  • Final (do not allow a method or a class to be overridden by subclasses)

A més hi ha coses com la part d’object handles que donen molt de si:

  • Create an object by reference, as in $obj =& new Class;
  • Pass an object by reference, like function funct(&$obj_param) {}
  • Catch an object by reference function &some_funct() {} $returned_obj =&
    some_funct()

En escència el que més m’ha agradat ho teniu resumit aquí, ja sé que esta en anglès però em feia una mandra brutal traduir-ho. Si m’animo un dia d’aquests donaré més detalls de com aprofitar aquestes avantatges per implementar design patterns amb PHP5. Realment ja comences a sentir-te com un programador de veritat quan veus que el PHP5 no té cap problema en suportar estructures que fins ara li quedaben tan lluny.

UML – Procés de desenvolupmanet OO de Craig Larman

Reading time: 2 – 2 minutes

uml.gif

Dels molts documents que he estat llegint les últimes setmanes especialment n’hi ha un de només 38 pàgines que l’he trobat ideal per fer-ne una guia de passos de com modelar un sistema OO amb UML. Aquest document bàsicament explica un mètodes anomenat de Craig Larman (wikipedia).

Doncs basant-me en aquest document amb el “tallar” i “engaxar” contra el meu wiki m’he fet un petit document resum ideal per usar com a eina de consulta durant el desenvolupament d’un projecte. És curiós perquè tret d’algunes frases per unir conceptes la resta l’he extret directament del document inicial i m’ha quedat força bé, almenys això em sembla a mi. Per altre banda, li vull agraïr a l’autor del document original Juan de Dios Bátíz Paredes la seva feina ja que m’ha estat molt útil, si voleu ampliar conceptes o veure exemples del que explica el meu resum obviament els trobareu al document d’aquest senyor.

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.

Aprenent UML

Reading time: 2 – 2 minutes

uml.gif

Ja he repetit mil vegades que no sóc informàtic, així doncs, mai havia après UML fins aquest cap de setmana que aprofitant que estava de Rodriguez m’he fotut una marató d’aquelles que feia temps que no feia.Doncs per tal de posar remei a la meva mancança en el tema UML m’he llegit/estudiat el llibre Aprenda UML en 24 Horas (editorial: Prentice Hall. 2001. Autor: J. Schmuller. ISBN: 968444463X. link amazon).

La veritat és que encara estic destrossat de l’esforç però us recomano el llibre. Realment no és res de l’altre món però si com jo teniu un problema i no pas la teoria per plantejar-lo, doncs jo diria que és la millor solució que he trobat per avui dilluns haver-lo pogut afrontar ja amb UML directament. M’ha agradat molt el fet que esta orientat a objectes tot el que explica això ja et permet pensar ràpidament en conceptes que coneixes i que et permeten avançar moltíssim.

Una altre cosa important del llibre és que no comença amb la pesada teoria de l’UML sinó que va directament a ensenyar-te a usar les eines, és a la segona part del llibre on tot això es posa en pràctica en un problema real i llavors et queda ben clar com s’han d’usar totes aquestes eines. Ara com sempre passa quan entres en una matèria que fins ara era nova és que tinc el gusanillo d’aprofundir més en alguns conceptes especialment en temes de Design Patterns.