Entrades classificades amb: XML

Introducció a JSON

Leer en castellano 

JSON (Notació d’Objectes de JavaScript) és un format lleuger d’intercanvi de dades el qual està basat en un subconjunt literal d’objectes del Llenguatge de Programació JavaScript.
Llegir-lo i escriure-ho és simple per persones, mentre que per a les màquines és simple d’interpretar i generar-lo. JSON és un format de text que és completament independent del llenguatge de programació però utilitza convencions que són àmpliament conegudes pels programadors de la família de llenguatges C, incloent C++, C#, Java, JavaScript, Perl, i molts altres.
Aquestes propietats fan que JSON sigui un llenguatge ideal per a l’intercanvi de dades i una molt bona alternativa (o complement) a XML degut a la seva simplicitat i lleugeresa.

JSON està constituït per dues estructures:

– Una col•lecció de parells de nom/valor. En diversos llenguatges això és conegut com un objecte, registre, estructura, diccionari, taula hash, llista de claus o un arranjament associatiu.
– Una llista ordenada de valors. En la majoria dels llenguatges, això s’implementa com arranjaments, vectors, llistes o seqüències.

Els vectors i altres estructures seqüencials per l’estil són estructures universals; virtualment tots els llenguatges de programació les suporten d’una manera o altra. És raonable que un format d’intercanvi de dades que és independent del llenguatge de programació es basi en aquestes estructures.

En JSON, les estructures es presenten d’aquestes formes:

– Un objecte és un conjunt desordenat de parells nom/valor. Un objecte comença amb “{“ (clau d’obertura) i acaba amb “}” (clau de tancament). Cada nom és seguit per dos punts i els parells nom / valor estan separats per una coma.
– Un vector es una col•lecció de valors que comença amb “[“ i acaba amb “]”. Els valors es separen per una coma.
– Un valor pot ser una cadena de caràcters amb cometes dobles, o un número , o true o false o null, o un objecte o un vector. Les estructures poden ser niades.
– Una cadena de caràcters es una col•lecció de 0 o més caràcters Unicode, tancats entre cometes dobles i usant barres divisòries invertides com escape. Un caràcter esta representat per una cadena de caràcters d’un únic caràcter.
– Un número es similar a un número en C o JAVA , excepte que no es fan servir els formats octals i hexadecimals.

Aquí un exemple simple per la definició d’una barra de menús:

{“menu”: {
“id”: “file”,
“value”: “File”,
“popup”: {
“menuitem”: [
{“value”: “New”, “onclick”: “CreateNewDoc()”},
{“value”: “Open”, “onclick”: “OpenDoc()”},
{“value”: “Close”, “onclick”: “CloseDoc()”}
]
}
}
}

La representació JSON es descriu en relació amb la representació XML de la següent manera:

– Els noms dels membres d’objecte JSON són els mateixos que els noms dels elements i atributs XML, inclosos els elements que poden repetir-se.
– En els tipus de dades, el tipus primitiu integer es representa mitjançant un int nadiu JSON, mentre la dada booleana en JSON es representa mitjançant els valors “true” i “false”. Altres tipus primitius com els strings, els decimals, etc es representen com una cadena JSON, utilitzant la mateixa serialització com la forma XML (incloent instant, que es representa com a text pla, no en un dels formats de data JSON personalitzats proposats).
– Igual que en XML, els atributs de propietat JSON mai tenen valors buits, s’omet un valor si està buit.

Hi ha diferències també:

– No hi ha espais de noms (namespaces) en la representació JSON.
– L’ordre no és significatiu en la representació JSON.
– JSON no té una noció d’atributs davant dels elements, de manera que els atributs (xml: id, valor) són tractats com a membres d’objectes JSON.
– JSON té una notació per als vectors i matrius, que s’utilitza per a representar elements que es repeteixen. Cal tenir en compte que aquest és el cas, inclús encara si no es repeteixen en la instància particular.
– L’element <div> XHTML en el tipus de dades narrativa es representa com una sola cadena escapada de XHTML. Això és per evitar problemes en JSON amb contingut mixt etc. XHTML majoritàriament s’ajusta a les regles descrites anteriorment.
– També es pot mencionar que JSON és més lleuger que el format XML a l’ocupar menys espai i representar millor les estructures de les dades.

Exemples per contrastar XML i JSON:

el següent fragment en XML:

<date value=”1972-11-30″/>
<deceased value=”false”/>
<count value=”23″/>

està representat en JSON com:

“date” : { value: “1972-11-30” }
“deceased” : { value: false }
“count” : { value: 23 }

Tots els elements XML poden tenir un atribut ‘id’, que es representa en JSON com una propietat de nom “_id”:

el següent fragment en XML:

<dob id=”314159″ value=”1972-11-30″/>

està representat en JSON com:

“dob”: {
“_id”: “314159”,
“value”: “1972-11-30”
}

