Vistas

D 1.2 Arquitectura de Referencia, Especificación del Modelo Conceptual y Líneas Futuras

De MorfeoWiki

PROFIT

Morfeo-EzWeb

Área Temática: 350405 Strategic Action on Open Source Software
FIT-340503-2007-02 EzWeb



Morfeo project EzWeb

Entregable:

D 1.2 Arquitectura de Referencia, Especificación del Modelo Conceptual y Líneas Futuras






Versión: 1.0
Fecha de preparación: 19/11/07
Editores: Marcos Reyes (TID), CTIC
Revisores: Juan Pablo López, Juan Pablo Martín, y Javier de la Rosa (Yaco), CodeSyntax, ITI

Tabla de contenidos

D 1.2.1 Arquitectura de Referencia y Especificación del Modelo Conceptual

Descripción general del desarrollo

La adopción de Modelos Orientados a Servicios constituye un cambio de paradigma fundamental, que permitirá aumentar el dinamismo y competitividad de la sociedad actual transformándola en una "sociedad basada en el conocimiento". Este cambio de paradigma supone que:

  • Los modelos de negocio evolucionen desde la venta de productos (paquetes y aplicaciones) hacia la provisión de servicios electrónicos proporcionados desde la red en modo utilities (siempre disponibles, en cualquier lugar).
  • Los procesos, tanto procesos de negocio realizados por empresas como procesos llevados a cabo por individuos o colectivos en su vida diaria, se definan a partir de servicios de una manera más ágil y flexible, totalmente adaptada al contexto.

Este cambio de paradigma conducirá a una mejora significativa en la vida diaria de negocios, ciudadanos y colectivos. En efecto, dicho cambio permitirá a las empresas (y no sólo grandes compañías, sino también PyMEs) alcanzar los niveles más altos de innovación y excelencia en operaciones, así como un mejor "time to market". También permitirá a individuos y colectivos alcanzar los niveles más altos de productividad, satisfacción y bienestar. Además, se crearán nuevas oportunidades para pequeñas empresas (PyMEs) o incluso individuos que no tendrán que limitarse a ser simples consumidores, sino que podrán jugar el papel de proveedores de servicios, contenidos y en definitiva cualquier otro tipo de recurso, que harán disponible a través de la red, que se considere de utilidad.

En este cambio de paradigma, la manera en que los servicios serán descubiertos, usados y gestionados por los usuarios finales será clave y deberá contemplar los siguientes principios:

  • Los usuarios finales deben contar con la máxima autonomía y capacidad de personalización en relación con la configuración de su entorno operativo, como resultado de localizar, elegir, personalizar y combinar de manera flexible y dinámica (siguiendo un modelo de autoservicio o filosofía tipo IKEA) recursos disponibles en la red.
  • Los usuarios finales deben contar con la capacidad de crear y compartir conocimiento, que se materialice en la capacidad de construir nuevos recursos y publicarlos en la red, así como intercambiar experiencias con otros, aprendiendo juntos y acelerando de este modo tanto la incorporación constante de innovaciones como la mejora de la productividad.
  • La interacción debe adaptarse y ser relevante al contexto, dando al término "contexto" el significado más amplio posible, de manera que comprenda elementos tales como el contexto del usuario (conocimiento, perfil, preferencias, idiomas, información sobre las redes sociales a las que el usuario pertenece, etc.) o el contexto de utilización (características estáticas y dinámicas del dispositivo usado para el acceso, localización geográfica y de tiempo, la conexión de banda ancha, etc.); y teniendo en cuenta tanto la variabilidad del contexto como la movilidad de los usuarios.

En el ámbito de Internet, además de estos principios, es necesaria la creación de un ecosistema de negocio sostenible para todos los implicados en la cadena de valor de los servicios. Esto requiere definir tecnologías que den soporte al concepto de marketplace, donde diversos modelos de negocio fiables, innovadores y flexibles puedan ponerse en práctica, involucrando a los clientes/usuarios finales, a los proveedores que publican recursos (contenidos o servicios de aplicaciones), a los distribuidores (brokers) que finalmente hacen que estos recursos sean accesibles, a los posibles anunciantes que desean acceder a los clientes/usuarios finales y en definitiva a todos los participantes involucrados en la cadena de valor.

El proyecto EzWeb se centra en el desarrollo de tecnologías clave a emplear en el desarrollo de la capa de acceso web (front-end layer) a los servicios sobre Arquitecturas Orientadas a Servicios (SOA - Service Oriented Architecture) de nueva generación. Esta plataforma soportará la interacción entre usuarios finales y los contenidos/servicios apoyándose en los principios anteriormente mencionados.

En la definición de la arquitectura básica asociada a EzWeb, se han considerado dos principios de diseño básicos. Por un lado, los usuarios finales sólo pueden tratar con objetos que ellos puedan "ver y tocar" en el nivel de interfaz de usuario, por ejemplo, los elementos que puedan pulsarse con el puntero del ratón. En este sentido, los usuarios no son capaces de “ver” Web Services (WS*) ni “tocarlos” con el puntero del ratón. Las definiciones de interfaz de servicio en WSDL no tienen ningún sentido para ellos. No saben como buscar Web Services, caracterizarlos o gestionarlos. Por otra parte, las mejores soluciones son por lo general las más simples. En efecto, en el campo de las Tecnologías de la Información, la simplicidad y la flexibilidad siempre ha sido el motor principal de la evolución tecnológica. Cuanto menor es el obstáculo para el acceso a una tecnología, mayor es la comunidad de programadores y los usuarios que trabajan en ella. Esta mejora en el acceso a una tecnología potencia la aparición de nuevos modos de uso e ideas innovadoras surgidas de ella.

Basado en estos dos principios de diseño, el concepto de recursos web constituye el concepto básico alrededor del cual EzWeb dará soporte a la definición de la capa front-end en la nueva generación SOA. En realidad, los recursos son simples componentes que se programan siguiendo el paradigma arquitectónico REST (Representational State Transfer): tendrán una URI (Uniform Resource Identifier) y responderán a peticiones HTTP básicas (GET / POST / PUT / DELETE) atendiendo a su semántica predefinida (acceder / crear / modificar / borrar) y generando respuestas interpretables desde un navegador estándar. Los recursos encapsulan el acceso a contenidos y servicios, recopilando datos (el contenido o la salida de servicios), procesándolos, y distribuyéndolos a otros recursos o visualizándolos para el usuario final. Algunos de ellos, denominados gadgets, tratarán con funciones de presentación e interacción humana, es decir, producirán la salida de forma que directamente pueda ser integrada en el nivel de interfaz de usuario (por ejemplo, producirán contenidos web que puedan ser procesados y suministrados por navegadores). Los gadgets constituyen los ladrillos de la fachada en una Arquitectura Orientada a Servicios que los usuarios finales pueden “ver y tocar”. Otros recursos únicamente producirán datos (contenidos) que puedan ser procesados por otros recursos (operadores). Adoptar el paradigma REST implicará por un lado simplificar y hacer accesible la invocación y el tratamiento de las respuestas de los servicios, y por otro encapsular la complejidad y el uso de los servicios gracias a la utilización de una interfaz uniforme. Estos dos aspectos fundamentales reducen significativamente los esfuerzos de programación necesarios para la utilización, composición y enriquecimiento de los servicios por parte de los usuarios.

