Author: Oriol Rius

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.

Fer un business plan sense tenir-ne ni idea…

Reading time: 2 – 4 minutes

Com sabeu jo sóc telemàtic i això dels negocis ho estic aprenent a base de caure i aixecar-me. Doncs bé estic cansat d’escriure plans de negoci sense tenir un patró clar de quins són els punts que aquest ha de contenir. Així que la setmana passada vaig escriure el que sota la meva opinió és el millor que he escrit, encara no m’han donat feedback de que tal esta. Crec que defineix perfectament el que vull que sigui movilpoint i després de molt de temps i molts esforços jo diria que tots els socis hi estem d’acord.

Però bé, jo l’únic que us volia dir als que tingueu la necessitat de fer-ho i com jo només disposeu de l’ajuda del google que a mi em van anar bé quatre documents que a continuació us enllaço. Es tracte de 4 articles no massa llargs i que si els sumem al fet de tenir les idees molt clares sobre el nostre negoci ens ajudaran a tenir una guia de quins són els punts a tocar i explicar en el que s’ha de convertir en el llibre de navegació del nostre negoci.

  • El plan de marketing en la empresa (local) amb aquest document ja teniu per on començar. Té una minidescripció de tots els punts a tocar al vostre business plan. En el meu cas alguns no calia i en faltaven alguns altres. Però en general m’ha estat molt útil.
  • La matriz DAFO y su aplicación en el ajedrez (local) si com jo això de DAFO us ha sonat a japonés, doncs bé resulta que és un dels punts que s’han de posar en un pla de negoci. Així doncs amb aquest petit document podem resumir les vostres: debilitats, amenaces, fortaleses i oportunintats.
  • Estrategias de Marketing – La Matriz RMG I aquest document ja parla de temes una mica més avançats però si en el vostre business plan voleu realment explicar d’on sortiran els diners en la vostre empresa és una bona idea incloure’l.
  • Estrategias de Marketing – La matriz RMG II la segona part del document que comentava avanç. Com podeu veure aquest tema no és trivial, però tampoc és indispensable en molts casos. Així que no us desanimeu.

En el primer dels documents vaig trobar un quadre resum que m’ha ajudat molt a l’hora de no perdrem escribint. Així que per no perdre aquesta eina tan útil aquí teniu l’enllaç.

protocol de capa 4: SCTP (Stream Control Transmission Protocol)

Reading time: 3 – 4 minutes

Tot navegant per la xarxa fa uns dies que vaig trobar un breu document d’IBM que parlava d’un protocol que fa temps que coneixo però que mai m’havia parat a pensar com funcionava per dintre. Es tracta d’un protocol de la capa de transport que intenta ser una eina molt més precisa i efectiva en alguns problemes que presenten els protocols TCP i UDP al transportar aplicacions d’streaming per sobre seu. Tot i la seva orientació a aplicacions multimèdia es pot usar per moltes altres aplicacions.

stack-ip.gif

Més que fer un resum de les aplicacions que són òptimes corre sobre aquest relativament nou protocol (l’RFC és de l’any 2000) el que jo he trobat molt interessant i que vull explicar una mica aquí són dues funcionalitats que desconeixia completament d’aquest protcol:

1) Multi-homing

En un enllaç podem adreçar el tràfic d’un host a un altre a través de més d’una interficie de xarxa i de més d’una IP. A diferència del protocol TCP les comunicacions no s’estableixen entre un socket que uneix dos hosts, sinó que SCTP ens permet establir connexions que permeten connectar dos hosts a través de més d’una interficie simultaneament. El sorprenent és que el propi protocol de transport, al igual que fa TCP, s’encarrega d’entregar els paquets de forma ordenada a la capa d’aplicació.

esquema1.gif

2) Multi-streaming

Cada paquet SCTP té una associació d’stremas, o sigui, multiples streams en el seu interior. L’importància d’això esta en que, per exemple, quan estem esperant una retransmissió després d’haver perdut un paquet; això no afecta als altres streams de l’associació d’streams. Aquest és el problema més greu que tenim en TCP, perquè si ens falta el paquet inicial aquest bloc d’informació que ens falta bloqueja la resta d’informació que ja hem rebut. Per això, no és gens òptim treballar en connexions TCP si estem usant aplicacions basades en stream de dades. A part dels problemes de sobrecarrega de tràfic que suposa haver de tenir una capçalera tan pesada com la TCP, en protcol que depenen tan de la latència del canal.

esquema2.gif