Repetició d’elements:

Els elements repetits es fonen dins d’un vector JSON amb el nom de l’element, de manera que si un element <dob> es repeteix en XML, en JSON queda dins d’un vector.

el següent fragment en XML:

<dob value=”2011-11-30″/>
<dob id=”314159″ value=”1972-11-30″/>

està representat en JSON d’aquesta manera:

“dob”: [
{“value”: “2011-11-30”},
{“_id”: “314159”, “value”: “1972-11-30”}
]

 

Llegir en català 

JSON (Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos el cual está basado en un subconjunto literal de objetos del Lenguaje de Programación JavaScript.
Leerlo y escribirlo es simple para personas, mientras que para las máquinas es simple de interpretar y generarlo. JSON es un formato de texto que es completamente independiente del lenguaje de programación pero utiliza convenciones que son ampliamente conocidas por los programadores de la familia de lenguajes C, incluyendo C++, C #, Java, JavaScript, Perl, y muchos otros.
Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos y una muy buena alternativa (o complemento) a XML debido a su simplicidad y ligereza.

JSON está constituido por dos estructuras:

– Una colección de pares de nombre/valor. En varios lenguajes esto es conocido como un objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arreglo asociativo.
– Una lista ordenada de valores. En la mayoría de los lenguajes, esto se implementa como arreglos, vectores, listas o secuencias.

Los vectores y otras estructuras secuenciales por el estilo son estructuras universales; virtualmente todos los lenguajes de programación las soportan de una manera u otra. Es razonable que un formato de intercambio de datos que es independiente del lenguaje de programación se base en estas estructuras.

En JSON, las estructuras se presentan de estas formas:

– Un objeto es un conjunto desordenado de pares nombre/valor. Un objeto comienza con “{” (llave de apertura) y termina con “}” (llave de cierre). Cada nombre es seguido por dos puntos y los pares nombre / valor están separados por una coma.
– Un vector es una colección de valores que empieza con “[” y termina con “]”. Los valores se separan por una coma.
– Un valor puede ser una cadena de caracteres con comillas dobles, o un número, o true o false o null, o un objeto o un vector. Las estructuras pueden ser anidadas.
– Una cadena de caracteres es una colección de 0 o más caracteres Unicode, encerrados entre comillas dobles y usando barras divisorias invertidas como escape. Un carácter está representado por una cadena de caracteres de un único carácter.
– Un número es similar a un número en C o JAVA, excepto que no se usan los formatos octales y hexadecimales.

Aquí un ejemplo simple para la definición de una barra de menús:

{“menu”: {
“id”: “file”,
“value”: “File”,
“popup”: {
“menuitem”: [
{“value”: “New”, “onclick”: “CreateNewDoc()”},
{“value”: “Open”, “onclick”: “OpenDoc()”},
{“value”: “Close”, “onclick”: “CloseDoc()”}
]
}
}
}

La representación JSON se describe en relación con la representación XML de la siguiente manera:

– Los nombres de los miembros de objeto JSON son los mismos que los nombres de los elementos y atributos XML, incluidos los elementos que pueden repetirse.
– En los tipos de datos, el tipo primitivo integer se representa mediante un int nativo JSON, mientras el dato booleana en JSON se representa mediante los valores “true” y “false”. Otros tipos primitivos como los strings, los decimales, etc se representan como una cadena JSON, utilizando la misma serialización como la forma XML (incluyendo instante, que se representa como texto plano, no en uno de los formatos de fecha JSON personalizados propuestos).
– Al igual que en XML, los atributos de propiedad JSON nunca tienen valores vacíos, se omite un valor si está vacío.

Hay diferencias también:

– No hay espacios de nombres (namespaces) en la representación JSON.
– El orden no es significativo en la representación JSON.
– JSON no tiene una noción de atributos ante los elementos, de modo que los atributos (xml: id, valor) son tratados como miembros de objetos JSON.
– JSON tiene una notación para los vectores y matrices, que se utiliza para representar elementos que se repiten. Hay que tener en cuenta que este es el caso, incluso aún si no se repiten en la instancia particular.
– El elemento <div> XHTML en el tipo de datos narrativa se representa como una sola cadena escapada de XHTML. Esto es para evitar problemas en JSON con contenido mixto etc. XHTML mayoritariamente se ajusta a las reglas descritas anteriormente.
– También se puede mencionar que JSON es más ligero que el formato XML al ocupar menos espacio y representar mejor las estructuras de los datos.

Ejemplos para contrastar XML i JSON:

el siguiente fragmento en XML:

<date value=”1972-11-30″/>
<deceased value=”false”/>
<count value=”23″/>

está representado en JSON como:

“date” : { value: “1972-11-30” }
“deceased” : { value: false }
“count” : { value: 23 }

Todos los elementos XML pueden tener un atributo ‘id’, que se representa en JSON como una propiedad de nombre “_id”:

el siguiente fragmento en XML:

<dob id=”314159″ value=”1972-11-30″/>

está representado en JSON como:

“dob”: {
“_id”: “314159”,
“value”: “1972-11-30”
}

Repetició d’elements:

Los elementos repetidos se unen dentro de un vector JSON con el nombre del elemento, de manera que si un elemento <dob> se repite en XML, en JSON queda dentro de un vector.

el siguiente fragmento en XML:

<dob value=”2011-11-30″/>
<dob id=”314159″ value=”1972-11-30″/>

está representado en JSON de la siguiente manera:

“dob”: [
{“value”: “2011-11-30”},
{“_id”: “314159”, “value”: “1972-11-30”}
]

 

Introducció als Serveis Web RESTful

Leer en castellano

Els serveis web REST (Transferència d’estat representacional) defineixen un conjunt de principis arquitectònics pels quals es dissenyen serveis web fent focus en els recursos del sistema, incloent com s’accedeix a l’estat d’aquests recursos i com es transfereixen per protocol HTTP cap a clients escrits en diversos llenguatges. REST ha emergit en els últims anys com el model predominant per al disseny de serveis. De fet, REST va aconseguir un impacte tan gran a la web que pràcticament va aconseguir desplaçar a SOAP i les interfícies basades en WSDL per tenir un estil bastant més simple d’utilitzar.

Es basa en 4 principis que descriuen la seva manera en que està implementat:

– Utilitza els mètodes HTTP de manera explícita.
– No manté l’estat.
– Exposa URIs amb forma de directoris.
– Transfereix XML, JavaScript Object Notation (JSON), o tots dos.

Utilitza els mètodes HTTP de manera explícita:
Una de les característiques claus dels serveis web REST és l’ús explícit dels mètodes HTTP, seguint el protocol definit per RFC 2616. Per exemple, HTTP GET es defineix com un mètode productor de dades, l’ús està pensat perquè les aplicacions client obtinguin recursos, busquin dades d’un servidor web, o executin una consulta esperant que la web la realitzi i retorni un conjunt de recursos .

REST fa que els desenvolupadors usin els mètodes HTTP explícitament de manera que resulti consistent amb la definició del protocol. Aquest principi de disseny bàsic estableix una associació un-a-un entre les operacions de crear, llegir, actualitzar i esborrar i els mètodes HTTP.

D’acord a aquesta associació:

–    S’usa POST per crear un recurs al servidor.
–    S’usa GET per obtenir un recurs.
–    S’usa PUT per canviar l’estat d’un recurs o actualitzar.
–    S’usa DELETE per eliminar un recurs.

Una falla de disseny poc afortunada que tenen moltes APIs web és l’ús de mètodes HTTP per a altres propòsits. Per exemple, la petició de la URI en una comanda HTTP GET, en general identifica un recurs específic. O el string de consulta al URI inclou un conjunt de paràmetres que defineixen el criteri de recerca que farà servir el servidor per trobar un conjunt de recursos. Almenys, així com el RFC HTTP/1.1 descriu l’GET.

No manté l’estat:
Els serveis web REST necessiten escalar per poder satisfer una demanda en constant creixement. S’usen clústers de servidors amb balanceig de càrrega i alta disponibilitat, proxies, i gateways de manera de conformar una topologia servicial, que permeti transferir peticions d’un equip a un altre per disminuir el temps total de resposta d’una invocació al servei web.
L’ús de servidors intermedis per millorar l’escalabilitat fa necessari que els clients de serveis web REST enviïn peticions completes i independents, és a dir, s’han d’enviar peticions que inclouen totes les dades necessàries per complir la comanda, de manera que els components en els servidors intermedis puguin redireccionar i gestionar la càrrega sense mantenir l’estat localment entre les peticions.

Una petició completa i independent fa que el servidor no hagi de recuperar cap informació de context o estat en processar la petició. Una aplicació o client de servei web REST  ha d’incloure dins de la capçalera i del cos HTTP de la petició tots els paràmetres, context i dades que necessita el servidor per generar la resposta. D’aquesta manera, el no mantenir estat millora el rendiment dels serveis web i simplifica el disseny i implementació dels components del servidor, ja que l’absència d’estat al servidor elimina la necessitat de sincronitzar les dades de la sessió amb una aplicació externa.

Exposa URIs amb forma de directoris:
Des del punt de vista del client de l’aplicació que accedeix a un recurs, la URI determina què tan intuïtiu serà el web service REST, i si el servei va a ser utilitzat tal com va ser pensat al moment de dissenyar-lo. La tercera característica dels serveis web REST és justament sobre les URIs.

Les URI dels serveis web REST han de ser intuïtives, fins al punt que sigui fàcil endevinar. Pensem en les URI com una interfície auto-documentada que necessita de molt poca o cap explicació o referència perquè un desenvolupador pugui comprendre al que apunta, i als recursos derivats relacionats.

Una forma d’aconseguir aquest nivell d’usabilitat és definir URIs amb una estructura a l’estil dels directoris. Aquest tipus d’URIs és jeràrquica, amb una única ruta arrel, i va obrint branques a través de les subrutes per exposar les àrees principals del servei. D’acord a aquesta definició, una URI no és només una cadena de caràcters delimitada per barres, sinó més aviat un arbre amb subordinats i pares organitzats com a nodes. Per exemple, en un servei de fils de discussions que té temes diversos, es podria definir una estructura d’URI com aquesta:

http://www.elmeuservei.org/discusio/temes/ {tema}

L’arrel, /discusio, té un node /temes com fill. Sota aquest node hi ha un conjunt de noms de temes (com ser tecnologia, actualitat, i més), cadascun dels quals apunta un fil de discussió. Dins d’aquesta estructura, resulta fàcil recuperar fils de discussió al tipejar alguna cosa després d’/ temes /.

En alguns casos, la ruta a un recurs encaixa molt bé dins la idea de “estructura de directoris”. Per exemple, prenguem alguns recursos organitzats per data, que són molt pràctics d’organitzar usant una sintaxi jeràrquica.

Transfereix XML, JavaScript Object Notation (JSON), o tots dos:
La representació d’un recurs en general reflecteix l’estat actual del mateix i els seus atributs al moment en què el client de l’aplicació realitza la petició. La representació del recurs són simples “fotos” en el temps. Això podria ser una representació d’un registre de la base de dades que consisteix en l’associació entre columnes i tags XML, on els valors dels elements en l’XML contenen els valors de les files. O, si el sistema té un model de dades, la representació d’un recurs és una fotografia dels atributs d’una de les coses en el model de dades del sistema.

L’última restricció al moment de dissenyar un servei web REST té a veure amb el format de les dades que l’aplicació i el servei s’intercanvien en les peticions/respostes. Aquí és on realment val la pena mantenir les coses simples, llegibles per persones, i connectades.

Els objectes del model de dades generalment es relacionen d’alguna manera, i les relacions entre els objectes del model de dades (els recursos) s’han de reflectir en la forma en què es representen al moment de transferir les dades al client. En el servei de fils de discussió anterior, un exemple d’una representació d’un recurs connectat podria ser un tema de discussió arrel amb tots els seus atributs, i links embeguts a les respostes al tema.

<discusio data=”{data}” tema=”{tema}”>
<comentari> {comentari} </comentari>
<respostes>
<resposta de = “gaz@mail.com “href =” /discussió/temes/{tema}/gaz “/>
<resposta de = “gir@mail.com “href =” /discussió/temes/{tema}/gir “/>
</respostes>
</discusio>

Conclusió: No sempre REST és la millor opció. Està sorgint com una alternativa per dissenyar serveis web amb menys dependència en middleware propietari (per exemple, un servidor d’aplicacions), que el seu contrapart SOAP i els serveis basats en WSDL. D’alguna manera, REST és la volta a la Web abans de l’aparició dels grans servidors d’aplicacions, ja que fa èmfasi en els primers estàndards d’Internet, URI i HTTP. XML sobre HTTP és una interfície molt poderosa que permet que aplicacions internes, com interfícies basades en JavaScript asíncron + XML (AJAX) puguin connectar-se, situar i consumir recursos. De fet, és justament aquesta gran combinació amb AJAX la que va generar aquesta gran atenció que ha tingut REST avui en dia.
Resulta molt flexible el poder exposar els recursos del sistema amb un API REST, de manera de brindar dades a diferents aplicacions, formats en diferents maneres. REST ajuda a complir amb els requeriments d’integració que són crítics per construir sistemes on les dades s’han de poder combinar fàcilment i estendre. Des d’aquest punt de vista, els serveis REST es converteixen en alguna cosa molt més gran.

Llegir en català

Los servicios web REST (Transferencia de estado representacional) definen un conjunto de principios arquitectónicos por los que se diseñan servicios web haciendo foco en los recursos del sistema, incluyendo cómo se accede al estado de estos recursos y cómo se transfieren por protocolo HTTP a clientes escritos en varios lenguajes. REST ha emergido en los últimos años como el modelo predominante para el diseño de servicios. De hecho, REST logró un impacto tan grande en la web que prácticamente logró desplazar a SOAP y las interfaces basadas en WSDL por tener un estilo bastante más simple de utilizar.

Se basa en 4 principios que describen su forma en que está implementado:

– Utiliza los métodos HTTP de manera explícita.
– No mantiene el estado.
– Expone URIs con forma de directorios.
– Transfiere XML, JavaScript Object Notation (JSON), o ambos.

Utiliza los métodos HTTP de manera explícita:
Una de las características claves de los servicios web REST es el uso explícito de los métodos HTTP, siguiendo el protocolo definido por RFC 2.616. Por ejemplo, HTTP GET se define como un método productor de datos, el uso está pensado para que las aplicaciones cliente obtengan recursos, busquen datos de un servidor web, o ejecuten una consulta esperando que la web la realice y devuelva un conjunto de recursos.

REST hace que los desarrolladores usen los métodos HTTP explícitamente de manera que resulte consistente con la definición del protocolo. Este principio de diseño básico establece una asociación uno-a-uno entre las operaciones de crear, leer, actualizar y borrar y los métodos HTTP.

De acuerdo a esta asociación:

– Se usa POST para crear un recurso en el servidor.
– Se usa GET para obtener un recurso.
– Se usa PUT para cambiar el estado de un recurso o actualizar.
– Se usa DELETE para eliminar un recurso.

Una falla de diseño poco afortunada que tienen muchas APIs web es el uso de métodos HTTP para otros propósitos. Por ejemplo, la petición de la URI en un pedido HTTP GET, en general identifica un recurso específico. O el string de consulta al URI incluye un conjunto de parámetros que definen el criterio de búsqueda que utilizará el servidor para encontrar un conjunto de recursos. Al menos, así como el RFC HTTP/1.1 describe el GET.

No mantiene el estado:
Los servicios web REST necesitan escalar para poder satisfacer una demanda en constante crecimiento. Se usan clústeres de servidores con balanceo de carga y alta disponibilidad, proxies, y gateways de manera de conformar una topología servicial, que permita transferir peticiones de un equipo a otro para disminuir el tiempo total de respuesta de una invocación al servicio web.
El uso de servidores intermedios para mejorar la escalabilidad hace necesario que los clientes de servicios web REST envíen peticiones completas e independientes, es decir, se deben enviar peticiones que incluyen todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan redireccionar y gestionar la carga sin mantener el estado localmente entre las peticiones.

Una petición completa e independiente hace que el servidor no tenga que recuperar ninguna información de contexto o estado al procesar la petición. Una aplicación o cliente de servicio web REST debe incluir dentro de la cabecera y del cuerpo HTTP de la petición todos los parámetros, contexto y datos que necesita el servidor para generar la respuesta. De esta manera, el no mantener estado mejora el rendimiento de los servicios web y simplifica el diseño e implementación de los componentes del servidor, ya que la ausencia de estado en el servidor elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa.

Expone URIs con forma de directorios:
Desde el punto de vista del cliente de la aplicación que accede a un recurso, la URI determina qué tan intuitivo será el servicio web REST, y si el servicio va a ser utilizado tal como fue pensado al momento de diseñarlo. La tercera característica de los servicios web REST es justamente sobre las URIs.

Las URI de los servicios web REST deben ser intuitivas, hasta el punto que sea fácil adivinar. Pensamos en las URI como una interfaz auto-documentada que necesita de muy poca o ninguna explicación o referencia para que un desarrollador pueda comprender al que apunta, y los recursos derivados relacionados.

Una forma de lograr este nivel de usabilidad es definir URIs con una estructura al estilo de los directorios. Este tipo de URIs es jerárquica, con una única ruta raíz, y abriendo ramas a través de las subrutas para exponer las áreas principales del servicio. De acuerdo a esta definición, una URI no es sólo una cadena de caracteres delimitada por barras, sino más bien un árbol con subordinados y padres organizados como nodos. Por ejemplo, en un servicio de hilos de discusiones que tiene temas diversos, se podría definir una estructura de URI como esta:

http://www.miservicio.org/discusion/temas/ {tema}

La raíz, /discusión, tiene un nodo /temas como hijo. Bajo este nodo hay un conjunto de nombres de temas (como ser tecnología, actualidad, y más), cada uno de los cuales apunta un hilo. Dentro de esta estructura, resulta fácil recuperar hilos de discusión en tipear alguna cosa después de /temas/.

En algunos casos, la ruta a un recurso encaja muy bien dentro de la idea de “estructura de directorios”. Por ejemplo, tomemos algunos recursos organizados por fecha, que son muy prácticos de organizar usando una sintaxis jerárquica.

Transfiere XML, JavaScript Object Notation (JSON), o ambos:
La representación de un recurso en general refleja el estado actual del mismo y sus atributos al momento en que el cliente de la aplicación realiza la petición. La representación del recurso son simples “fotos” en el tiempo. Esto podría ser una representación de un registro de la base de datos que consiste en la asociación entre columnas y tags XML, donde los valores de los elementos en el XML contienen los valores de las filas. O, si el sistema tiene un modelo de datos, la representación de un recurso es una fotografía de los atributos de una de las cosas en el modelo de datos del sistema.

La última restricción al momento de diseñar un servicio web REST tiene que ver con el formato de los datos que la aplicación y el servicio se intercambian en las peticiones / respuestas. Aquí es donde realmente vale la pena mantener las cosas simples, legibles por personas, y conectadas.

Los objetos del modelo de datos generalmente se relacionan de alguna manera, y las relaciones entre los objetos del modelo de datos (los recursos) se reflejarán en la forma en que se representan en el momento de transferir los datos al cliente. En el servicio de hilos de discusión anterior, un ejemplo de una representación de un recurso conectado podría ser un tema de discusión raíz con todos sus atributos, y links embebidos en las respuestas al tema.

<discusion data=”{data}” tema=”{tema}”>
<comentario> {comentario} </comentario>
<respuestas>
<respuesta de = “gaz@mail.com “href =” /discusion/temas/{tema}/gaz “/>
<respuesta de = “gir@mail.com “href =” /discusion/temas/{tema}/gir “/>
</respuestas>
</discusion>

Conclusión: No siempre REST es la mejor opción. Está surgiendo como una alternativa para diseñar servicios web con menos dependencia en middleware propietario (por ejemplo, un servidor de aplicaciones), que su contraparte SOAP y los servicios basados en WSDL. De alguna manera, REST es la vuelta a la Web antes de la aparición de los grandes servidores de aplicaciones, ya que hace hincapié en los primeros estándares de Internet, URI y HTTP. XML sobre HTTP es una interfaz muy poderosa que permite que aplicaciones internas, como interfaces basadas en JavaScript asíncrono + XML (AJAX) puedan conectarse, ubicar y consumir recursos. De hecho, es justamente esta gran combinación con AJAX la que generó esta gran atención que ha tenido REST hoy en día.
Resulta muy flexible el poder exponer los recursos del sistema con un API REST, de manera de brindar datos a diferentes aplicaciones, formatos en diferentes maneras. REST ayuda a cumplir con los requerimientos de integración que son críticos para construir sistemas donde los datos deben poder combinar fácilmente y extender. Desde este punto de vista, los servicios REST se convierten en algo mucho más grande.

Efficient XML Interchange

Leer en castellano

En aquest post mostrarem una tecnologia per transmetre els fitxers XML d’una manera més ràpida, especialment dissenyat per les tecnologies d’avui en dia, com poden ser els smartphones. Un cop introduida, farem una prova treballant en el camp dels estàndards (concretament amb l’estàndard CDA R2) i veurem l’impacte que crea aquesta tecnologia sobre fitxers CDA XML.

EXI (Efficient XML Interchange) és un format de dades proposat per el Efficient XML Interchange Working Group, i ja es considera estandard W3C. L’objectiu d’aquest format és codificar documents XML en un format binari, per reduir l’espai dels missatges, i permetre una transmissió entre dispositius molt més àgil.

Format

Un document EXI està format per un EXI Header i un EXI Body.

EXI Header

Conté les propietats de codificació necessàries per poder codificar i descodificar l’EXI-stream. La mida mínima de capçalera és de 1 byte, per tant podem considerar que té un overhead molt baix.

EXI Body

El cos d’un document EXI esta composat per events EXI. Els ítems XML es codifiquen en un o més EXI events. Els events s’agrupen seguint una definició de gramàtica, per veure els elements que es repeteixen més o menys, per codificar la informació en funció d’això, i pode r comprimir molt més la cadena, semblant al mètode de compressió dels codis Huffman. La idea és comprimir al màxim l’espai que ocupen els “tags” de l’XML, que solen repetir-se molt.

Primer mostrem un exemple d’XML qualsevol:

<?xml version="1.0" encoding="UTF-8"?>
<notebook date="2007-09-12">
<note category="EXI" date="2007-07-23">
<subject>EXI</subject>
<body>Do not forget it!</body>
</note>
<note date="2007-09-12">
<subject>Shopping List</subject>
<body>milk, honey</body>
</note>
</notebook>

Aquest XML es representa en EXI events de la següent forma:

Un cop tenim els EXI events, s’ordenen per poder fer la compressió dels tags:


Rendiment

Per veure una prova del rendiment d’aquest mètode, farem un parell de proves amb fitxers XML, amb propietats diferents.

Compressió de fitxer d’espirometria propietari

Baix rendiment degut a les poques repeticions de tags, ja que cada tag és diferent, per transmetre cada dada que és única de l’espiròmetre.

Original:               27 KB

EXI:                        8 KB

Ratio:                    1/3

Compressió del document CDA d’espirometria

Alt rendiment degut a la gran quantitat de tags a repetir tant d’estructura de CDA (entries, components, code…) com d’estructura del text html per mostrar l’informe (td, tr, table…).

Original:               680 KB

EXI:                        35 KB

Ratio:                    1/20

Conclusió

Aquest nou mètode és molt important, primer de tot perquè ha sigut aprovat com un estàndard per la W3C, i per tant no és cap format propietari.

El punt fort del mètode és que està concretament orientat a codificar XML, res més, a diferència d’altres sistemes de compressió genèrics.

La compressió es pot veure aplicada en documents CDA i això pot ser molt interessant per integrar documents en format EXI, per ocupar menys espai, i per transmetre en un temps més ràpid.

A més cal dir que aquest estàndard s’ha desenvolupat pensant en dispositius mòbils, per facilitar una transmissió més ràpida i amb menys pes, per tant tenir aquest format crearia un impacte important en aquests dispositius, i en el desenvolupament de noves aplicacions per aquests.

Fragment extret del document “EXI (Efficient XML Interchange) – M. Lizana”

Llegir en català

En esta entrada mostraremos una tecnología para transmitir los ficheros XML de una manera más rápida, especialmente diseñada para las tecnologías de hoy en día, como los smartphones. Una vez introducida, haremos una prueba trabajando en estándares (en concreto con el estándar CDA R2) i veremos el impacto que crea esta tecnología sobre ficheros CDA XML.

EXI (Efficient XML Interchange) es un formato de datos propuesto por el Efficient XML Interchange Working Group, y se considera estándar W3C. El objetivo de éste formato es codificar documentos XML en un formato binario, para reducir el espacio de los mensajes y permitir una transmisión entre dispositivos mucho más ágil.

Formato

Un documento EXI está formado por un EXI Header y un EXI Body.

EXI Header

Contiene las propiedades de codificación necesarias para poder codificar y descodificar el EXI-stream. El tamaño mínimo de cabecera es de 1 byte, por tanto podemos considerar que tiene un overhead muy bajo.

EXI Body

El cuerpo de un documento EXI esta compuesto por eventos EXI. Los ítems XML se codifican en uno o más EXI events. Los eventos se agrupan siguiendo una definición de gramática, para ver los elementos que se repiten más o menos, para codificar la información en función de estos elementos, y poder comprimir mucho más la cadena, parecido al método de compresión de los códigos Huffman. La idea es comprimir al máximo el espacio que ocupan los “tags” del XML, que suelen repetirse mucho.

Primero mostramos un ejemplo de XML cualquiera:

<?xml version="1.0" encoding="UTF-8"?>
<notebook date="2007-09-12">
<note category="EXI" date="2007-07-23">
<subject>EXI</subject>
<body>Do not forget it!</body>
</note>
<note date="2007-09-12">
<subject>Shopping List</subject>
<body>milk, honey</body>
</note>
</notebook>

Éste XML se representa en EXI events de la siguiente forma:

Una vez tenemos los EXI events, se ordenan para poder hacer la compresión de los tags:

Rendimiento

Para ver una prueba del rendimiento de éste método, haremos un par de pruebas con ficheros XML, con propiedades diferentes.

Compresión del fichero de espirometría propietario

Bajo rendimiento debido a las pocas repeticiones de los tags, ya que cada tag es diferente, para transmitir cada dato que es único del espirómetro.

Original:               27 KB

EXI:                        8 KB

Ratio:                    1/3

Compressión del documento CDA de espirometría

Alto rendimento debido a la gran cantidad de tags a repetir tanto de estructura de CDA (entries, components, code…) como de estructura del texto html para mostrar el informe (td, tr, table…).

Original:               680 KB

EXI:                        35 KB

Ratio:                    1/20

Conclusión

Éste nuevo método es muy importante, primero de todo porque ha sido aprobado como un estándar por la W3C, y por lo tanto no es formato propietario.

El punto fuerte del método es que esta concretamente orientado a codificar XML, nada más, a diferencia de otros sistemas de compresión genéricos.

La compresión se puede ver aplicada en documentos CDA i esto puede ser muy interesante para integrar documentos en formato EXI, ocupando menos espacio y transmitiendo en un tiempo más rápido.

Además éste estándar se ha desarrollado pensando en dispositivos móviles, para facilitar la transmisión más rápida y con menos peso. Con éste formato se crearía un impacto importante en estos dispositivos, y en el desarrollo de nuevas aplicaciones para estos.

Fragmento extraído del documento “EXI (Efficient XML Interchange) – M. Lizana”

Interoperabilitat de la prova d’espirometria forçada

En aquesta entrada explicarem un dels treballs que hem realitzat al CCI en quan a l’àmbit d’integració i interoperabilitat amb estàndards, la integració de la prova d’espirometria forçada.

Per tal d’implantar l’estàndard CDA R2 homologat per la Oficina d’Estàndards i Interoperabilitat de la Fundació TicSalut del Departament de Salut de la Generalitat de Catalunya, des del Pla Director de Malalties de l’Aparell Respiratori (PDMAR) encapçalat pel Dr. Joan Escarrabill, s’ha decidit realitzar projectes pilot per a donar una empenta a la integració i interoperabilitat de la prova d’espirometria forçada, tot utilitzant l’estàndard HL7-CDA R2.

A través de la nostra expertesa en estàndards i en integració de sistemes i dispositius mèdics, hem proporcionat suport tècnic a nivell de consultoria al Institut Català de la Salut, per facilitar la implantació de l’estàndard en aquells centres participants en els projectes pilot.

Des del CCI (a traves del treball realitzat), s’han gestionat i normalitzat els resultats d’una prova d’espirometria forçada, i s’ha desenvolupat una integració d’aquesta prova, creant una producció sota la plataforma d’integració, Ensemble d’Intersystems.La producció reuneix tots els fluxos necessaris per poder dur a terme l’integració de la prova, des de la gestió de la demanda (enviada pel centre peticionari), la gestió dels resultats de l’espiròmetre, i la generació final d’un informe detallat amb: l’informació personal del pacient, els resultats clínics de la prova i una interpretació gràfica dels mateixos.

El procés intern que es duu a terme en la producció desenvolupada es divideix en les següents etapes:

Etapa 1 – Gestió demanda:

La demanda d’espirometria, es duu a terme ha partir d’una petició d’un metge desde el servei de pneumologia d’un centre hospitalari, cap a la llista de treball (cua de pacients que s’han de dur a terme proves clíniques en el centre), del sistema d’informació centralitzat del centre. Rebuda la demanda d’espirometria en la llista de treball, és processada pel sistema d’informació centralitzat del centre i emmagatzemada en una base de dades, a l’espera dels resultats de la prova d’aquest pacient.

La producció desenvolupada és adaptable, a rebre la missatgeria de la demanda(prominent del sistema d’Informació centralitzat del centre), en format “propietari” però es aconsellable per manegar aquesta informació utilitzar l’estàndard de missatgeria medica HL7.

Etapa 2 – Gestió prova:

Un cop emmagatzemada la demanda a la base de dades de la producció, el pacient arriba al centre transcorregut un cert temps i es realitza la prova. El dispositiu mèdic en qüestió (espiròmetre), genera una sèrie de dades clíniques relacionades amb la respiració del pacient (FVC, FEF, etc. ), aquestes dades quedaran emmagatzemades físicament en un fitxer.

Aquest fitxer com el missatge de demanda, sol ser format propietari, tot i que desde diferents organismes i proveïdors de dispositius mèdics, s’està treballant per aconseguir que aquestes ambos informacions es rebin i es generin al dispositiu mèdic en format estàndard HL7.

El següent pas d’aquesta etapa del procés, es llegir els resultats clínics generats durant la prova d’espirometria i intentar lligar la mateixa amb la demanda corresponent. El procés de “lligar” es fa a través del codi identificador de la prova, així com el nom i l’edat del pacient (com a dades addicionals per reafirmar aquest identificador). Si es troba una demanda relacionada amb la prova, la producció generarà l’informe corresponent a la prova realitzada, incloent un documento clínic CDA R2 (representant l’informe d’espirometria com a estàndard de text amb entrades codificades), un XSL (per poder visualitzar el CDA R2 en un navegador) i les gràfiques corresponents a les dades clíniques de la prova, com a informació de suport per el metge.

En cas contrari el sistema emmagatzemarà la prova d’espirometria. Aquests resultats quedaran emmagatzemats sense processar, degut a que l’etapa de lligar la demanda no ha finalitzat amb èxit. Les proves no “lligades”, són comprovades cada un determinat període de temps en el cas de que la demanda no hagués arribat correctament.Si en una comprovació s’aconsegueix lligar la prova, es processa normalment seguint el procés anteriorment explicat.

Per evitar que una prova quedi en el sistema de manera permanent, quan ja s’han dut a terme diversos intents, i no s’ha aconseguit lligar amb la demanda, aquest fitxer és emmagatzemat de forma separada dels altres, per a que sigui comprovat manualment per la persona responsable que a realitzat la prova al pacient.

Quan el procés finalitza satisfactòriament es generarà, com ja s’ha esmentat anteriorment,tres fitxers:

CDA R2: Arquitectura estàndard per a documents clínics basada en el model UML R-MIM. Aquest document contindrà la informació del pacient i les dades clíniques de la prova d’espirometria, de manera estructurada (XML) i codificada a traves de la terminologia clínica SNOMED-CT.

XSL: Permet visualitzar el CDA R2 en un navegador com si es tractés d’una plana web qualsevol.

Gràfics: Conjunt de dos gràfics (Flux-Volum i Volum-Temps), que representen els resultats clínics de la prova. Aquests gràfics apareixen incrustats al final del CDA R2.

A continuació podreu visualitzar la producció d’espirometria que hem desenvolupat, sota l’entorn d’integració Ensemble d’Intersystems.

YouTube Preview Image