PDF de programación - CAPTULO 4 (MICROSOFT ROBOTICS STUDIO)

CAPÍTULO 4:

MICROSOFT ROBOTICS

STUDIO





















4.1 - INTRODUCCIÓN AL MODELO DE APLICACIÓN



Microsoft Robotics Studio está basado en un entorno de Windows y su uso está dirigido a
la creación de aplicaciones de robótica de forma sencilla y para una gran variedad de
plataformas de hardware de ámbito académico, de aficionados y para su desarrollo
comercial. La ejecución de Microsoft Robotics Studio desarrolla un entorno que ha sido
diseñado para complacer las necesidades de un amplio rango de aplicaciones de
robótica:



1. Debe ser posible monitorear el estado e

interactuar con componentes

individuales mientras la aplicación está siendo ejecutada.

2. Debe ser posible descubrir, crear, poner fin, y reiniciar componentes mientras la

aplicación está siendo ejecutada.

ser posible

trabajar con

3. Debe

sensores
simultáneamente y organizar tales entradas como tareas, sin riesgo de
interferencias no intencionadas entre tareas.

las entradas de múltiples

4. Debe ser posible manejar aplicaciones automatizadas autónomas así como

controladas, ambas a nivel local y lo largo de la red de trabajo.

5. La ejecución debe ser ejecutada de una forma suficientemente “ligera” en una

gran variedad de entornos.

6. El entorno de aplicación debe ser suficientemente extensible y flexible para

complacer la interacción con una gran variedad de hardware y software.

Para cubrir estos requisitos, la ejecución de Microsoft Robotics Studio provee una
arquitectura de servicio orientada que combina los aspectos clave de la arquitectura
tradicional basada en Web con servicios en red para proporcionar un modelo de
aplicación flexible, ligero y muy distribuido.



El enfoque principal de la arquitectura Web está en la sencillez, la interoperabilidad, y
la conexión ininterrumpida. Las aplicaciones basadas en Web demuestran a través del
HTTP (HyperText Transfer Protocol) que este modelo se ajusta bien, suministra la
interoperabilidad, y es suficientemente flexible para complacer una gran variedad de
situaciones.



A pesar del éxito del HTTP, sin embargo, hay aspectos bien conocidos que no capta de
forma eficaz. En particular, las dos limitaciones con las que las aplicaciones Web se
encuentran repetidamente son:



1. Ausencia de soporte para la manipulación de los datos estructurados. Es decir las
únicas operaciones permitidas en un recurso están en el "nivel del recurso", no
en la subestructura de un recurso. Esto hace difícil actualizar el estado de un
servicio, lo que limita cómo pueden interactuar los servicios.

2. No hay ningún soporte para la notificación de eventos. El HTTP es un protocolo
de solicitud/respuesta y no permiten modelos de notificación de eventos basados
en transmisión de datos. Mientras mecanismos como el RSS son muy útiles,
todavía son básicamente orientados a la extracción de datos y suministran poco
soporte para filtros estructurados.

Un aspecto clave del HTTP es que permite que las aplicaciones saquen provecho de un
modelo de aplicación simple y orientada a estado, comúnmente conocido como REST.
La ejecución de Microsoft Robotics Studio está basada en el modelo de REST pero lo
aumenta con fragmentos de servicios Web para permitir la manipulación de datos
estructurada y la notificación de eventos.



Extendiendo el modelo de REST de esta manera, las aplicaciones pueden aprovechar un
modelo de notificación de eventos y la manipulación estructurada de los datos sin
perder la interoperabilidad con la infraestructura de REST existente. El resultado son
aplicaciones mucho más interactivas y dinámicas construidas como composiciones de
servicios que se organizaron a lo largo de la red.



4.1.1 - Web y REST

El término "REST" fue creado por Roy Fielding. Abstrae, y a la vez, formaliza la
arquitectura de Web. El REST se basa en la noción presentada por Tim Berners-Lee
según la cual un URI (Uniform Resource Identifier, identificador uniforme de recurso)
hace referencia a un recurso y todas las interacciones con ese recurso ocurren mediante
el intercambio de estados. Se puede establecer un símil en el que un recurso sería como
una persona y una fotografía de esa persona como una representación especial. Las
representaciones pueden cambiar con el tiempo y ser expresadas en gran variedad de
formatos de datos. Por ejemplo, una representación de una persona puede ser dada como
una fotografía, una descripción de texturas, un vídeo, etcétera. La única manera de
interactuar con recursos es a través del intercambio de las representaciones de estado.
La separación de estado y comportamiento de un recurso es un componente
fundamental para conseguir conexión ininterrumpida entre componentes que se
comunican entre sí.