Debido a que algunos recursos (gadgets) tendrán asociada una URI, que garantizará su capacidad de acceso universal y ofrecerán una fachada (son visibles) al nivel de la interfaz de usuario, los usuarios finales podrán combinarlos y configurarlos para crear sus propias interfaces y procesos personalizados. Además, los usuarios finales podrán etiquetarlos, buscarlos, enriquecerlos, etc. La composición y creación de nuevos recursos a partir de otros pre-existentes y la explotación de las sinergias y flujos de información que puedan establecerse entre ellos (desde el diseño hasta la interfaz de usuario final) debería ser muy simple para los usuarios finales, aplicando conceptos tales como el mash-up. El término mash up se está usando actualmente para definir la integración de contenidos en la capa de interfaz de usuario, pero su aplicación en servicios representa un área muy relevante de investigación. De hecho desde el punto de vista de los servicios, el concepto de mash-up tiene que abarcar e integrar conceptos como el piping (de forma similar a como los shellscripts de UNIX pueden ser combinados en un interprete de comandos) y wiring (establecimiento dinámico de flujos y dependencias de datos entre recursos).

La búsqueda de recursos tiene realmente sentido para los usuarios finales en el momento en el que los resultados de la búsqueda son visibles y manejables. Hay que tener en cuenta que el descubrimiento y la composición de recursos ocurren a un nivel diferente que el descubrimiento y la composición de servicios en el back-end. La naturaleza del descubrimiento y la composición a ambos niveles es diferente y las tecnologías involucradas pueden ser diferentes.

El Software Social está llamado a jugar un papel clave en la interacción Usuario/Servicio y la definición del concepto de capa de adaptación basada en recursos. El Software Social es una de las claves que han llevado a la revolución actual de la Web 2.0. Permite a la gente comunicarse, interconectarse o colaborar entre sí. Uno de los principales rasgos del software social es su modelo de desarrollo bottom-up y la manera que esto capacita a los usuarios finales para colaborar en la creación de contenidos dentro de comunidades. Uno de los conceptos clave a considerar en el Software Social son las folksonomías, que han demostrado ser una herramienta potente para asociar metadatos a recursos y organizar el conocimiento de forma distribuida. Se pueden definir como un sistema de etiquetado social que permite a los usuarios aportar y compartir su conocimiento mediante la categorización de diferentes recursos tales como páginas web, pero se desarrollan como islas en diferentes comunidades de usuarios y en sitios web específicos. Actualmente se están usando en diferentes tipos de aplicaciones tales como:

  • Librerías sociales: donde los visitantes pueden etiquetar y clasificar sus libros, discos y DVD’s, y recibir recomendaciones.
  • Bookmark social, donde los usuarios publican y etiquetan sus bookmarks o imágenes en base a folksonomías para que otros puedan buscarlos y verlos.
  • Guías sociales, donde los usuarios recomiendan lugares a visitar en el mundo, tales como “coffee shops”, restaurantes o puntos de acceso WiFi.

La potencia de las folksonomías reside en su facilidad de uso, lo que permite la generación de una gran cantidad de metadatos por parte de usuarios sin conocimientos técnicos. Los usuarios alimentan el sistema con contenidos etiquetados semánticamente, evitando la costosa tarea de que un experto realice anotaciones manuales o la dificultad de desarrollar tecnologías que implementen anotaciones automáticas de contenido. Los metadatos extraídos gracias a las folksonomías pueden ser explotados para mejorar los motores de búsqueda y también para mejorar la navegación. Sin embargo, es preciso desarrollar nuevas áreas de investigación con el objetivo de averiguar como las folksonomías pueden estructurarse y asociarse con servicios (actualmente, están unidas en su mayoría a contenidos), también es necesario explorar técnicas que nos permitan mejorar su calidad y utilidad, así como su integración con tecnologías más formales, como son las ontologías.

Un aspecto relevante es que la salida generada tanto por los recursos como por las funciones de descubrimiento y composición debe ser sensible al contexto. Adicionalmente, la plataforma tiene que ser concebida como una plataforma abierta que permita a los usuarios finales descubrir, etiquetar y componer recursos, siguiendo una filosofía de autogestión y autoservicio. En el ámbito de Internet, esta plataforma serviría como marketplace abierto en el que los usuarios busquen y paguen por recursos (contenidos y servicios). Un mercado abierto en el que las PyMEs y las grandes empresas pueden publicar sus servicios, haciéndolos visibles a los usuarios finales. Teniendo en cuenta, en todo momento, aspectos tales como la seguridad, la fiabilidad y la confianza.

Arquitecturas Orientadas a Servicios (SOA)

Muchas definiciones de SOA han sido publicadas desde finales de los 90, entre ellas está la definición proporcionada por el modelo de referencia OASIS donde se definen las arquitecturas orientadas a servicios como "... un paradigma para la organización y utilización de funcionalidades distribuidas que pueden estar bajo el control y propiedad de diferentes dominios. Proporcionando una forma uniforme de descubrir, interactuar y utilizar dichas funcionalidades obteniendo unos efectos consistentes y verificables a partir de las precondiciones y expectativas”. De acuerdo con este modelo, los componentes principales y sus interacciones dentro de un entorno SOA básico estarían definidos en el siguiente escenario: el proveedor de servicios publica las interfaces de sus servicios a través de un registro donde un consumidor de servicios podrá localizarlos ligándose de este modo al proveedor de servicios.

La existencia de servicios, interfaces y un conjunto de funcionalidades bien definidas que permiten el desarrollo de contratos de servicio, teniendo en cuenta restricciones y políticas de uso, entre consumidores y proveedores permite disponer de entornos y sistemas de bajo acoplamiento (que minimicen dependencias mutuas) que se ajustan a algunos de los más importantes principios de construcción de sistemas e ingeniería del software: encapsulamiento de la información y modularidad.

Esto permite que los Servicios puedan construirse sobre otros servicios más simples, permitiendo de este modo su reutilización. Los servicios son autónomos no provocando impacto ni modificaciones en otros sistemas o servicios (dado que únicamente controlan la lógica que encapsulan de forma bien definida). Hoy en día la evolución de los sistemas y de Internet establecen que estos servicios deberían poder implementarse, gestionarse y utilizarse, por desarrolladores, proveedores y usuarios de forma mas sencilla y accesible que el software empaquetado tradicional.

Las arquitecturas SOA prometen hacer realidad la integración, comunicación y utilización de los sistemas mas allá de los límites de las empresas (B2B) y que acercar el mundo de los servicios a los clientes en general (B2C) y a todo el espectro de usuarios finales. Para lograr esto los servicios deben ser accesibles para todos los usuarios.

Implementaciones Actuales (WS*)

Dentro de este marco los WebServices han acaparado un gran interés durante los últimos años. Se esperaba que los WebServices permitieran una implantación real de las arquitecturas orientadas a servicios a lo largo de la Internet, sin embargo, a día de hoy, las implementaciones de SOA basadas en WebServices ni han logrado todavía traspasar los límites impuestos por las compañías, ni han permitido la adopción de esquemas de provisión y consumo de servicios en Internet (proceso que continúa en una etapa poco madura).

