A Medida
Desarrollo de un sistema de transformación de contenidos, amedida de los usuarios.
A Medida es un proyecto que cuenta con el apoyo del Ministerio de Industria, Turismo y Comercio (Porgrama Profit) y de la Unión Europea
Descripció >> Funcionalitat
Procés de transformació
La definició del procés es realitzarà mitjançant el dissenyador de processos, una eina gràfica que generarà una descripció del procés en format XML , encara que es podrien utilitzar alguns dels estàndards existents XPDL, BPML, .... En l'execució del disseny del servidor de transformació, i concretament en la fase d'elecció dels estàndards que s'utilitzaran, es decidirà quin d'ells s'ajusta més als requeriments del projecte.
Definició del procés
Un procés és un conjunt seqüencial d'operacions de transformació sobre documents.
La definició del procés tindrà forma de graf dirigit, on els nodes representarien les operacions i cada vèrtex estaria associat a cada una de les possibles respostes de les operacions (token de resposta).
Un procés es pot veure de forma global com un objecte amb estat (iniciat, finalitzat amb error, en execució, etc.), per la qual cosa es definirà una API d'accés que permeti la seva monitorització.
Operació de transformació
És on s'implementarà tota la lògica de les transformacions. Cada operació rep una informació d'entrada. Aquesta informació pot ser de dos tipus:
- Informació de context: es refereix a l'operació en ella mateixa, dins del context del procés (Exemples: que operacions s'hagin executat, quins són els valors dels paràmetres en el moment del disseny del procés, etc.).
- Informació d'execució: té relació amb el procés de transformació i té sentit en el temps d'execució (Exemples: si l'operació és una transformació XSL, la informació és el XML sobre el qual s'aplicarà la transformació).
Cada operació realitza una sèrie d'accions (Exemples: una transformació XSL, emmagatzemar dades en el sistema de fitxers, etc.) i genera una informació de sortida (dades que serveixen d'entrada a la següent operació i un token de resposta que permet determinar la següent operació que s'executarà mitjançant la definició del procés).
Algunes de les característiques que es podran definir a nivell d'operació des del dissenyador són:
- Paràmetres de les operacions: els seus valors només es podran determinar en temps d'execució en alguns casos.
-
Tipus d'operacions: Hi pot haver diferents tipus d'operacions, com per exemple:
- Listeners. Interactuen amb les parts externes del sistema, obtenint dades que permetin iniciar els processos. Són exemples de listeners els HttpListener, SmtpListener, etc., i per la seva naturalesa estan associats a un protocol determinat - http, smtp, etc.
- Operacions Automàtiques. Les més habituals són les operacions que reben una sèrie de dades, executen l'activitat associada i retornen unes dades de sortida. Per exemple, l'operació d'execució d'una transformació XSLT.
- Manuals. Per a completar la seva execució es necessita de la intervenció d'un component expert i aquesta en la seva execució, com en qualsevol altra operació, rep una sèrie de dades, executa una activitat determinada i es posa en contacte amb una entitat aliena al procés, enviant-li tota la informació que consideri necessària, incloent-hi com l'entitat s'ha de posar en contacte amb l'operació per reiniciar el procés. Si fos necessari, inicia un listener concret per a rebre la resposta. Un exemple seria enviar un text a traduir a una entitat externa utilitzant el correu electrònic i esperar resposta mitjançant un WebService. L'entitat receptora de les dades de l'operació executa l'activitat associada, generant una sèrie de dades i a continuació envia aquestes dades de nou al procés utilitzant el mecanisme que l'operació li hagi indicat. Així, seguint amb l'exemple, un traductor rep el correu electrònic amb el text a traduir, el tradueix i envia el text traduït a una URL concreta segons se li indicava en el correu electrònic previ. Aquestes dades arriben a l'operació mitjançant el listener que aquest havia iniciat i, una vegada obtingut, executa una activitat associada i continua l'execució del procés com si d'una operació automàtica es tractés.
Processament d'imatges com a part d'un contingut
Moltes de les transformacions en els continguts que es manejaran involucraran informació de tipus gràfic, més concretament imatges i vídeo.
La qualitat de les imatges depèn de l'ús que se'ls hi vulgui donar, i per tant, del format en que s'hagin de presentar als usuaris. Un mateix document que contingui imatges ha de poder ser presentat als usuaris d'un curs en línia en format HTML però al mateix temps ha de poder ser presentat als mateixos usuaris, per exemple en format PDF, per a la seva posterior impressió. En el cas que el document s'hagi d'imprimir, la qualitat de les imatges ha de ser molt major que si el document està creat per a ser distribuït en format de pàgina web. Per a aconseguir aquest objectiu s'han de realitzar un conjunt d'operacions sobre les imatges que inclouen l'escalat, la compressió, el format de sortida, els colors de sortida, adaptació a l'ampla de banda. Així doncs cada imatge s'adapta en temps real al format de sortida requerit.
En el cas del vídeo, si es vol presentar un curs que inicialment està en format vídeo digital en format text i imatges pot ser interessant que es captin determinats fotogrames de les diferents seqüències que composen el vídeo i que es capturin com a imatges, després, aquestes imatges es poden incorporar a un document en el format de text adequat.
Per a suportar aquest tipus de funcionalitats s'ha incorporat un mòdul d'adaptació d'imatges la funcionalitat principal del qual és la d'emmagatzemar les imatges en un format d'alta qualitat i servir-les amb una qualitat adaptada al format de presentació. Aquest mòdul va ser desenvolupat per la Fundació IBIT dins del projecte Servidor d'Imatges, finançat en part pel programa PROFIT. Per a reutilitzar dit programari s'hauria d'adaptar a la nova arquitectura, a més d'incorporar noves operacions sobre les imatges.
Sol·licitud de dades a l'usuari
En cas d'existir una connexió HTTP amb l'usuari (Exemple: el procés s'ha iniciat des d'un HttpListener), aquesta operació permetrà definir un formulari que s'enviarà a l'usuari i s'esperarà a que aquest el completi. Per a la definició de formularis es pot utilitzar Xforms , proposat per W3C pera a la definició de formularis.
Arquitectura orientada a Serveis (SOA)
Els processos de transformació poden veure's com a serveis. A més, i a causa del plantejament obert del sistema, es fa necessari la definició d'altres serveis (Exemple: la monitorització, el control d'accessos, etc.). que permeten la seva gestió. Així doncs, la millor manera d'orquestrar el conjunt de serveis plantejats és mitjançant la definició d'una arquitectura orientada a serveis. Una arquitectura orientada a serveis és, essencialment, una col·lecció de serveis que es comuniquen entre ells. Aquesta comunicació pot implicar des d'un simple canvi d'informació fins a complexos protocols de coordinació.
Per servei s'entén una funcionalitat ben descrita i autocontinguda, que no depèn de l'estat d'altres serveis. Per a això és necessari fixar:
- Un protocol de dades (XML).
- Un protocol de comunicació (JMS, JMS, és l'estàndard Java per a l'accés a sistemes de missatgeria tradicionals (MQSeries, TIBCO, OracleAQ, JBossMQ.), HTTPS, ....)
- Un mecanisme de relació entre el format de dades i el protocol de comunicació (binding).
De fet, l'estructura d'un sistema en serveis duu les mateixes avantatges que la programació orientada a objectes: modularitat, abstracció, etc., i a més aquesta permet que siguin repicables i distribuïbles.
Per a implementar i gestionar aquests elements de forma dinàmica permetent, per exemple, que en un moment de màxima activitat es puguin afegir noves instàncies, es fa necessària una peça més: un Catàleg de Serveis.
Catàleg de serveis
Un component que ofereix un determinat servei registra un proxy en un catàleg, de forma que encapsuli els detalls d'accés. Els clients que volen accedir a un servei realitzaran una cerca sobre el catàleg, executant el proxy que serà l'encarregat de comunicar-se amb el servei concret utilitzat, per exemple, missatgeria com a mètode de transport. Una avantatge addicional del catàleg proposat és que, tant en el registre com en la cerca de serveis, es defineixen una sèrie d'etiquetes que identifiquen de forma abstracta la seva funcionalitat. Això permet que d'una manera totalment transparent es puguin canviar unes parts per altres d'equivalents, dotant així d'una gran flexibilitat al sistema. S'optarà per una solució de catàleg redundant, distribuït en varis nodes, i dinàmic, de forma que es pugui saber en temps real quins serveis estan en funcionament. Això permetrà que en cas de no trobar cap servei actiu en el moment de rebre una petició pugui respondre immediatament que el servei no està disponible, sense haver d'esperar un timeout.
En aquest catàleg podrem trobar serveis de diferents tipus com per exemple:
- Operacions: executa les operacions de transformació i per a això rep tota la informació de context necessària.
- Avisos: rep avisos que altres serveis envien als destinataris - usuaris o altres components.
- Monitorització de processos: rep informació d'operacions que han estat executades pel servei d'operacions, emmagatzemant-la en una base de dades.
- Administració: rep comandaments que permet modificar la configuració del sistema i enviar missatges a altres serveis.
- Control d'accessos: l'execució de les operacions, així com l'accés als diferents serveis, pot restringir-se mitjançant un control d'accessos utilitzant protocols de comunicació XACML , un estàndard proposat pel W3C per a la gestió de permisos, i SAML , un estàndard proposat per OASIS per a l'intercanvi d'informació referent a usuaris i permisos.