El document també ens parla d’altres característiques molt interessants d’aquest protocol de transport. Per exemple, que per negociar l’obertura d’un enllaç ja no es fa amb una three-way handshake sinó que s’usa un sistema millorat que evita de forma intrínseca els problemes de SYN flood. La resta de característiques no les he vist especialment interessants així que si les voleu coneixer us convido a llegir el document en que m’he inspirat per escriure això: Better networking with SCTP (local).

error booting gentoo linux: populating /dev with device nodes…

Reading time: 2 – 2 minutes

Des d’ahir a la tarda que li dono voltes a un problema arrancant una gentoo que fa mesos que funcionava sense problemes. La qüestió és que de bones a primeres va començar a donar un problema i no continuava arracant. L’última informació que donava el /sbin/rc era un error a la línia 24 i just abans publicava aquesta informació: populating /dev with device nodes…. L’error era raríssim deia algo així com: /sbin/rc: line 24: cannot redirect standard input from /dev/null gentoo. Aquest línia del fitxer /sbin/rc diu el següent:

linia 23 - einfo " Populating /dev with device nodes..."
linia 24 - try tar -jxpf /lib/udev-state/devices.tar.bz2 -C /dev

Finalment la solució era tan senzilla com comentar la línia 24, fàcil… però complicat de trobar. La solució l’he trobat gràcies a una pàgina boníssima sobre com funciona el UDEV: Computer Help for the New and Veteran User for Linux: UDEV Setup. Realment recomano moltíssim la pàgina és boníssima.

Sobre el meu error jo entenc que el problema és que per algún problema d’incosistència del sistema de fitxers s’ha perdut l’inode que apuntava a devices.tar.bz2 que és una còpia dels fitxers de /dev. Llavors els tar de la línia 24 fallava i és clar no es podia descomprimir. Al comentar-lo l’inici segueix perfectament i els pròpi UDEV genera els fitxers de /dev dinàmicament a mesura que es van requerint.

Jordi Labanda

Reading time: < 1 minute

Doncs fa força temps us vaig parlar de Rion Vernons que feia uns dibuixos guapíssims de noies. Doncs bé gràcies a la nova dissenyadora gràfica que tenim a movilpoint he descobert un nou dissenyador.

Aquest em sembla que és català i ha fet dibuixos de força anuncis famosos, com el de Font Vell. La qüestió és que també agradat el seu estil i per tal de no perdre la referència aquí teniu aquest post.

Com funciona un disc dur…

Reading time: < 1 minute

Tot navegant em vaig trobar aquest video que tenia guardat a l’escriptori, així que com que estic fent-hi neteja el penjo perquè el vegi tothom és molt interessant i el que explica la veu en off encara més:

Servidor USB 1.1

Reading time: 2 – 3 minutes

Potser el concepte us sona una mica extrany, una altre forma de definir-ho seria: bridge USB RJ45/Ethernet. La idea és ben senzilla, vull poder connectar un cable de xarxa convencional amb un petit dispositiu que tingui 4 sortides USB. Després des del windows hi ha d’haver un driver virtual de HUB USB, perquè virtual? doncs perquè el HUB USB no esta físicament connectat al sistema ROOT USB del PC. Així doncs, el driver ha de simular que el realment hi esta connectat, fent de bridge a través de la xarxa ethernet. Doncs això tan extrany que demano existeix, com sempre als EUA i el seu preu és d’uns ~100€. L’única nota negativa que li he troba a part de que només esta disponible a l’altre punta del món és que només és compatible amb USB v1.1, o sigui, 12Mbps com a màxim. Obviament si fos compatible USB v2.0 no podria desenvolupar la potència de 480Mbps que és el que pot donar la v2 de USB, però almenys donaria molt més que els 12Mbps.

Què guanyem amb aquest invent:

  • connectar dispositius USB a més de 100m del PC
  • connectar un dispositiu USB a més d’un PC a la vegada
  • la resta de funcions ja són massa friquis per explicar aquí

Si ens posem a pensar en com funciona el ‘catxarrillo’ no és tan difícil d’implementar. Dins de la caixeta negra hi podriem fer correr un linux embedded i no seria excessivament difícil configurar-lo perquè envies tots els paquets de capa 2 USB per sobre d’IP a través de la xarxa ethernet. La part més pesada de programar seria la del driver windows, osx i/o linux fent la simulació de que el HUB USB esta connectat al ROOT USB com us comentava abans. Però si implementés això de ben segur que hi posaria una giga-ethernet per poder enviar els 480Mbps per sobre dels 1Gbps de la ethernet i així poder connectar-hi qualsevol dispositiu. Malgrat la teoria sempre és molt maca estic segur que alguna cosa faria que hi haguéssin mil problemes, però això fins que no s’intenta mai se sap.