Los motivos de estos problemas los podemos encontrar detrás de la gran complejidad técnica de las arquitecturas basadas en WebServices y a la dificultad de implementación, mantenimiento, flexibilidad de las soluciones que plantean. Estos motivos pueden agruparse en tres áreas:

  • Los WebServices se han centrado únicamente en fomentar la comunicación entre sistemas. Los sistemas actuales basados en arquitecturas orientadas a servicios son demasiado abstractos e invisibles a los usuarios por lo que su implantación y uso se limita a los procesos automáticos de grandes y medianas empresas. Los WebServices no han permitido que usuarios finales, con pocos o nulos conocimientos técnicos, puedan obtener y utilizar estos servicios, restringiéndose su uso a usuarios de amplios conocimientos técnicos dentro de los límites de las compañías.
  • Los WebServices basan su arquitectura e implementación en una serie de complejos estándares muy poco amigables y en constante evolución. El empleo de estos estándares y tecnologías hacen que la utilización de los WebServices en entornos no automatizados o de muy amplia experiencia sea una tarea casi imposible. Estándares como WSDL, UDDI, SOAP y los que se organizan sobre sus bases como puedan ser BPEL, y la creciente familia de estándares "WS*" (WS-Trust, WS-Security, WS-MessageDelivery, ...) hacen que los servicios no sean inteligibles ni utilizables por los usuarios finales impidiendo que estos usuarios puedan pasar a formar parte de la cadena de valor de los servicios.
  • Por último los WebServices están sujetos a una gran cantidad de marcos de regulación (dado que se emplean principalmente en el entorno corporativo). El diseño, la provisión, el mantenimiento y la interrelación o acoplamiento de servicios debe verificar estos marcos de regulación. La existencia de esta estrictas normas impiden la flexibilidad que los nuevos esquemas de uso basados en la accesibilidad de los servicios a los usuarios, parecen necesitar.

La Web 2.0 y su relación con SOA

En esta sección se hablará sobre un conjunto de sinergias identificadas entre la Web2.0 y los principales conceptos de las arquitecturas SOA con el fin de desarrollar un arquitectura orientada a servicios de ámbito global y centrada en el usuario. También se describirán los paradigmas tecnológicos y los novedosos principios de diseño que han sido identificados como catalizadores para la creación de una Web de Servicios.

A primera vista, el movimiento Web2.0 y las arquitecturas SOA se encargan de solucionar distintos problemas de los usuarios, empleando un conjunto distinto de diseños y tecnologías. El concepto Web2.0 se asocia a la percepción de una nueva generación de comunidades y servicios en la Internet: wikis, blogs, redes sociales, folksonomias,... . El nexo común entre todos ellos se encuentra en que se encargan de adquirir, explotar, compartir y maximizar la inteligencia colectiva y el conocimiento de sus usuarios.

Recientemente numerosos casos de uso han demostrado el gran potencial de la combinación de las tecnologías y principios de la Web2.0 con las arquitecturas SOA. El ejemplo principal de las posibilidades de esta convergencia es la aparición de una nueva alternativa a las implementaciones SOA, una alternativa que puede hacer realidad la idea de la "Web of Services" descrita anteriormente. La idea principal detrás de esta nueva aproximación surge de considerar la existencia de un amplio ecosistema de Recursos accesibles a través de Internet. Estos recursos deben poder ser registrados, descubiertos, etiquetados (ratings, folksonomies) y mezclados (mashup) con el objetivo de crear nuevos recursos según los requisitos de los usuarios.

Concretando esta aproximación, las soluciones SOA centradas en el usuario deben proporcionar una infraestructura o plataforma que permita a los diferentes negocios, proveedores, clientes, socios y usuarios compartir información y fomentando la cooperación de forma inmediata. Para llegar a este fin es necesario disponer un entorno de composición de servicios (mashup) que por medio de herramientas accesibles al mayor número de usuarios posible les permita colaborar para la resolución de problemas complejos de forma inmediata.

Los puntos mas importantes a tener en cuenta que se han identificado al estudiar las aproximaciones de SOA centrado en el usuario son:

  • Los usuarios deben sentirse plenamente potenciados y capaces de solventar sus necesidades a partir de un ecosistema de recursos disponibles. Estos recursos les darán acceso a contenidos y servicios que podrán emplear para personalizar su propio entorno operativo.
  • Debe permitirse la participación de los usuarios. Los usuarios finales deben ser capaces de contribuir con nuevas y mejoradas versiones de recursos, así como compartir nuevo conocimiento sobre ellos, su uso y sus interrelaciones.
  • Las colaboración dentro de comunidades debe ser promovida. Utilizando prácticas que promuevan la compartición, reutilización, composición dentro de un entorno de colaboración que permita explotar las redes de trabajo como medio de amplificación de resultados.

Además de estos principios habría que añadir la creación de un ecosistema de negocios, sostenible para todos los actores principales dentro de la cadena de valor de las arquitecturas SOA (incluyendo esta vez a los trabajadores de las empresas). Esto supone la definición de las tecnologías que den soporte al concepto de un marketplace donde la confianza y nuevos modelos innovadores y flexibles de negocio puedan ser desarrollados teniendo en cuenta a los proveedores de servicios que desarrollan los servicios, los distribuidores que los hacen accesibles, y los usuarios finales que los utilizan.

Como primera consecuencia de la aplicación de estos principios, los usuarios se ven directamente involucrados en el desarrollo del software promoviendo la creación de nuevos vectores de innovación basados en el uso y la experiencia. Las aplicaciones así creadas constituirán soluciones a medida totalmente adaptadas a las necesidades concretas de los negocios. Teniendo en cuenta todo lo anterior, a continuación se presenta un modelo genérico para la implantación y desarrollo de arquitecturas SOA centradas en el usuario.

Arquitectura de Referencia y Modelo Conceptual

En esta sección se presentará la arquitectura que planteamos para permitir la implementación de soluciones basadas en arquitecturas SOA de nueva generación planeadas anteriormente. Esta plataforma permitirá el desarrollo de aplicaciones basadas en el concepto de composición más que en el concepto de programación, habilitando y potenciando a los usuarios para la realización cooperativa de mash-ups empresariales que suplan sus necesidades concretas y les permitan una (re)utilización efectiva de los recursos y servicios a su disposición. La arquitectura propuesta se basa en cuatro capas lógicas situadas sobre los sistemas y servicios de back-end a los que deseamos proveer acceso, dentro de estos sistemas se englobarían bien sistemas legacy, bien sistemas SOA basados en implementaciones de WS*.

Sobre esta capa de servicios de backend se situará la capa Recursos, que se encargará dar acceso de manera uniforme y fácilmente explotable por usuarios y sistemas a los contenidos y servicios que proporciona la capa de back-end. Estos rerursos se desarrollarán siguiendo el paradigma de las arquitecturas REST, potenciando de este modo su capacidad de cara a la generalización, reutilización, composición, modificación y uso. Gracias a la clara orientación al usuario de las arquitecturas REST, estos podrán enriquecer el universo de recursos tanto con nuevo recursos como con conocimiento asociado a ellos. La arquitectura de referencia propone tres tipos básicos de recursos según su funcionalidad y capacidad de interacción: Contenidos (recursos que proporcionan información), Operadores(recursos capaces de realizar tareas de forma automática) y Gadgets (recursos capaces de interactuar con humanos).

