EndPoint

El actual \diluvio de datos" esta inundando la Web con grandes volúmenes de información representados en RDF, dando lugar a la Web de Datos. Los puntos de acceso a esta red semántica son los SPARQL endpoints, servicios que interpretan el lenguaje de consulta SPARQL. El rendimiento de esta infraestructura se ve claramente afectado por los formatos verbosos utilizados para la representación de RDF, cuyo procesamiento e intercambio introduce importantes retrasos en la comunicación al operar con grandes conjuntos de datos. En este trabajo introducimos los principios básicos de la arquitectura HDT_EndPoints. Esta propuesta se fundamenta en el uso de una representación compacta de RDF, denominada HDT, sobre la que se diseñan servicios para el descubrimiento, consulta e intercambio de información en la Web de Datos.

 

 

Introducción

 

La Web, como ente alimentado social y tecnológicamente, se encuentra en constante evolución. Actualmente, la versión mas utópica de la Web Semántica esta viéndose superada por una versión menos estricta conocida como la “Web de Datos". Esta surge al considerar una visión \centrada en datos" frente al tradicional punto de vista “basado en documentos". Su pilar fundamental es RDF (Resource Description Framework3), un modelo de datos semi-estructurado que permite expresar sentencias como triples (sujeto; predicado; objeto) que pueden verse como grafos etiquetados. El principal valedor de dicho modelo, y de la Web de Datos, es la filosofía Linked Open Data4, que aboga por disponer de datos RDF abiertos y enlazados con otras fuentes de datos. SPARQL5 es el lenguaje de consulta estándar para RDF. Los conjuntos de datos se exponen para su consulta, en la Web de Datos, a través de SPARQL endpoints que, típicamente, entregan sus resultados en un formato procesable automáticamente.

Actualmente se publican en RDF grandes cantidades de datos procedentes de diferentes  áreas, como datos biológicos (Uniprot), estadísticos (2001 US Census), o geográficos (GeoNames). Sin embargo, el diseño original del modelo RDF se centro en la descripción de pequeños documentos o recursos. Esto se traduce en formatos de serializacion, como RDF/XML6 o N37, excesivamente verbosos.

Este hecho ocasiona graves problemas de escalabilidad a la hora de publicar e intercambiar las colecciones disponibles en la Web de Datos. HDT [2] es un formato de serializacion RDF que acomete la problemática anterior.

Este trabajo contempla las propiedades de HDT como base para el desarrollo de una nueva arquitectura (denominada HDT_EndPoints) que afronta el consumo de grandes colecciones RDF. Esta propuesta modela la Web de Datos como una red (ver Figura 1) cuyos nodos almacenan, sirven y se comunican utilizando HDT, facilitando que los usuarios (no necesariamente humanos) interactúen de forma eficiente sobre las colecciones potencialmente distribuidas.

Arquitectura HDT_EndPoints

HDT

HDT[2] es un formato binario para la representación compacta de datos RDF, modelando un conjunto de datos mediante tres componentes: (i) la cabecera (Header) contiene metadatos sobre la colección y su organización para facilitar su descubrimiento y consumo, (ii) el diccionario (Dictionary) organiza el vocabulario utilizado en la colección en RDF asignando un identificador numérico  único a cada elemento, y (iii) los triples (Triples) representan la topología del grafo.

HDT permite representar un conjunto de datos RDF en un 15% del espacio utilizado por los formatos tradicionales de RDF [2], llegando a cotas cercanas al 4% si se combina con compresores universales. Una implementación del componente Triples [1], basada en estructuras de datos compactas, indexa la topología del grafo de forma comprimida y permite, a su vez, la resolución eficiente de consultas sobre lo mismo.

Que es SOA?

La Arquitectura Orientada a Servicio no es una forma nueva de crear soluciones a problemas del dominio, sino más bien un paradigma de organización que permite obtener mayor valor de las capacidades, tanto poseídas como controladas por otros. SOA no provee elementos del dominio de una solución que no exista sin SOA. El objetivo en SOA es hacer que cada subsistema de una empresa presente sus capacidades a través de servicios adecuados, que permitan usar las capacidades de una manera homogénea. Esto evita crear interfaces para cada par de sistemas que requieran comunicación. La filosofía atrás del concepto es que cada sistema brinda servicios a clientes desconocidos, por lo que se debe hacer hincapié en las capacidades que se ofrecen y no en quién las va a usar. Esta filosofía de servicio permite crear funciones que sean utilizables por distintos clientes; simplemente deben conocer la descripción del servicio para poder utilizarlo.

 

Conceptos importantes en SOA

Los siguientes conceptos son indicados por Oasis como principales, en el contexto de Arquitecturas de Servicios. Pueden ser implementados de distintas formas, pero deben estar presentes para que la orientación a servicio sea factible.

Visibilidad