Mientras muchas personas piensan en el REST como únicamente dirigido al HTTP, ésta
no es la verdad. Los principios del REST (y la arquitectura de Web en general) pueden
ser implementados en gran número de maneras pero hoy por hoy, el HTTP es el único
protocolo que permite que uno piense en términos de REST eficazmente: respalda a los
URIs y suministra un lenguaje compartido para interactuar con los recursos.



4.1.2 - SOAP y REST: manzanas y naranjas

El protocolo de SOAP (Simple Object Access Protocol) está en el núcleo del modelo de
servicios de Web. Mientras el SOAP se puso en marcha como una manera de publicar
por entregas objetos de C# y Java, por la época en que SOAP/1.0 fue publicado, tenía la
estructura de mensaje semi-estructurado y estaba concentrado en la extensibilidad.



Debido a que SOAP es un protocolo, es comparado con el HTTP y el REST a menudo,
pero ése es un error. El objetivo de SOAP es proporcionar un modelo de extensibilidad
distribuido y estructurado, mientras que el propósito del REST es proporcionar un
modelo de aplicación.



El modelo de extensibilidad de SOAP está basado en un conjunto de reglas para
procesar un mensaje de SOAP que permite que un remitente indique lo que un receptor
debe hacer para procesar ese mensaje apropiadamente. El modelo de extensibilidad
proporcionado por SOAP era un conjunto directo de aquello que proveía el HTTP y se
desarrolló a partir de la observación de las muchas maneras en que el HTTP estaba
siendo usado.



La diferencia principal entre el HTTP y SOAP es que SOAP no define un modelo de
aplicación como el HTTP y es ahí donde volvemos a REST. Porque SOAP no se
preocupa por cómo está siendo usado: puede soportar cualquier número de modelos de
aplicación que se extienden desde RPC a aplicaciones con holguras acopladas e incluso
aplicaciones de estilo REST.



El resultado de estas diferencias es que ambos protocolos desempeñan funciones útiles
y complementarias, y aunque SOAP es usado principalmente en el contexto de la
programación de estilo de RPC, actualmente no hay ninguna razón para que SOAP no
pueda ser también usado en un contexto de SOAP.





4.1.3 - Ejecución de Microsoft Robotics Studio

La ejecución del Microsoft Robotics Studio proporciona un entorno, también conocido
como nodo, para crear, ofrecer, dirigir, y conectar servicios dentro de ese nodo y a lo
largo de la red con el propósito de situarlos en las aplicaciones. El resultado es un
modelo de aplicación distribuido donde los nodos son semejantes en vez de clientes y
servidores, y los datos son intercambiados de forma bidireccional a petición, en lugar de
por sondeo.



El soporte de tiempo de ejecución o Runtime de Robotics Studio consta de dos
componentes principales que hacen posible la construcción, supervisión, despliegue y
funcionamiento de un gran rango de aplicaciones. Estos dos componentes son el CCR
(Concurrency and Coordination Runtime) y el DSS (Decentralized Software Services):



1. La concurrencia y coordinación de la ejecución (CCR), que permite la
coordinación de mensajes sin el uso de coordinación manual, bloqueos,
semáforos, etcétera. El CCR está basado en el paso de mensaje asíncrono y
proporciona el contexto a una ejecución para servicios incluyendo un conjunto
de prototipos de alto nivel para sincronizar los mensajes.

El CCR permite la coordinación concurrente y asíncrona del flujo de ejecución
abstrayendo al programador del uso de hilos, semáforos y otras técnicas de más
bajo nivel para el aseguramiento de la exclusión mutua o la prevención del
interbloqueo. Además plantea un modelo de programación asíncrona que facilita
y optimiza la explotación de un entorno de ejecución paralelo o multihilo. Cabe
destacar que el CCR es un componente DLL que se ejecuta en el entorno .NET y
accesible desde cualquiera de los lenguajes de programación disponibles en
.NET.

2. Servicios de sistema descentralizados (DSS), que proporcionan un entorno y un
juego de servicios básicos que facilitan tareas tales como depurar, la
observación, la seguridad, el descubrimiento, y la recuperación de datos.
El DSS combina la arquitectura tradicional Web (HTTP) con elementos de las
nuevas arquitecturas orientadas a servicios Web (SOAP). La arquitectura
resultante está completamente basada en servicios que se coordinan entre sí para
crear aplicaciones distribuidas. Por lo tanto, desde este punto de vista, una
aplicación desarrollada en Robotics Studio es un conju