La siguiente capa de la arquitectura es la encargada de proporcionar a los distintos usuarios (proveedores y consumidores de recursos) un entorno de registro, compartición, búsqueda y descubrimiento de recursos y conocimiento asociado. Se hace necesario proveer herramientas que permitan capacitar a los usuarios tanto para la inclusión de nuevos recursos como para la localización de aquellos recursos y/o combinaciones de recursos que solventen de la forma mas efectiva posible sus necesidades atendiendo al contexto de utilización. Al contrario de un repositorio clásico basado UDDI este tipo de catálogo/registro proporciona su funcionalidad teniendo en cuenta su explotación por parte de usuarios.

Sobre las herramientas de descubrimiento y como principal elemento de realimentación a esta fase se plantea un entorno de desarrollo que permita la creación de nuevos recursos a partir de la composición de otros recursos más simples. Para la realización de estas composiciones se explotaran fundamentalmente técnicas de Piping (al modo del pipe de UNIX) y de definición de screenflows (en el caso de componer gadgets complejos mediante la definición de flujos entre gadgets simples).

Por último se presenta una plataforma de mashup capaz de permitir por un explotar de forma conveniente el ecosistema de gadgets y recursos. Desde el punto de vista de los usuarios finales será a través de esta plataforma como se les capacitará para la construcción de su propio entorno operativo. Desde el punto de vista de los desarrolladores y proveedores de recursos la plataforma proporcionará un marco de trabajo básico al que puedan adscribirse los gadgets y recursos facilitándoles de este modo el acceso a un conjunto de funcionalidades consideradas de interés para su ejecución como puedan ser la integración con otros gadgets y recursos, soporte a la persistencia, seguridad, contabilidad de uso, capacidad de maquetación, acceso al contexto de uso...

Tecnologías clave para SOA de nueva generación

Arquitecturas Orientadas a Recursos

Como un primera aproximación tecnológica de SOA centrado en el usuario, el acceso a servicios será puesto en práctica por los recursos que cumplan con el estilo arquitectural de REST (Representational State Transfer) . Un recurso puede ser considerado como un componente simple que posee una URI (Uniform Resource Identifier). Las URI identifican el contenido o el servicio. Estos representan y responden a los verbos básicos HTTP (p. ej. get, post, put, y delete), así conseguimos establecer una capa al acceso al contenido o servicio vía una interfaz uniforme. La capa del paradigma de REST implica la incorporación de los principios de huida de complejidad y uniformidad, ya que esto considerablemente reduce esfuerzos de programación y fuerza tanto a clientes como recursos de adherirse a un juego común de operaciones apoyadas y descripciones de interfaz. En un REST-based SOA, recursos y clientes cambian representaciones de recurso (formatos de datos prenegociados) en mensajes autodescriptivos, como la parte de sus interacciones por un interfaz uniforme. Como los objetivos de REST distribuyeron sistemas de hipermedios de comunicación, las representaciones también contienen normalmente identificadores para otros recursos. De esta manera se puede usar los identificadores para navegar entre recursos relacionados (dentro de un servicio), así cambiando (la transferencia) del estado. Esta interfaz uniforme es sumamente ventajosa comparada a SOA tradicional. Para que un cliente actúe correctamente con un Servicio Web, él o ella deben entender los datos concretos del protocolo de la interfaz del servicio no sólo para sus operaciones, también para los datos cambiados como la parte de invocaciones de operación. Pero para que un usuario para invocar un servicio de REST, tienen que entender totalmente el contrato de datos específico del servicio, porque las operaciones son uniformes para todos los servicios. Algunos recursos son diseñados para tratar con funciones de presentación, p. ej. en respuesta a una petición Http, ellos producen la salida que usa un formato de datos que directamente puede ser integrado en el nivel de interfaz de usuario (p.ej., ellos pueden producir datos en una lengua de margen que puede ser procesada y dada por navegadores, usando XUL). Los otros son diseñados para solamente(justo) producir los datos que pueden ser procesados por otros recursos, y permitir su nueva mezcla y composición. En última instancia, esto quiere decir que los recursos son un estándar que ofrecen una interfaz uniforme que los usuarios finales pueden "ver y tocar". El concepto de contenido y servicios como recursos agrega mucho a la idea de ser la base de mash-ups tradicionales (usos híbridos de Web o servicios compuestos por contenido y servicios de una gama de dispersa). Así se proporciona el acceso uniforme a todos.

De este punto de vista, mash-ups pueden ser creados por composición e interconectando recursos diferentes con una interfaz uniforme sin necesidad mezclar de nuevo datos, código o servicios de bajo nivel. Por lo tanto, el empleo de esta abstracción de recurso conduce a un verdadero cambio de paradigma conducido por un modelado de datos totalmente funcional. Proponemos la clasificación siguiente de recursos:

  • Fuentes de datos que retroalimentan el uso de mash-up.
  • Operadores que transforman las fuentes de datos.
  • Gadgets, que son responsables de proporcionar la gráfica, y mecanismos de interacción de usuario simples y eficientes.

Plataformas de Mashup

Las plataformas mash-up son consideradas como una aproximación remota tecnológica de SOA centrada en el usuario. "Mash-up es un recurso de Web-based, que ha sido creada para la reutilización y la composición de dos o más recursos diferentes". En estas Plataformas ("plataformas mash-up") cabe destacar de ellas que autorizan a usuarios para acoplar recursos fácilmente disponibles, enriquecerlos y componerlos en un recurso nuevo, que tarde o temprano puede ser hecho públicamente disponible otra vez. Por consiguiente, las redes de recursos diferentes a base de Web surgen por si solas. Estas redes pueden ser consideradas ingobernables, la ciudad sin ley, desde que no hay ninguna entidad de control central que impone directrices formales para la reutilización y la distribución.

La posibilidad de, por un lado, activamente contribuir y ganar una reputación publicando recursos y, por otro, aprovechando el conocimiento conseguido y la inteligencia de todos los participantes de la plataforma es una de las ventajas principales para los usuarios. Este nuevo principio de diseño conducido por el usuario de la aplicación también ha sido comentado en diversas ocasiones en muchos artículos y empresas: programación orientada a mash-up dirigida por el contenido (también se llama programación circunstancial o la programación instantanea) es un nuevo paradigma de desarrollo ágil de aplicación donde los usuarios no tienen habilidades de programación, pero realmente tienen la maestría de montar y combinar visualmente los gadgets disponibles, p. ej. el dominio discreto autónomo componentes orientados por datos tanto con el desarrollo (el servicio como con la encuadernación de datos y la interconexión) y el tiempo de ejecución dando capacidades. Estos gadgets representan los componentes básicos para un usuarios para montar nuevos servicios (p.ej. SOAP o Servicios REST-based lightweight Web Services), data sources (p.ej. Atom/RSS feeds) y otros gadgets y darlos como es necesario para desarrollar el uso que ellos necesitan en un período muy corto de tiempo. A menudo obtenemos otro que es un híbrido, el resultado de la aplicación de este nuevo paradigma de Enterprise Mash-up. Las empresas tratan de capitalizar sobre estas tecnologías para construir el software y servicios para relativamente efímero, y "rápidos de construir", tal cual mostrado en la sección siguiente. El elemento principal de una Enterprise Mash-up es el gadget o el recurso de interacción gráfico humano. Enterprise Mash-up entonces esta compuesto de uno o varios gadget separados que se comportan coherentemente en el mash-up como si ellos eran el que el interfaz fuerte cohesivo. Cada gadget normalmente será conectado a un número de tuberías encadenadas. Habrá que definir el flujo de ejecución. Un gadget podrá tener una entrada y una salida provenientes de otro gadget por medio de una tubería. Desde el punto de vista de software, la ejecución de una secuencia de tuberias del nivel de usuario define la orden de ejecución de los sistemas diferentes de negocio que apoyan el negocio (procesos laborales, BPMs, Servicios Web, etc.). Es decir, los recursos actúan como una entrada a estos sistemas de negocio. ¡Por lo tanto, la disponibilidad de un lenguaje de definición de tuberías, como Yahoo! Las tuberías, son un elemento clave para sistemas desarrollados según esta arquitectura.