Para que el consumidor y el proveedor de un servicio puedan interactuar deben, primero, poder ‘verse’. La visibilidad implica conocimiento (el iniciador debe conocer la existencia de las otras partes), voluntad (los participantes deben estar predispuestos a interactuar) y alcanzable (los participantes deben tener un medio de interacción). El conocimiento requiere que el proveedor de un servicio sea capaz de hacer llegar los detalles del servicio (descripción y políticas) a potenciales consumidores. Se suele lograr por medios de publicación y descubrimiento. La voluntad para interactuar, de parte de un proveedor de servicio, puede ser sujeta a políticas (por ejemplo, puede requerir autenticación y autorización). Un consumidor y un proveedor de servicio pueden tener el conocimiento y la voluntad para proceder, pero si no son alcanzables, no podrá haber interacción.

Interacción

La interacción implica realizar acciones frente a un servicio; generalmente involucra el intercambio de mensajes, pero también puede significar un cambio en algún estado compartido. Para permitir la interacción, se debe contar con un modelo de información (establecer el formato de la información intercambiada) y un modelo de comportamiento -acciones invocadas frente al servicio (modelo de acción) y los aspectos temporales (modelo de proceso) de interactuar con el servicio.

Efectos del mundo real

La ejecución de un servicio produce un efecto en el mundo real, que puede ser un cambio en un estado compartido o un dato en la respuesta. Un estado compartido es aquél al que tiene acceso tanto el proveedor como el consumidor del servicio. Las acciones internas que se realicen al ejecutar un servicio son, por definición, privadas y fundamentalmente desconocidas; es decir, un consumidor no sabe sobre el funcionamiento interno del proveedor y viceversa. Esto permite limitar las dependencias entre partes a las interfaces de interacción (mensajes, formatos de datos, etc.). Los efectos de un servicio deben estar especificados en su descripción.

Principios básicos de SOA

Los siguientes son objetivos generales buscados en Arquitecturas Orientadas a Servicios:

Límites son explícitos

Los servicios pueden estar distribuidos en diferentes zonas geográficas, pueden afectar diferentes dominios (de tecnologías propietarias) y normalmente se ejecutan en entornos diferentes. Bajo este contexto, los servicios se ejecutan a través del intercambio de mensajes, confiriendo a la implementación del servicio la problemática intrínseca de resolver cómo ejecutar la función que corresponda y a través de qué protocolo (RPC, APPC, TCP, etc.).

Servicios autónomos

·         Independencia en el deployment de los servicios

·         Control de excepciones

·         Control de integridad de los resultados de la ejecución del servicio

·         Seguridad (e.g. control de los datos de entrada, mensajes malformados)

·         Control de identidad

·         Autorización

·         Autenticación

·         Otros servicios de infraestructura (transacciones, timeout, etc.)

Compartir esquemas y contratos

Los servicios no comparten clases (con datos y comportamiento), comparten schemas (datos) y contratos (comportamiento). Mensajes de entrada y salida que corresponden a la definición de los schemas.

Compatibilidad de servicios basada en políticas

La compatibilidad estructural está determinada por los schemas y contratos. La compatibilidad semántica esta determinada por la confirmación de diferentes políticas (aspectos): autenticación, autorización, validación de datos de entrada. Todas las condiciones deben darse para garantizar la ejecución normal del servicio.  

Ventajas de implementar SOA

Respuesta rápida a nuevas necesidades de negocio

Al tener todas las capacidades del negocio representadas en servicios, cuando se necesita una nueva interacción, simplemente se pueden utilizar los servicios existentes por medio de una nueva colaboración, limitando los desarrollos a capacidades nuevas. Se asume que la creación de una colaboración de servicios es mucho más sencilla que el desarrollo de las capacidades totales de los servicios e, incluso, es más simple que hacer interfaces propietarias para la colaboración. La implementación de SOA debe ser adecuada para que esta asunción sea realidad.

Reducción del costo de desarrollo de IT

El hecho de que se necesite menos desarrollo de integración, reduce los costos de IT que estarían destinados a este fin. A su vez, reduce el nivel de acoplamiento, por lo que un cambio en un servicio no afectará a los consumidores. Mejora la definición de los roles de desarrollo. Al implementar cada función de negocio como un servicio diferente, permite delimitar mejor las responsabilidades de cada programador. Facilita el testeo. El bajo acoplamiento y la granularidad permiten un testeo más específico de las funciones. Mejora el mantenibilidad. Favorece la reutilización y mejora la productividad. Favorece el desarrollo en paralelo.

Capacidad de integrar a clientes y socios

Una gran ventaja de SOA es que está estandarizado. Existen varias especificaciones de SOA, lo cual permite que distintas empresas puedan publicar parte de los servicios de su negocio para que clientes, proveedores y socios puedan acceder a ellos. En particular, Web Services es adecuado para esto, ya que está basado en tecnologías ubicuas (HTTP, XML, etc.). Existen además muchas herramientas útiles que lo soportan.

Capacidad de generar nuevos modelos de negocios