SAX 2006 (Salut Amor i Xarxa)

Reading time: 4 – 6 minutes

La setmana passada vaig agafar la furgo i en Lluis i camí cap a Manresa. On varem assistir a la SAX 2006, ara no recordo si és la segona o tercera edició. Aquesta cita anual és on ens reunim les comunitats lliures de comunicacions sense fils. Durant el matí hi varen haver algunes xerrades tècniques tot i que molt interessants diria que poc preparades, suposo que tots anem de cul. Tot i amb això el nivell tècnic en alguns temes era més que interessant. A veure si l’any que ve ara que ja sé de que va el tema em preparo alguna coseta i així hi aporto el meu granet d’arena.

Després del dinar, que va ser molt suau, tot s’ha de dir. Varem fer una taula rodona molt i molt interessant. On es varen parlar sobretot de temes referents a la inter-relació de totes aquestes comunitats entre elles. Per tal de sumar esforços, tan a nivell tècnic, com de documentació i organització. Jo diria que va ser la part que més s’hauria de descatar en aquestes jornades. Per tal de poder unificar encara més els esforços que com sempre acaben sent massa dispersos. Així doncs la meva proposta en aquest punt seria la de fer unes SAX dels cores de cada xarxa sense fils per tal de parlar de temes específics de col·laboracions entre nosaltres.

En aquest punt de la col·laboració entre xarxes sense fils es va acordar de publicar una especie de Planet RSS de les comunitats(*). Això consisteix en la idea de que cada web, weblog, portal o el que sigui de cada comunitat hauria de disposar de tres categories obligatories de contingut que es publicarien a través d’RSS. Això permetrà que es sindiqui des d’una web central, segurament www.guifi.net aquests continguts des de cada comunitat i que s’autopubliquin. El que es preten aconseguir amb aquesta iniciativa és:

  • No dubplicar esforços en la documentació generada per cada comunitat
  • No explicar de forma redundants noticies que afecten al món del wifi
  • Posar en comú els avenços de la nostre comunitat que poden interessar a la resta de comunitats
  • Tenir un únic punt de consulta d’informacions tècniques, consulta de propostes semblants o iguals
  • Enriquir amb més comentaris els articles que es publiquen, això enriqueix substancialment el contingut del propi autor, ja que en matitza aspectes que l’autor no ha pensat o no ha descrit prou bé
  • Es pot treballar de forma coordinada sense fer un sobre-esforç ja que fent el que fariem de forma normal ho posem en coneixement del resta de comunitats

Com que s’ha de predicar en l’exemple, podreu veure que en el meu bloc he creat una categoria que es diu Wireless dintre hi ha 3 subcategories, que són just les categories que varem acordar que cada comunitat ha de publicar via RSS:

  • eBosc: noticies de la propia comunitat (p.e. novetats eBosc)
  • wireless-docs: documents tècnics i/o informatius sobre wifi (p.e. com configurar un dongle usb wifi en linux)
  • wireless-news: novetats del món wifi: tècniques, productes, normatives, estàndars, etc.

Sota el meu punt de vista el nom de les 3 categories no és gaire important, sempre i quan sigui rellevant respecte el que contenen. A més s’ha de deixar ben clar aquests tres tipus de continguts perquè després es puguin recuperar des del lloc web central. En principi, el drupal que corre a www.guifi.net, el que no recordo és quin tipus d’RSS s’ha de publicar perquè el drupal el pugui importar automàticament a la categoria que toca. A l’espera de parlar aquest tema amb els administradors de guifi.net deixo pendent generar els meus 3 RSS.

Sobre el tema dels RSS als que no estigueu acostumants a treballar amb aquest tipus d’XML’s no us preocupeu ja que ús puc donar suport per tal de que us sigui més senzill fer-ho. A més la majoria d’aplicacions que s’usen avui en dia com a CMS ja suporten aquesta opció de serie. Així que només s’haurà de configurar convenienment el vostre aplicatiu web perquè publiqui els RSS.

Pels que durant la lectura d’aquest article us hagin sonat a japonés algunes de les sigles que he usat, us recomano que llegiu aquest article: ¿Què és RSS, sindicar, weblog, bitacora, etc?.

* Planet is a flexible feed aggregator. It downloads news feeds published by web sites and aggregates their content together into a single combined feed, latest news first.

Scroll to Top