Composición de Recursos

Además de la orientación de recurso y la idea de plataformas gráficas mash-up como activadores de integración, dos conceptos, wiring y piping of resources (la tubería de recursos), juntos representan a otro conductor importante para apoyar la creación de usuario, la innovación y la colaboración en un SOA centrado en el usuario. Cuando creamos un mash-up, los usuarios visualmente tienen que componer recursos y resolver sus interdependencias de dos perspectivas diferentes. En una mano, ellos integran un número de recursos heterogéneos que definen data chains/gráficos de tratamiento encadenando recursos sucesivos (fuentes de datos y operadores). Llaman la composición de tubería a este procedimiento (en la referencia al concepto de tubería en la shell de UNIX). De otra parte, ellos tienen que definir flujos de datos y las interdependencias entre gadget para alcanzar una solución interconectada gráfica capaz de solucionar exigencias complejas funcionales como una típica aplicación de escritorio hace. Estos reciben el nombre de wiring. La creación de una tubería implica un número a priori desconocido de recursos, con un número sumamente variable de entradas y salidas. Sin embargo, cualquier recurso responde a HTTP (una interfaz uniforme), al realizar una invocación devolverá la respuesta en formato xml. Por lo tanto, es fácil encadenar recursos de modo que la salida de un recurso directamente alimente la entrada del otro. Gracias a esto, la interacción de sistemas de negocio fácilmente puede ser modelada por la transformación y las fases de validación de cualquier tipo de datos XML (la entrada y la salida), causando recursos de operador (p.ej. XSLtransformations). Los gadgets tienen que comunicarse su estado a otros gadgets dentro un específico mash-up; hasta permiten a la definición de flujos de datos. La definición de estos enlaces de datos debería ser desarrollada basada en las soluciones que aseguren el libre emparejamiento de pizarras de subscripción/publicación o los esquemas de acontecimiento de notificación. Estos caminos, dependencias de datos flexibles pueden ser definidas. La combinación de interfaces visuales mash-up y tecnologías que permiten a la tubería y los componentes de wiring que uniformemente son encapsulados como recursos es un acercamiento que combina la Web 2.0 y conceptos tradicionales SOA. Los componentes pueden ser orquestados en una manera fácil, sin requerir cualquier esfuerzo de programación permitiendo que los usuarios construyan sus propias aplicaciones.


Composición de servicio por wiring

Una nueva tendencia tecnológica de Internet es hacer que los usuarios sean capaces de manejar Servicios Web como elementos visuales o gadgets, es decir el controlador de la interfaz que maneja uno o varios servicios y/o recursos. Estos gadgets, pueden ser simples o complejos, dependiendo del tamaño. Los usuarios pueden interconectar gadgets existentes simples el uno con el otro para crear servicios cada vez más complejos, ampliando la idea de creación conducida por un wizard y explotando el poder de la semántica en los sistemas de back-end. Por lo tanto, los usuarios tienen que tratar solamente APIs e interfaces, como marcos tradicionales o diálogos de ventana, e interconectarlos para crear aplicaciones gráficas complejos de empleo en vez de usar una de integración de negocios entre empresas orientada BPEL-based. Este esquema visual será trazado en un mapa de servicios y componentes remotos para crear una aplicación integrada de un modo más flexible que una orquestación tradicional BPEL. La composición formal y compleja BPEL-based usada para la integración en SOA ahora es substituida por las técnicas céntradas en el usuario de formación de mash-up que conseguirá aumentar la innovación de negocio como nunca antes. La aplicación de la semántica a este nuevo diseño y el acercamiento de desarrollo (descendente y orientado al usuario) ayudaría a acortar el hueco entre la visión técnica de recursos de back-end y el usuario la visión funcional front-end. Por esta razón, varias plataformas comienzan a trabajar con gadgets complejos y definir un workflow complejo con muchos desvíos de la rama principal por lo general tienen que tratar con la interacción humana.

Adquisición y Compartición de Conocimiento en entornos Web2.0

Folksonomias

Ver entregable D.2.3.1 Informe sobre el modelo formal de los mapas folksonomía-ontología

Redes Sociales

Redes Sociales Genéricas

Las Redes son formas de interacción social, definida como un intercambio dinámico entre personas, grupos e instituciones en contextos de complejidad. Un sistema abierto y en construcción permanente que involucra a conjuntos que se identifican en las mismas necesidades y problemáticas y que se organizan para potenciar sus recursos.

Una sociedad fragmentada en minorías aisladas, discriminadas, que ha desvitalizado sus redes vinculares, con ciudadanos carentes de protagonismo en procesos transformadores, se condena a una democracia restringida. La intervención en red es un intento reflexivo y organizador de esas interacciones e intercambios, donde el sujeto se funda a sí mismo diferenciándose de otros.

En definitiva, las redes sociales surgen y sirven para que, con la fuerza del grupo, un individuo consiga sus objetivos que de otra manera, sin pertenecer a una, podrían ser difíciles. Esto genera nuevos vínculos afectivos y de negocios, lo que realimenta la cohesión de la red.

Historia de las Redes Sociales en Internet

El origen de las redes sociales en Internet se remonta, almenos, a 1995, cuando Randy Conrads crea el sitio Web classmates.com. Con esta red social se pretende que la gente pueda recuperar o mantener el contacto con antiguos compañeros del colegio, instituto, universidad, etc.

Pero no será hasta el año 2001 y 2002 hasta que no se produce el primer 'boom' de estos círculos de amigos. Hacia 2003 se hacen muy populares con la aparición de sitios tales como friendster.com, tribe.net y myspace.com.

Viendo el grandisimo filón que eran, grandes compañías como Google y Yahoo, lanzaron también sus propias redes sociales orkut.com en 2004 y flickr.com en 2005 respectivamente.

Redes Sociales en Internet

En las redes sociales, en Internet, tenemos la posibilidad de interactuar con otras personas aunque no las conozcamos, ni sepamos su sexo, edad o profesión. Aunque normalmente con el tiempo y según la involucración estos datos los vamos conociendo.

El sistema es abierto y se va construyendo obviamente con lo que cada suscripto a la red aporta, cada nuevo miembro que ingresa transforma al grupo en otro nuevo. La red no es lo mismo si uno de sus miembros deja de ser parte.