Con la aparición de herramientas de modelado de negocio e integración de servicios, se pueden analizar nuevos modelos de negocios, ver cómo los servicios actuales los soportan y ver qué necesidades deben completarse.

Alinear objetivos de IT a objetivos de negocio

La agilidad para responder a nuevas necesidades de negocio hace más sencillo mantener alineados los objetivos de IT con los del negocio. Se logra un mapeo más directo entre los procesos de negocio y los sistemas. La composición de servicios permite replicar los procesos del negocio del mundo físico en el mundo virtual, de un modo más directo y natural.

Servicie Messaging Patterns

El servicio de mensajería ofrece tecnicas para el procesamiento y coordinación en el intercambio de datos entre servicios. Es un patron base que puede especializar a otros patrones tales como:

Messaging Metadata

Service Agent

Intermediate Routing

State Messaging
Service Callback

Service Messaging 

El servicio de mensajería responde a la problemática al protocolo de comunicación remota tradicional donde se ve a necesidad de conexiones  fuertemente acopladas en el intercambio de datos.  El servicio de mensajería busca eliminar la necesidad de conexiones persistentes. Adicionalmente, ofrece QoS, seguridad, eficiencia y confiabilidad.

El ejemplo dado es la necesidad dependencia sobre frameworks  de invocación remota como RPC. Donde se establece conexiones persistentes para el intercambio de datos entre unidades de software.

La mensajería proporciona una alternativa para no depender de conexiones persistentes. Los mensajes se transmiten como unidades independientes de comunicación como se muestra en la figura:

 

 

Algunos frameworks de mensajería no puede proporcionar un nivel de QoS para soportar las altas demandas.  Para poder habilitar la aplicación de otros patrones, el servicio de mensajería debe proporcionar lo siguiente:

·       Garantizar la entrega del mensaje o notificar los errores de entrega.

·       Gestionar el estado y el contexto de los datos a través de una actividad de servicio.

·       Transmitir mensajes  eficientemente en tiempo real.

·       Servicio de Coordinación de las transacciones.

A pesar que la tecnología RPC fue una tecnología muy eficiente y fiable, los retos de RPC son:

·       Los componentes que establecen las conexiones consumen mucha memoria.

·       Dificultad para cambiar los diseños existentes de distribución debido a las depenencias entre los componentes que se formaron.  Los patrones de comunicación eran rigidos y sincrónicos.

Las prestaciones de los servicios son desarrolladas e implementadas con tecnología Web Service.

Messaging  Metadata

Los servicios en este patrón están diseñados para procesar información propia de las actividades en tiempo de ejecución. En este caso la mensajería no depende de una conexión persistente entre un servicio y el consumidor. Lo que tiene que hacer un servicio, es acceder a los datos de estado asociada a una actividad del tiempo ejecución total. Entonces el mensaje tiene información meta adicional de la actividad específica y ésta es interpretada  y procesada en tiempo de ejecución por un servicio.  Este patrón requiere un framework que soporte encabezados de mensajes o propiedades. Por otro lado la interpretación y procesamiento de los metadatos de los mensajes hace que se genere una sobre carga de rendimiento en tiempo de ejecución y aumenta la complejidad de los servicios.

 La tecnología de mensajería para la comunicación de servicios soporta encabezados de los mensajes o propiedades en los cuales llevan información dentro del documento del mensaje como se muestra en la imagen, siendo de utilidad para identificar y enrutar los mensajes.

 

 

 

Google Cloud Messaging

Google Cloud Messaging abierto a desarrolladores

Geogle sigue innovando un poco mas cada día en los servicios que crea para los desarrolladores androides. En esta ocasión, Geogle ha lanzado un nuevo servicio de envió de datos mediante la nube. Geogle Cloud Messaging nos permite enviar datos a nosotros mismos, a otros usuarios o a nuestra aplicación mediante nuestro dispositivo Android. 

Este servicio de Google recibió en sus comienzos las siglas C2DM (Cloud to Device Messaging), pero después de su salida de fase beta modifico su nombre a GCM (Google Cloud Messaging). En resumen, es la manera de recibir notificaciones push en nuestras aplicaciones Android. 

Este servicio repercute buenamente en varios aspectos de la vida Androide. Quiero decir, que puede mejorar una gran parte de las aplicaciones existentes al mejorar las notificaciones y reducir el consumo del Smartphone, al no tener estos que estar pidiendo al servidor cada dos por tres información sobre las notificaciones pendientes.

 

Gracias a la salida de este servicio los desarrolladores podrán enviar un mensaje de poco peso a la aplicación para decirle que hay información que recoger del servicio como, por ejemplo, unos mensajes o unas nuevas fotos. En definitiva, una motivación push. Un buen ejemplo seria Whatsapp. Nosotros enviamos un mensaje al servidor y este se encarga de decirle al otro usuario que tiene un mensaje que leer. Por lo que la aplicación no tiene que estar pendiente al servidor cada “X” tiempo si hay mensajes pendientes.