Obviamente Internet tiene mucho objetivos, cada uno lo utiliza para algo diferente. Y obviamente, cada red social tendrá uno o varios objetivos concretos. Ya sea para hacer negocios, hacer amigos, ligar, o simplemente compartir aficiones, experiencias y conocimiento, existen decenas de sitios web dedicados a crearlas y gestionarlas, lugares donde invitar a los amigos y conocer a los 'amigos de los amigos' (como vemos en la siguiente figura), o aquellas comunidades de intereses comunes. Cuentan con acérrimos partidarios que compiten por ser los más populares en cada red, pero también con detractores que cuestionan su utilidad y que consideran que suponen una preocupante amenaza a la intimidad y al aislamiento.

Imagen:Redessociales.jpg

Las tres propiedades básicas que debe de tener una red social son:

  • Comunicación: Nos ayudan a poner en común el conocimiento, con lo que podremos ir avanzando juntos más rápidamente.
  • Comunidad: Directamente, nos ayudan y nos apoyan. Además de ayudarnos a encontrar cual es nuestro lugar.
  • Cooperación: Nos ayudan a realizar proyectos juntos.


Para terminar diciendo que las redes sociales continúan avanzando en Internet a pasos agigantados, especialmente dentro de lo que se ha denominado Web 2.0. Y dentro de ellas, cabe destacar un nuevo fenómeno que pretende ayudar al usuario en sus compras en Internet: las Redes Sociales de Compras, como Shoomo. Las Redes Sociales de Compras tratan de convertirse en un lugar de consulta y compra. Un espacio en el que los usuarios pueden consultar todas las dudas que tienen sobre los productos en los que están interesados, leer opiniones y escribirlas, votar a sus productos favoritos, conocer gente con sus mismas aficiones y, por supuesto, comprar ese producto en las tiendas más importantes con un solo clic. Sitios como Shoomo.com son el presente del comercio online y el futuro de las compras sociales.


Ejemplos de algunas redes sociales
  • Classmates.com: Red social americana, considerada la primera gran red social por Internet, que desde el año 1995 consigue establecer contactos entre antiguos compañeros de clase, en la actualidad cuenta con mas de 40 millones de usuarios registrados. Y es una de las mayores compañías de Internet con un mayor número de personas subscritas que pagan por sus servicios.
  • MySpace.com: Una de las mayores redes sociales con más de 70 millones de usuarios. En este portal se opina de películas, distribuyen maquetas,se suben videos. MySpace ha creado un ecosistema poblado de pequeñas empresas que ofrecen todo tipo de recursos para que los usuarios decoren sus perfiles, o sofisticadas herramientas para gestionar los e-mails, que a la vez permiten a los anunciantes identificar a su público objetivo.
  • YouTube.com: Red social de vídeos. El la que se publican mas de 50.000 videos nuevos cada día. Con más de 25 millones de visitas diarias. En el que se comparten desde un choque al estilo Jackass a una parte de un programa de televisión. Últimamente esta siendo muy cuestionada por la cantidad de videos no éticos que se estan subiendo.
  • Orkut.com: Toma el nombre del ingeniero de Google Orkut Buyukkokten, permite a los usuarios contactar con amigos de sus amigos, un esquema muy similar al de Friendster. Al igual que ese servicio, Orkut.com sólo acepta a las personas que han sido invitadas por alguien que ya está en la red de contactos.
  • Flickr.com: Perteneciente a Yahoo, ha revolucionado los sistemas de gestión fotográfica online y cuenta con más 100 millones de fotos, un 88% de distribución gratuita.
  • Bebo.com: En tan solo 9 meses ha logrado la cifra de 23 millones de usuarios, que buscan antiguos amigos o nuevas relaciones.
  • MusicStrands.com Sitio español, creado por Francisco J. Martín, ayuda a descubrir y organizar canciones y compartir los temas con otros consumidores. Su tecnología de recomendación social permite personalizar los contenidos en función de los gustos de un individuo o una comunidad, y del contexto.

D 1.2.2 Documento de Líneas Futuras Tecnológicas

Introducción

Conjuntamente con los líderes de los distintos paquetes de trabajo y en el transcurso de proyecto se realizará investigación sobre nuevas tecnologías y estándares susceptibles de ser aplicados en cualquiera de las áreas tecnológicas utilizadas en el proyecto (Web Semántica, MashUps, Web 2.0, Modelos de Negocio y Licenciamiento etc..)

La plataforma que surja de este proyecto pretende no sólo sentar las bases para resolver problemas con los sistemas de información de las empresas, sino tambien facilitar la creación de ecosistemas de componentes y aplicaciones para solventar problemas a los que se enfrentan PYMES, colectivos o incluso individuos en su uso de las tecnologías de la información. Por lo tanto el conjunto de conceptos y tecnologías que se lleguen a manejar será grande, y es necesario desde un primer momento establecer guías en la investigación.


Identificación de tecnologías emergentes y nuevos estándares

En esta sección se repasa el panorama tecnológico en las distintas áreas que toca el proyecto EzWeb, identificando aquellas tecnologías que están configurándose como referentes o tendencias para los próximos años. En algunos casos estas nuevas propuestas están surgiendo en el contexto de un proceso de estandarización que trata de ordenar la innovación, lograr interoperabilidad entre agentes y evitar la fragmentación tecnológica. En otros casos no se ha alcanzado aún la fase de estandarización.

Para un mejor seguimiento de estas propuestas, el repaso se realiza siguiendo las actividades del proyecto EzWeb. Naturalmente, sólo se incluyen las actividades de desarrollo tecnológico, es decir:

  • Actividad 2: Semántica para describir contextos y recursos.
  • Actividad 3: Plataforma de Mashup.
  • Actividad 4: Plataforma Marketplace de Recursos.

Quedan fuera de este repaso las tareas administrativas y no-tecnológicas:

  • Actividad 1: Arquitectura y adquisición de requisitos de usuario.
  • Actividad 5: Experimentación y validación.
  • Actividad 6: Explotación y Difusión de Resultados.

Dentro de este repaso se mencionan tecnologías y estándares que aunque no sean de aplicación directa a día de hoy en algunas de las tareas dentro de la plataforma, son susceptibles de ser estudiadas y vigiladas.

Tecnologías Emergentes

  • Actividad 2: Semántica para describir contextos y recursos.
    • Microformatos. Los microformatos comenzaron a utilizarse dentro de la comunidad de bloggers, pero han ganado popularidad recientemente. Su objetivo es mejorar la descripción semántica de la información presente en las páginas web, para facilitar su reutilización. La sencillez de uso ha ayudado a que los microformatos se hayan implantado rápidamente. Aunque se considera que los microformatos son un paso adelante hacia el despliegue de la web semántica, sin embargo también se ha indicado que carecen de interpretación semántica formal, no se integran con el resto de la web, y responden a un modelo de desarrollo centralizado. El W3C no sólo está culminando RDFa (una alternativa al uso de microformatos), sino que ha publicado GRDDL, una tecnología que, entre otras cosas, permite extraer semántica formal de los microformatos.
    • Folksonomías. Las folksonomías no son en realidad una "nueva tecnología", sino más bien una extensión de las técnicas de anotación y clasificación ya conocidas. Lo que es realmente novedoso es la escala a la que resulta posible aplicar estas técnicas ahora. En el entorno web resulta posible tener miles (millones, incluso) de usuarios con todo tipo de motivaciones, procedentes de distintos lugares geográficos, y que anotan recursos de todo tipo, tanto contenidos producidos por ellos mismos como otros que encuentran en la web. Algunos portales basados en folksonomías se han constituido en poco tiempo en referentes fundamentales de la web, y sus folksonomías son valiosos recursos lingüísticos y muy útiles para facilitar la recuperación de contenidos (por ejemplo, para localizar videos o fotografías etiquetados de cierta forma). Pero el auténtico potencial futuro de las folksonomías pasa por explotar más su naturaleza colaborativa, de manera que permitan generar sugerencias, no sólo para encontrar recursos, sino para anotar nuevos recursos.
  • Actividad 3: Plataforma de Mashup.
    • JSR 311: JAX-RS: The JavaTM API for RESTful Web Services. Esta especificación definirá el conjunto de APIs Java para el desarrollo de Servicios Web construidos de acuerdo con el patrón arquitectural REST. Dicha especificación tendrá como objetivos el funcionamiento a través de Plain Old Java Objects (POJOS) para exponer los recursos Web, el funcionamiento alrededor de HTTP como protocolo fundamental de comunicación, la independencia de formato respecto al contenido de las entidades HTTP, la independencia de contenedor Web y la inclusión en la rama empresarial de java JAVAEE. Es de esperar que debido al gran porcentaje de utilización de la tecnología Java en la parte servidora de muchas aplicaciones Web, la creación de una especificación sea adoptada y seguida por la industria, con lo que será de gran relevancia realizar un seguimiento de las soluciones y patrones adoptados en esta especificación para su posible uso y/o adaptación dentro de la plataforma EzWeb.
    • Lenguajes para la descripción de servicios REST. Aunque existe disensión acerca de su necesidad, actualmente existen varias propuestas para ayudar en la descripción de los servicios REST (además de la posibilidad de utilizar WSDL2.0). Dos de las principales son WADL y WRDL.
      • WADL, la primera propuesta, es similar a WSDL y se centra en describir entradas y salidas de cada servicio de forma que se pueda automatizar la creación de esqueletos de aplicación para trabajar con el recurso. La tecnología está relacionada con la JSR-311 y de momento parece gozar de cierto soporte por parte de la industria.
      • WRDL, por el contrario, se basa en que el modelo de servicio Web REST está descrito como webs de recursos enlazados. Principalmente un servicio será definido a través de documentos XML, cuya estructura será definida a través de esquemas XML. Sin embargo, de dicha forma sólo tenemos una representación parcial ya que no se describen las transiciones entre recursos que son las que fijan el comportamiento del servicio. WRDL se centra en describir dichas transiciones.
    • Tecnologías relativas a seguridad: Uno de los requisitos de la plataforma es el de la seguridad. Es necesario evaluar nuevas tecnologías en el ámbito de la seguridad para ver si es factible aplicarlas dentro de EzWeb. Dentro de ese grupo de tecnologías se pueden incluir; OpenID, OpenSSO, Security Assertion Markup Language (SAML), XML Access Control Markup Language (XACML) o Service Provisioning Markup Language (SPML) entre otros, algunos de ellos comentados en el proyecto Morfeo EzForge.
  • Actividad 4: Plataforma Marketplace de Recursos.
    • Tecnologías para la obtención del contexto. Uno de los requisitos principales de EzWeb consiste en proporcionar al usuario un entorno flexible y que se adapte a sus necesidades en la medida de lo posible. Dentro de ese escenario, cobran importancia las tecnologías relacionadas con el acceso al contexto en el que se desarrollan las acciones, y que puede definir preferencias, proporcionar acceso a nuevos recursos, etc. Dentro de ese grupo de tecnologías se encuentran los algoritmos de matching, el uso de semántica (ontologías, folcsonomías, etc) y los protocolos que permitan transmitir el contexto dentro de la plataforma.
    • Servicios Web Semánticos. Los servicios web semánticos son una solución integrada para la siguiente generación web. Se basan en la conjunción de la tecnología proveniente de la web semántica (formalización del conocimiento mediante ontologías + información procesable automáticamente por las máquinas) y de los servicios web actuales (descubrimiento automático, selección, composición, etc. ejecutados sobre la web). Por lo tanto las tecnologías y conceptos que utilizan pueden servir como de base en el desarrollo de técnicas de match-making, descubrimiento de recursos y adaptación al contexto que se utilizarán dentro del marketplace.
    • Modelos de negocio basados en el uso de servicios. Aunque no sea en su definición estricta una tecnología, sino más bien un nuevo paradigma, la economía basada en el uso de servicios (Software As A Service, SaaS) esta destinada a gobernar en un futuro cercano los escenarios en el uso de las tecnologías de la información. Si bien dentro de EzWeb ya se recoge desde un principio como uno de los pilares fundamentales, la investigación en nuevos modelos de negocio estará presente durante todo el transcurso del proyecto.

Nuevos estándares

  • Actividad 2: Semántica para describir contextos y recursos.
    • Nueva versión de OWL. El W3C desarrolló durante el periodo 2001-2004 la especificación de OWL, el lenguaje de ontologías para la web. En 2004 esta especificación alcanzó el grado de Recomendación (el más alto para un documento en W3C). Desde entonces han aparecido un gran número de herramientas y ontologías basadas en OWL. Sin embargo, también se han identificado algunas limitaciones del lenguaje así como dificultades para su uso. Pero más significativamente, la investigación básica ha continuado avanzando, y ha permitido descubrir nuevas variantes de la Lógica Descriptiva que aumentan la expresividad de las anteriores sin incrementar el coste computacional. Un grupo liderado por la Universidad de Manchester ha desarrollado una nueva versión del lenguaje OWL, y la ha remitido al W3C para su consideración (la member submission fue recibida a finales de 2006). Por tanto, durante el año 2007, el consorcio W3C abrió un nuevo grupo de trabajo para crear y publicar una nueva versión de OWL, basada en la propuesta recibida. Este grupo tiene previsto concluir sus actividades en 2009, dando lugar a OWL 1.1 (el nuevo número de versión no es definitivo, no obstante). Entre las novedades del nuevo lenguaje, se cuentan: nuevos constructores y restricciones, mayor expresividad en tipos de datos e introducción de azúcar sintáctico.
    • SKOS. El grupo de trabajo Semantic Web Deployment de W3C, cuya actividad se está desarrollando desde 2006 y concluirá en 2008, se ha fijado como objetivo conseguir que la tecnología SKOS llegue al grado de Recomendación. SKOS es un modelo basado en RDF para representar bases de conocimiento tradicionales (taxonomías, tesauros, vocabularios controlados) y más modernas (folksonomías). Se pretende facilitar que estas estructuras de conocimiento, que existen desde mucho antes que la web semántica, pasen a formar parte de ella, y ser consultadas mediante los lenguajes de consulta de la web semántica. La evolución y estandarización de SKOS resulta especialmente importante para el proyecto EzWeb por su potencial como vehículo para formalizar folksonomías y anotaciones.
    • RDFa. Los grupos Semantic Web Deployment y XHTML 2.0 de W3C impulsan conjuntamente, a través de un equipo especializado, el desarrollo de RDFa. Se espera que RDFa alcance el grado de Recomendación durante el año 2008, puesto que lleva varios años en desarrollo, pero sólo recientemente ha alcanzado la estabilidad necesaria. RDFa y los microformatos persiguen objetivos similares, si bien desde enfoques muy distintos. Dentro del proyecto EzWeb, RDFa se antoja clave como tecnología para permitir la anotación de recursos, la autodescripción de los contenidos de la web, y la integración de datos para realizar mashup.
    • GRDDL. A finales de 2007, W3C ha publicado GRDDL como Recomendación. Esta tecnología se presenta como un puente que permite extraer semántica formal a partir de documentos XML estructurados pero sin semántica, o débilmente anotados (por ejemplo, mediante microformatos). GRDDL es una tecnología de fácil adopción y mínimamente intrusiva, por lo que se espera que su implantación sea muy rápida.
    • Rule Interchange Format. El W3C trata de definir un lenguaje común que facilite el intercambio de reglas entre distintos sistemas. Actualmente se trata de un área muy activa de investigación, pero donde la estandarización avanza más lentamente. Para el proyecto EzWeb será importante contar con este lenguaje común, puesto que determinada información (especialmente las preferencias de los usuarios y el contexto) tienen expresión como reglas (si estoy en una reunión, entonces mostrar este gadget).
    • SPARQL. A finales de 2007 estaba concluyendo el proceso de desarrollo de SPARQL por parte de W3C. Si bien en el momento de escribir este documento la especificación era "candidata a recomendación", es previsible que en las próximas semanas llegue a Recomendación, después de un proceso bastante largo (el primer borrador es del año 2004). SPARQL es una de las tecnologías claves de la web semántica, y su implantación, incluso antes de su llegada a Recomendación, está muy extendida. Resulta significativo señalar que en su artículo de 2001 en el que definió la visión de la web semántica, Tim Berners-Lee no contempló ningún lenguaje de consultas en la arquitectura. Sin embargo, posteriores revisiones de esa arquitectura por el propio Berners-Lee han incoporado SPARQL como pieza fundamental y transversal. En el futuro, resulta previsible la aparición de nuevas versiones de SPARQL que añadirán funciones de agregación al estilo de SQL (COUNT, SUM, etc.), y capacidades de modificación CRUD (actualmente SPARQL sólo realiza consultas). Junto con el lenguaje SPARQL, se está estandarizando una sintaxis común para los servicios de consultas SPARQL (endpoints), con versiones SOAP y HTTP, así como un vocabulario para representar en XML los resultados de las consultas, mientras otro grupo (ajeno a W3C por ahora) hace lo mismo para JSON. Estos movimientos tienen una enorme importancia de cara a EzWeb, ya que permiten conectar directamente aplicaciones AJAX y gadgets con cualquier proveedor de datos en RDF.
  • Actividad 3: Plataforma de Mashup.
    • HTML 5. Aunque el desarrollo de HTML había sido detenido por el W3C tras la versión 4.x, un grupo externo denominado WHATWG y formado por empresas como Apple, Mozilla y Opera, continuó desarrollando el lenguaje. W3C apostó por XHTML, pero a finales de 2006, el director del consorcio W3C, Tim Berners-Lee admitió que el mercado estaba adoptando XHTML muy lentamente, y que era necesario reanudar la actividad en el frente de HTML para proporcionar un camino de migración menos traumático. Durante 2007 se ha constituido un multitudinario grupo de trabajo dentro de W3C que, tomando como base lo desarrollado por WHATWG, pretende concluir en 2010 una nueva Recomendación denominada HTML 5. Esta nueva versión incorporará un gran número de novedades de gran interés para el desarrollo de la web semántica y las "aplicaciones web" (es decir, el uso de la web como plataforma para desplegar aplicaciones). Entre ellas, un nuevo lenguaje de formularios web con soporte para más verbos HTTP, plantillas de URL para facilitar el uso de REST, nuevas etiquetas y elementos de estructuración del documento, y una sintaxis más relajada a costa de perder la compatibilidad con XML.
    • XHTML 2.0. La reanudación del trabajo en HTML no significa que W3C haya descartado XHTML. Todo lo contrario, un nuevo grupo de trabajo fue formado durante 2007 con el objetivo de completar el desarrollo de XHTML 2.0 (y otras tecnologías relacionadas, como XFrames, XML Events, RDFa y XHTML 1.1 Basic). La planificación indica que XHTML 2.0 será una Recomendación a finales de 2008. Respecto a XHTML 1.0, la nueva versión incorpora nuevas capacidades para estructurar los documentos y las tablas, así como mejoras en imágenes y enlaces. En el contexto del proyecto EzWeb, las novedades más importantes son la adopción de RDFa (ya descrito anteriormente), de XForms (una tecnología mucho más potente para construir formularios web) y XML Events (que añade nuevas capacidades de interacción y programación de eventos). Desde el punto de vista de la arquitectura, XHTML 2.0 mejora la modularidad de su predecesor.
    • Widgets 1.0. Desde el Web Application Formats WG del W3C, perteneciente a la Rich Web Clients Activity, se viene trabajando en un documento que especifique el funcionamiento de Widgets, una clase de aplicación web cliente para representar y/o modificar datos locales o remotos, encapsulados de forma que se permita su instalación en una máquina o dispositivo con una simple descarga. Algunos ejemplos de este tipo de aplicaciones serían relojes, presentadores de noticias, juegos y sistemas de predicción de tiempo. Esta especificación, mediante su combinación con otras, definirá una solución software para el desarrollo de estos widgets. Actualmente el documento se encuentra en fase de Working Draft y sujeto a numerosos cambios, con lo cual la vigilancia sobre él ha de ser intensiva para poder adaptarse a futuros posibles estándares aplicables a la plataforma EzWeb.
    • Revisiones y trabajos sobre Web Services Description Language (WSDL) Version 2.0. En esta nueva versión de WSDL se ha puesto énfasis en la interoperabilidad con servicios REST, en lugar de centrarse sólo en los tradicionales estándares de la familia WS-*. Debido a la relevancia de este estándar, es importante estudiar la compatibilidad de los servicios y recursos definidos en la capa REST de EzWeb con lo reflejado en éste estándar.

Evaluación de los resultados de la investigación (detallados por WP)

En este estadio del proyecto la mayoría de los resultados de investigación aún se encuentran en fase preliminar con lo que aún es pronto para realizar una evaluación completa. Dentro de los entregables adscritos a cada paquete de trabajo se encuentran las conclusiones preliminares.

Actualización del Plan de Riesgos y Contingencias

A partir del seguimiento de las tecnologías, estándares, resultados de investigación y prototipos de la plataforma desarrollados en el proyecto se ha de ir actualizando el plan de riesgos y contingencias dispuesto al comienzo del mismo. Debido a la cantidad de conceptos y tecnologías a integrar es fundamental que esten planificadas las acciones a ejecutar si aparecen nuevos riesgos.

En el estado actual del proyecto, donde aún se está tratando una primera versión, no existen nuevos riesgos potenciales. Si bien debido a la rápida evolución que presentan los proyectos y frameworks basados en mashups, es sobre todo uno el riesgo principal que hay que tener presente y que ya era contemplado en la propuesta del proyecto:

  • El riesgo de que un competidor lance un producto competitivo. Este riesgo ya tiene un plan de contigencia asignado, ya que gracias al proceso iterativo seguido en EzWeb es sencillo añadir nuevas funcionalidades para la siguiente iteración. Además, dentro de cada uno de los paquetes de trabajo ya se han evaluado alternativas de competidores, dejando patente sus limitaciones y la necesidad de los desarrollos de EzWeb.