Angel "Java" Lopez : Concurrency and Coordination Runtime

Web Crawler distribuido usando AjMessages

lopez — Tue, 10 Mar 2009 01:07:04 GMT

En Enero pasado, actualicé mi proyecto AjMessages para que soporte comunicación usando DSS/CCR y Windows Communication Foundation. AjMessage puede ejecutarse de forma distribuida, enviando mensajes desde un nodo lógico a otro. Los nodos lógicos pueden albergarse en una o más máquinas física. Más información sobre AjMessages en:

AjMessages- a message processor
Distributed Applications with AjMessages using DSS/CCR
Aplicaciones Distribuidas con AjMessages usando DSS/CCR
AjMessages- hacia un procesador de mensajes

Pueden descargar el código fuente desde

http://www.codeplex.com/ajmessages

Tenía la idea de escribir un procesador de mensajes distribuidos. Hace unos años, escribí mi primer intento, llamado AjServer

Hacia el AjServer

Luego, encontré al proyecto Fabriq, estudiando sus ideas e implementación. En ese proyecto, hay manejadores (handlers) lógicos de mensajes, que pueden instalarse de modo distribuido, de forma transparente, cambiando la información de configuración:

En el 2007, escribí la primera versión de AjMessages, como prueba de concepto: pude reproducir bastante de las ideas de Fabriq, y a la vez, elevar el nivel de abstracción de algunos puntos, para conseguir mayor flexibilidad. Fabriq estaba más orientado a SOA. AjMessages se orienta a mensajes arbitrarios, que coordinados, pueden funcionar en una aplicación en grilla.

La solución actual de AjMessages es:

Hay un proyecto núcleo, y dos proyectos de transporte: uno para soporte de WCF, y otro que se basa en DSS/CCR (tecnologías de Microsoft Robotics). Si no tienen DSS/CCR instalado, pueden remover los proyectos que lo referencia. El núcleo de AjMessages está lib de dependencias de esas tecnologías.

AjMessages.SampleApp contiene un simple manejador de mensajes: un decrementador de enteros, que toma un mensaje de entrada, con un contenido entero, lo decrementa, y produce un nuevo mensaje.

En cambio, AjMessages.WebCrawler implementa el mensaje y manejadores de mensajes para armar un web crawler distribuido. Pueden ejecutarlo desde una sola máquina, o en varias.

Cara AjMessages tiene:

Body: un contenido arbitrario
Headers: información adicional, por clave/valor.
Action: describe el destino del mensaje, usando un patrón Aplicación/Nodo/Acción

(más detalle en AjMessages- hacia un procesador de mensajes)

Exploremos el ejemplo de web crawler. Esta aplicación está compuesta de nodos, que pueden ser orquestado para visitar una página web, tomar de esa página todos los enlaces relacionados, y volver a tomar esas páginas. Para que no sea un proceso infinito, la visita de páginas se limita al sitio inicial, y hasta un nivel de profundidad. La aplicación puede ser descripta lógicamente con este diagrama:

El primer mensaje se envía al nodo Controller, a su acción Dispatch. Ese primer mensaje contiene la dirección de la página a visitar. El mensaje es enriquecido, y pasado al nodo Controller, acción Resolve. Este nodo está a cargo de mantener la lista de páginas ya visitadas, y de controlar la profundidad de exploración. Si el enlace recibido es aprobado, entonces el mensaje es enviado al nodo Downloader, acción Download. El contenido de la página es recuperado, agregado al mensaje, y reenviado al nodo Harvester, a su acción Harvest. Esta acción analiza el contenido de la página, y emite varios mensajes, uno por cada enlace encontrado. El receptor de esos nuevos enlaces es el nodo Resolver, en su acción Resolve. Así, el proceso continua hasta visitar todas las páginas (con un límite en la profundidad a explorar).

Esta aplicación se puede describir en un archivo de configuración XML, como por ejemplo:

<?xml version="1.0" encoding="utf-8" ?>
<AjMessages>
  <Application Name="WebCrawler">
    <Node Name="Dispatcher">
      <Handler Name="DispatcherHandler" Type="AjMessages.WebCrawler.Handlers.Dispatcher, AjMessages.WebCrawler"/>
      <Action Name="Dispatch" Handler="DispatcherHandler"/>
    </Node>
    <Node Name="Harvester">
      <Handler Name="HarvesterHandler" Type="AjMessages.WebCrawler.Handlers.Harvester, AjMessages.WebCrawler"/>
      <Action Name="Harvest" Handler="HarvesterHandler"/>
    </Node>
    <Node Name="Downloader">
      <Handler Name="DownloaderHandler" Type="AjMessages.WebCrawler.Handlers.Downloader, AjMessages.WebCrawler"/>
      <Action Name="Download" Handler="DownloaderHandler"/>
    </Node>
    <Node Name="Controller">
      <Handler Name="ResolverHandler" Type="AjMessages.WebCrawler.Handlers.Resolver, AjMessages.WebCrawler"/>
      <Action Name="Resolve" Handler="ResolverHandler"/>
    </Node>
  </Application>
</AjMessages>

Un aplicación, entonces, está compuesta de nodos lógicos. Cada nodo puede ser visto como una clase lógica. Cada nodo puede manejar acciones, que son los puntos destinos de los mensajes. Una acción puede estar compuesta de uno o varios pasos. Este es el punto de extensibilidad de la aplicación: deben proveer los pasos, el manejador de mensaje, y escribir el archivo de configuración que orquestre el procesamiento de los mensajes.

Pero una cosa es la aplicación, y otra es su distribución en máquinas físicas. Pueden tener dos hosts, e instalar diferentes nodes en cada uno:

En este diagrama, el Dispatcher y el Resolver están en un hosts, mientras que el Downloader y el Harvester están en otro. Pero Uds. pueden poner Harverstes en cada hosts, o en veinte máquinas. Queda en Uds. cómo distribuir la carga del trabajo. Cuando un mensaje es enviado a un destino (Aplicación/Nodo/Acción), AjMessage lo reenvía a un host apropiado, que contenga un nodo capaz de procesar el mensaje.

La distribución de nodos lógicos en un host físico se define via configuración, por ejemplo:

<?xml version="1.0" encoding="utf-8" ?>
<AjMessages>
  <Host Name="Server1" Address="http://localhost:50002/AjMessages" Activate="true">
    <Application Name="AjMessages">
      <Node Name="Administration"/>
    </Application>
    <Application Name="WebCrawler">
      <Node Name="Controller"/>
      <Node Name="Dispatcher"/>
      <Node Name="Harvester"/>
      <Node Name="Downloader"/>
    </Application>
  </Host>

  <Host Name="Server2" Address="http://localhost:50003/AjMessages">
    <Application Name="AjMessages">
      <Node Name="Administration"/>
    </Application>
    <Application Name="WebCrawler">
      <Node Name="Dispatcher"/>
      <Node Name="Harvester"/>
      <Node Name="Downloader"/>
    </Application>
  </Host>
</AjMessages>

Ejecutando el ejemplo Web Crawler

Pueden probar el programa, lanzando dos hosts, en la misma máquina. Hay que ejecutar el programa de consola AjMessage.Console. Al comenzar esta aplicación, podemos ingresar el comando

fork

Este comando lanza un segundo host. Ahora, podemos configurar los dos hosts. En el primero, ingresamos:

load ConfigurationServer1.xml

Este archivo carga la aplicación AjMessage inicial (es una aplicación más dentro de "la grilla"), y define un endpoint WCF para escuchar mensajes de otros posibles hosts. Ahora, en la misma consola, ingresamos:

load ConfigurationWebCrawler.xml

Este comando carga la definición de la aplicación Web Crawler, con sus nodos lógicos (no hay información de deploy todavía). El tercer comando, define la distribución física de hosts:

load ConfigurationWebCrawlerNode1.xml

Ahora, volvamos a la segunda consola. Ahí, ingresamos los comandos:

load ConfigurationServer2.xml
load ConfigurationWebCrawler.xml
load ConfigurationWebCrawlerNode2.xml

Estamos listos para lanzar el primer web crawling. Vamos a la primera consola, e ingresamos:

send WebCrawler/Dispatcher/Dispatch http://ajlopez.zoomblog.com

El programa comienza a trabajar, en AMBAS consolas. Una típica salida de la primera consola:

Próximos pasos

Debería arreglar algunos problemas en el transporte DSS/CCR (actualmente, puede ejecutar una aplicación simple como el decrementador de enteros, pero no con el web crawler). Dos puntos para implementar:

- Configuración remota de nodos
- Distribución de los manejadores de mensajes (sus .dlls) a los nodos remotos
- Una configuración para todos los nodos (ahora, cada nodo es configurado separadamente)

Comencé un experimento con un proceso más abstracto de mensajes, que quisiera que pudiera implementar casos de uso como:

- Un simple hello world
- El ejemplo de decrementar enteros
- Web crawler distribuido
- Una especie de Enterprise Service Bus

Pueden ver mis primeros pasos en:

http://code.google.com/p/ajcodekatas/source/browse#svn/trunk/AjProcessor

Todavía en desarrollo.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Aplicaciones distribuidas con AjMessages usando DSS/CCR

lopez — Fri, 10 Oct 2008 11:42:46 GMT

Por ahora, es solo un proyecto en marcha. La aplicación de ejemplo es mínima. Pero es la evolución de mi trabajo anterior con AjMessages usando Windows Communication Foundation:

AjMessages- a message processor
AjMessages- hacia un procesador de mensajes

El año pasado excribí ese ejemplo, y otro que usaba DSS/CCR. Solo el primero fue publicado, ahora, estuve revisando mi implementación con DSS/CCR, tecnologías que son la base de Microsoft Robotics. El código nuevo se puede bajar del repositorio de CodePlex en:

http://www.codeplex.com/ajmessages

Los ejemplos estan basados en ideas del proyecto Fabriq, ahora en nuevas tecnologías. En estos días, Arvindra Sehmi escribió sobre una nueva versión de Fabriq, llamada Fabriq4Dss, que está usando DSS/CCR como base. Preparó una presentación para la conferencia JAOO, lean:

JAOO 2008 Presentation

Espero que pronto aparezcan novedades sobre esa implementación y otras. Keep tuned!

La solución

Tiene tres proyectos:

El primero es la implementación del núcleo del sistema, que es independiente del transporte de los mensajes distribuidos:

El segundo proyecto contiene un ejemplo con un message handler que decrementa un entero. El tercer proyecto es un DSS Service Component que se usa para albergar el servidor de AjMessages en una máquina con un DSS Host:

Para una más detallada explicación de qué es una aplicación, mensaje, servidor, leer mis anteriores posts:

AjMessages- a message processor
AjMessages- hacia un procesador de mensajes

La aplicación

Un archivo de configuración XML define las aplicaciones a ejecutar. Una aplicación tiene:

Nodes: una colección de acciones a procesar (un nodo tiene varias acciones, podría ser análogo a clase/método).
Handlers: objetos que procesan mensajes. Un handler puede estar compuesto de otros handlers.
Actions: puntos con nombre para entrar a un handler

Un ejemplo de definición de aplicación en AjMessages.SampleApp\Configurations\Server1.xml:

<?xml version="1.0" encoding="utf-8" ?>
<AjMessages>
  <Application Name="AjMessages">
    <Node Name="Administration">
      <Handler Name="ConfigureHandler" Type="AjMessages.ConfigureHandler, AjMessages"/>
      <Handler Name="PrintHandler" Type="AjMessages.PrintHandler, AjMessages"/>
      <Handler Name="PrintMessageHandler" Type="AjMessages.PrintMessageHandler, AjMessages"/>
      <Handler Name="ConfigurePipeline">
        <Handler Name="PrintHandler">
          <Property Name="Text" Value="Reconfiguring server..."/>
        </Handler>
        <Handler Name="ConfigureHandler"/>
      </Handler>
      <Action Name="Configure" Handler="ConfigurePipeline"/>
    </Node>
  </Application>

  <Application Name="App1">
    <Node Name="Node1">
      <Handler Name="PrintMessageHandler" Type="AjMessages.PrintMessageHandler, AjMessages"/>
      <Handler Name="PostHandler" Type="AjMessages.PostHandler, AjMessages"/>
      <Handler Name="DecrementHandler" Type="AjMessages.SampleApp.Handlers.DecrementHandler, AjMessages.SampleApp"/>
      <Handler Name="Pipeline1">
        <Handler Name="DecrementHandler"/>
        <Handler Name="PostHandler">
          <Property Name="Action" Value="App1/Node1/Process"/>
        </Handler>
      </Handler>
      <Action Name="Process" Handler="Pipeline1"/>
    </Node>
    <Node Name="Node2"/>
  </Application>

  <Host Name="Server1" Activate="true">
    <Application Name="AjMessages">
      <Node Name="Administration"/>
    </Application>
    <Application Name="App1">
      <Node Name="Node1"/>
      <Node Name="Node2"/>
    </Application>
  </Host>

  <Host Name="Server2" Address="http://localhost:50002/ajmessages/node">
    <Application Name="AjMessages">
      <Node Name="Administration"/>
    </Application>
    <Application Name="App1">
      <Node Name="Node1"/>
      <Node Name="Node2"/>
    </Application>
  </Host>
</AjMessages>

Ejecutando el ejemplo

Abrimos la solución en el Visual Studio 2008 (se necesita tener instalado un Microsoft Robotics Developer Studio, una versión CTP de este año, debe configurar el directorio de salida de los proyectos para que apunten a su directorio de MRDS). Al ejecutar el proyecto DSS se lanza un DSS Host, que muestra una ventana de control:

El host está ejecutando en las puertas 50000/50001. Configure el servidor AjMessages usando el archivo AjMessages.SampleApp\Configurations\Server1.xml.

Podemos lanzar un segundo host desde el prompt de DSS:

bin/dsshost /p:50002 /t:50003
m:<pathto>\Source\AjMessages.DssServices\AjMessagesDssServices.manifest.xml

Un segundo formulario aparece:

Use el archivo de configuración AjMessages.SampleApp\Configurations\Server2.xml y el port 50002.

Podemos enviar un mensaje a la aplicación de ejemplo (que ejecuta en dos hosts). El mensaje es solamente un entero, que es decrementado en cada proceso de acción en cada nodo. El nodo de decremento está instalado en ambos servidores, así que el mensaje viaja de uno a otro durante su proceso.

Próximos pasos

Quiero mejorar varios puntos. Me gustaría serializar cualquier tipo de mensaje, ahora solamente viajan enteros y strings. Me gustaría usar un solo archivo de configuración, en lugar de uno por máquina. Y poder tener en una sola solución, ambas implementaciones de hosting y transporte: DSS/CCR y WCF.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

CCR usado en mensajes asincrónicos

lopez — Fri, 19 Sep 2008 10:09:36 GMT

Leo en el blog de Arvindra Sehmi que la gente de Tyco Software House implementó un sistema donde usando CCR (Concurrent and Coordination Runtime), la librería que viene dentro de Microsoft Robotics. En su artículo ARCast.TV - Nice Example of CCR Adoption in the Enterprise muestra el video donde la gente de Tyco explica cómo consiguieron procesar gran cantidad de mensajes, basándose en envío asincrónico.

ARCast.TV - Stephen Tarmey of Tyco on adopting Robotics Studio CCR for High Performance Async IO

Me gustaría que mostraran algo más gráfico del sistema que armaron, pero igual es interesante escuchar a alquien que usa a Microsoft Robotics aplicado a la empresa.

Ya Arvindra había comentado usos de DSS/CCR más allá de Robotics en

DSS Use Cases in the Enterprise

Todavía algunos de esos usos no están publicados, pero espero que aparezcan más casos de éxito con el tiempo.

El año pasado escribí y publiqué un ejemplo AjMessages, con intercambio de mensajes asincrónicos, usando WCF como comunicación entre nodos de una grilla:

AjMessages- hacia un procesador de mensajes

También el año pasado escribí una versión para usar CCR internamente, y DSS como comunicación entre los nodos, pero no la publiqué. El núcleo del sistema se puede implantar en un host WCF o en un host DSS. Me gustaría en estos días, pulir un poco el código, y publicar el ejemplo, para ver que uno puede usar CCR internamente para encolar mensajes en memoria, y repartirlos en un pool de threads que maneja internamente CCR, mientras al mismo tiempo, repartimos mensajes en otros nodos de la grilla, si los hubiera, sin mayor problema, para conseguir escalabilidad usando más máquinas de forma transparente. Como ejemplo de uso, podría reescribir el Web Crawler o el programa de Fractal, que escribí directamente para DSS/CCR/VPL:

Agentes Distribuidos y Fractales usando DSS/VPL

Agentes Distribuidos usando DSS/VPL

Pero imaginen que pueden repartir una tarea entre varias máquinas, incluso remotas. Imaginen que pueden enviar una tarea a realizar (como recolectar información para un informe de Business Intelligence) a una sucursal, y otra tarea a máquinas de otra sucursal dentro de su empresa. Pueden recibir los resultados como mensajes, usando un patrón del tipo request-response. Podemos codificar "agentes" que se envíen mensajes entre sí, para colaborar en un objetivo.

Creo que el modelo de mensaje asincrónico junto con la implementación de grilla, puede ser explotado de muchas maneras. Mi idea es aprovechar mi semana sabática (que comienza mañana) para codificar algunos proyectos, y uno de ellos es una versión más terminada de AjMessages.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Recursos de Microsoft Robotics Developer Studio

lopez — Wed, 10 Sep 2008 13:17:43 GMT

En estos días, estuve dando varias charlas sobre Microsoft Robotics Developer Studio (MRDS), quisiera escribir acá sobre lo que presento en esas charlas, y enlaces a recursos del tema.

En primer lugar, pueden ver todo sobre el producto de Microsoft desde:

Microsoft Robotics

Ahí encontraran para bajarse el Microsoft Robotics Developer Studo 2008 (actualmente CTP July), y descargas adicionales.

La presentación original de la charla es la que dio Arvindra Sehmi en el Regional Architect Forum de México:

Mexico Regional Architect Forum 2008

En el blog de Arvindra, pueden encontrar información adicional sobre el uso de MRDS en la industria, más allá de robótica:

DSS Use Cases in the Enterprise

Mi presentación en español, la pueden bajar de my Skydrive:

Presentación de Microsoft Robotics (14 megas)

En la charla muestro algunas de las ideas y ejemplos de diseño, implementación y tecnologías usadas en MRDS:

Decentralized Software Services

Basado en principios de diseño de REST (Representational State Transfer), es la base que tiene MRDS para operar en forma distribuida de forma eficiente. Usa estándares de la industria, como HTTP para el envío y recepción de mensajes, XML y SOAP para el protocolo de transporte. Todo MRDS se basa en tener un host (servidor) de DSS (el DssHost) que levanta servicios. Los servicios son los elementos que nosotros programamos. Dentro del software viene ya servicios provistos, para manejar e interactuar con robots simulados y reales, y con cámaras, sensores, motores, y otros elementos, como ventanas y joysticks. Los servicios se comunican entre sí usando DSS. Podemos manejar uno o varios robots, desde una o varias máquinas. O podemos, como muestra la imagen, ver el estado de un servicio, como una cámara de video, apuntando en nuestro browser a la dirección donde se encuentra el servicio (puede ser nuestra máquina u otra máquina).

Concurrent and Coordination Runtime

Otra de las novedades del sistema, es una nueva librería que simplifica y potencia el uso de mensajes para comunicar distintas partes de nuestra aplicación. Podemos enviar un mensaje a un Port, y dentro de ese Port podemos programar cómo atendemos a ese mensaje. Toda la atención de los mensajes se maneja de una forma eficiente, usando múltiples hilos de ejecución, y un manejo interno nuevo de lo que se llama un pool de threads. Es interesante explorar las capacidades de CCR, que se puede usar como librería desde fuera de MSRS. Podemos armar sistemas compuestos de componentes que se envíen mensajes asincrónicos entre sí. Los componentes pueden residir todos en el mismo programa y máquina, o podemos usar DSS para que los mensajes viajen entre distintos servidores.

Visual Programming Language

Teniendo un servidor de servicios DSS, los servicios se pueden programar en el Visual Studio, o pueden coordinarse los servicios a usar, detallando los mensajes y su proceso, usando el Visual Programming Language, una forma de conectar esos servicios de forma visual. Usando un diseñador interactivo, arrastrando y soltando servicios, y conectando sus mensajes de salida y entrada, podemos modelar un programa, un nuevo servicio, que por ejemplo conecte nuestro joystick o ventana de control, con robots, dispositivos u otros servicios. Uno de los ejemplos que muestro, es cómo interactuar con un servicio de Text to Speech (texto a voz).

Simulation Environment

No necesitamos tener un robot físico para interactuar. MRDS nos brinda un entorno de simulación, para manejar entidades (poliedros, esferas, entidades complejas como mesas, paredes, robots).

El entorno de simulación es otro servicio más, que se levanta dentro de un host de DSS. Nuestros servicios pueden enviarle mensajes, como "crear suelo", "crear cielo", "crear sol", "agregar entidad esfera". Las entidades tienen características, que incluyen densidad, peso, cómo las afecta la gravedad.

Este entorno de simulación está basado en tres tecnologías, que se instalan (si no las tiene ya instaladas) con el MRDS: el DirectX 9, el Microsoft XNA (para el render de 3 dimensiones), y el AGEIA PhysX que simula la física del entorno. Estas tecnologías pueden ejecutarse basadas en software, o pueden aprovechar hardware especial que tenga instalada la máquina: tarjetas de video con soporte de 3D, o plaquetas de simulación física.

Como todo servicio, el entorno de simulación puede ejecutar en una máquina, y el resto de los servicios estar repartido en otros servidores de la red. Por ejemplo, pueden colocar varios robots en un entorno de simulación, y cada uno manejarlo desde una máquina dedicada.

Robochamps

Es un sitio donde aparece desafíos a resolver con MRDS, donde programadores de todo el mundo pueden participar resolviendo un problema. El primer concurso fue ganado por Dave Sprague, entusiasta de robótica de los EE.UU., y Jackson Matsuura, profesor de Brasil. En el Desafío Amazed compitieron participantes de 77 países. Ahora se abre el desafío Sumo donde dos robots, en un ring, tiene que maniobrar para echar al otro fuera de la arena.

Encontraran videos explacativos (en inglés) sobre las tecnologías que se usan en MRDS, así como ejemplos para bajarse.

Enlaces

En la charla menciono algunas implementaciones de gente de la comunidad, involucrada en robótica, y que usa MRDS.

Como el sistema puede ejecutarse en un Windows Compact Edition, se puede instalar en un dispositivo de Windows Mobile. Eso es lo que Brian Cross, con su:

http://www.wimobot.com/

WiMoBot es el Windows Mobile Robot. Usa un Windows Mobile 5.0 SmartPhone como el cerebro central de control. Cross lo ha extendido para poder ser manejado remotamente desde una PC usando MRDS. Hay una versión montada sobre el lego NXT en:

http://www.wimobot.com/AssemblyNxt.aspx

como el sistema operativo

Raúl Arrabales Moreno está trabajando desde hace tiempo, en Inteligencia Artificial y robótica. Pueden visitar su sitio de

http://www.conscious-robots.com/

Está trabajando con MRDS, del que destaca sus características de manejo de concurrencia, coordinación, mensajería asincrónica. Está usando MRDS son el robot Pioneer 3DX, uno de los robots reales y simulados soportados por el sistema. Encontraran ahí foros sobre robótica

http://www.conscious-robots.com/en/researchers-and-associations/discussion-forums/www.conscious-robots.com-f.html

como

PSYCHE-B Discussion Forum

PSYCHE-D Discussion Forum (Theoretical emphasis)

Language Mind and Consciousness

Conscious-Robots.com Forum for MSRS (English)

Conscious-Robots.com Forum for MSRS (Spanish) (muy recomendable, con abundante información, preguntas y respuestas de los participantes)

MSRS Official Forums

Robocup MSRS Challenge Maillist

Posts y ejemplos

Post que escribo sobre Robótica en general, a partir de:

Posts sobre Robótica

Algunos de los ejemplos que muestro en la charla:

Agentes Distribuidos y Fractales usando DSS/VPL
Agentes Distribuidos usando DSS/VPL
Intérprete tipo Lisp usando DSS y VPL
Ejemplo de Web Crawler usando DSS (Decentralized Software Services)
Scribble Distribuido con Microsoft Robotics Developer Studio y DSS
Algoritmos Genéticos con AjAgents y Concurrency and Coordination Runtime (CCR)

Más enlaces sobre estos temas en:

http://delicious.com/ajlopez/msrs
http://delicious.com/ajlopez/dss
http://delicious.com/ajlopez/ccr
http://delicious.com/ajlopez/robotics

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Charla gratuita de Microsoft Robotics

lopez — Fri, 18 Jul 2008 18:23:51 GMT

El lunes 28 de Julio daré una charla gratuita en el Club de Programadores, sobre Microsoft Robotics, acá en Buenos Aires.

La idea es presentar la herramienta y su modelo de programación. Visitaremos el entorno de simulación, el manejo de robots simulados (que pueden reemplazarse por robots reales), el Visual Programming Language, y las librerías Decentrilized Software Services (DSS), y Concurrent and Coordination Runtime (CCR).

Más informes e inscripción a esta charla gratuita en:

http://www.clubdeprogramadores.com/cursos/CursoMuestra.php?Id=458

Ya escribí algo sobre estos temas en este blog:

Robótica

Decentralized Software Services

Concurrency and Coordination Runtime

Presentaré algunos de los ejemplos que había usado en el último Microsoft Regional Architect Forum, en base a la presentación de Arvindra Sehmi, y otros ejemplos adicionales.

Todo sobre Microsoft Robotics Developer Studio, desde

http://www.microsoft.com/robotics

Concursos, desafíos, videos explicativos, desde el nuevo sitio de Robotics

http://www.robochamps.com/

Enlaces que he coleccionado sobre estos temas en:

http://del.icio.us/ajlopez/dss

http://del.icio.us/ajlopez/ccr

http://del.icio.us/ajlopez/robotics

http://del.icio.us/ajlopez/msrs

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Agentes Distribuidos y Fractales usando DSS/VPL

lopez — Mon, 23 Jun 2008 17:11:37 GMT

La semana pasada escribí una aplicación de base para agentes distribuidos usando DSS/VPL, agentes que intercambian mensajes arbitrarios e implementan un balanceo de carga rudimentario. Pueden leer los detalles en:

Agentes Distribuidos usando DSS/VPL
Distributed Agents using DSS/VPL

Ayer, extendí el ejemplo con un nuevo proyecto, Fractal:

Pueden bajarlo desde mi Skydrive.

Tiene dos DSS Service Components, uno es el Calculator: calcula un sector del fractal de Mandelbrot. El otro componente es el Renderer, que tiene un formulario para controlar y mostrar los resultados del cálculo. El mensaje que transporta la información del sector a calcular es:

    public class SectorInfo : MessagePayload
    {
        public double RealMinimum { get; set; }
        public double ImgMinimum { get; set; }
        public double Delta { get; set; }
        public int FromX { get; set; }
        public int FromY { get; set; }
        public int Width { get; set; }
        public int Height { get; set; }
        public int MaxIterations { get; set; }
        public int MaxValue { get; set; }
    }

Otra clase es el mensaje que retorna el cálculo:

    public class Sector : MessagePayload
    {
        public int FromX { get; set; }
        public int FromY { get; set; }
        public int Width { get; set; }
        public int Height { get; set; }
        public int[] Values { get; set; }
    }

El Calculator divide el sector a calcular, si lo considera demasiado grade. Podría calcularlo en un solo paso, pero me parece interesante esta solución, para repartir el trabajo entre varios nodos:

        private void Calculate(AgentMessage msg)
        {
            LogInfo("Entering Calculator with Action: " + msg.Action);
            SectorInfo sectorInfo = (SectorInfo) msg.Payload;
            LogInfo(String.Format("X {0} Y {1} Width {2} Height {3}", sectorInfo.FromX, sectorInfo.FromY, sectorInfo.Width, sectorInfo.Height));

            if (sectorInfo.Width > 100 && sectorInfo.Height > 100)
                SplitSector(sectorInfo);
            else
                CalculateSector(sectorInfo);
        }

Como en el ejemplo de la semana pasada, podemos ejecutar este ejemplo desde un diagrama VPL, que se llama FractalVpl1:

Acá hay un solo Renderer, y dos agentes Calculator. Si lanzamos este programa VPL, aparece una ventana. Esta es su apariencia (luego de presionar el botón Calculate):

Podemos arrastrar el mouse para seleccionar una nueva región, o usar los botones de Zoom In y Zoom Out. El botón de Reset vuelve a la posición y colores iniciales. El botón Reset Colors vuelve a los colores iniciales, que pueden ser cambiados al azar con el botón New Colors.

Hay otro programa VPL, llamado FractalVpl2, que puede ser usado para ejecutar el mismo ejemplo de forma distribuida. Tiene un diagrama con dos AgentHosts:

y dos nodos:

Debemos compilar el ejemplo VPL y pedir de ejecutar sus nodos en forma distribuida, usando el rundeployer.cmd (para más detalles, ver mi anterior post, mencionado al principio).

Estos son algunos de los gráficos que produce el sistema:

(Este post es una traducción del original en "Anglish":

Distributed Agents and Fractals using DSS/VPL

)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

Agentes Distribuidos usando DSS/VPL

lopez — Fri, 20 Jun 2008 10:44:33 GMT

En este post, exploraremos algunas ideas para implementar agentes distribuidos, aprovechando las capacidades que nos brindan Decentrilized Software Services (DSS) y el Visual Programming Language (VPL), includos en el Microsoft Robotics Developer Studio (estoy trabajando con la versión CTP 2.0, con VS 2008). Pueden bajarse el código desde mi Skydrive:

AjDssAgents-0.1.zip

En un anterior post:

Web Crawler example using DSS (Decentralized Software Services)
Ejemplo de Web Crawler usando DSS (Decentralized Software Services)

escribí algunos componentes DSS orquestados desde VPL, para implementar un web crawler. En ese ejemplo, hay un Dispatcher, un Resolver, un Downloader, y un Harvester. Pueden leer ahí el detalle de sus funciones.

Pero supongamos que ahora tenemos varias máquinas para poder ejecutar el proceso de web crawling. Queremos instalar y ejecutar varios Downloaders y Harvesters, en una grilla de máquinas, usando load balancing automático. El problema con la orquestación desde VPL es que no soporta conceptos como load balancing, por lo menos no directamente. Entonces, escribí este ejemplo donde los componentes se comunican entre sí, como agentes, usando mensajes especiales.

Un agente, en este ejemplo, es un DSS service component, capaz de recibir y procesar mensajes que les envían los otros agentes. Puede enviar mensajes a otros componentes. En vez de indicar a cuál agente va dirigido un mensaje, se especifica el tipo lógico de agente al que va destinado, por ejemplo "WebCrawler/Harvester".

Otro componente especializado, el AgentHost, se encargar de recibir esos mensajes a enviar, y los destina a un agente local o remoto, que corresponda al tipo lógico especificado.

La solución

La solución .NET tiene tres proyectos:

AjDssAgents contiene el contrato genérico de un agente, y sus tipos, y la implementación concreta del AgentHost.

DecrementAgent and WebCrawler son simples agentes a usar en el ejemplo. El web crawler implementado es similar al de mi anterior post, mencionado arriba.

El mensaje

Los agentes intercambian mensajes, objetos del tipo AgentMessage:


    [DataContract]
    public class AgentMessage
    {
        [DataMember]
        public string From { get; set; }

        [DataMember]
        public string To { get; set; }

        [DataMember]
        public string Action { get; set; }

        [DataMember]
        public object Payload { get; set; }
    }

El campo From indica el origen del mensaje (no estoy usando ese campo todavía) El campo To es la dirección física (dirección DSSP) del agente destino, o su tipo lógico. En el ejemplo de este post, solamente estoy usando los tipos lógicos. ¿Por qué usar un tipo lógico? Así, si un mensaje tiene como To el valor "WebCrawler/Dispatcher", será enviado a un agente que corresponda a ese tipo lógico.

¿Cómo un agente conoce cuáles otros agentes están siendo ejecutados, y cuáles son sus tipos lógicos? Pues bien, no lo sabe. El componente que mantiene esa información es el AgenHost local, único en cada DssHost activo. Cada agente envía sus mensajes salientes a su AgentHost local, y éste los reenvía a los agentes locales o remotos apropiados.

Los agentes

Cada agente es un DSS service component, con una dirección asignada cuando es creado. Durante el comienzo de su ejecucuón, el agente envía a su AgentHost local un mensaje DSS, indicando su dirección y su tipo lógico (p.ej. WebCrawler/Dispatcher). Esta es la forma por la que el AgentHost conoce los agentes que estan ejecutándose localmente, en su DssHost. Veamos el código de inicio de un agente Dispatcher del ejemplo WebCrawler:

        protected override void Start()
        {
            base.Start();
            // Add service specific initialization here.
            _state.AgentType = "WebCrawler/Dispatcher";

            host.NewNode newNode = new host.NewNode(new host.AgentInfo() { Address = this.ServiceInfo.Service, AgentType = _state.AgentType });
            _hostPort.Post(newNode);
        }

El tipo del agente es mantenido en su estado.

Este es un código típico, de un agente, en este caso un Dispatcher, mostrando el tratamiento de un mensaje entrante y la producción de mensajes salientes:

        [ServiceHandler(ServiceHandlerBehavior.Concurrent)]
        public IEnumerator<ITask> PostMessageHandler(generic.PostMessage postMessage)
        {
            if (postMessage.Body.Action.Equals("Dispatch"))
                Dispatch(postMessage.Body);
            else if (postMessage.Body.Action.Equals("Resolve"))
                Resolve(postMessage.Body);

            postMessage.ResponsePort.Post(DefaultSubmitResponseType.Instance);

            yield break;
        }

        private void Dispatch(AgentMessage msg)
        {
            LogInfo("Entering Dispatcher with Action: " + msg.Action);
            LogInfo("URL: " + msg.Payload);

            DownloadTarget target = new DownloadTarget();

            target.Uri = (string) msg.Payload;
            target.Depth = 1;

            AgentMessage postmsg = new AgentMessage() { Action = "Resolve", To = _state.AgentType, Payload = target };
            host.PostMessage post = new host.PostMessage(postmsg);
            _hostPort.Post(post);
        }

        private void Resolve(AgentMessage msg)
        {
            LogInfo("Entering Dispatcher with Action: " + msg.Action);
            DownloadTarget downloadtarget = (DownloadTarget)msg.Payload;

            LogInfo("URL: " + downloadtarget.Uri + ", Depth: " + downloadtarget.Depth);

            DownloadTarget target = ProcessUrl(downloadtarget);

            if (target != null) {
                AgentMessage agentmsg = new AgentMessage() { To = "WebCrawler/Downloader", Action="Download", Payload = downloadtarget };
                host.PostMessage postmsg = new host.PostMessage(agentmsg);
                _hostPort.Post(postmsg);
            }
        }

El AgentHost

Hay uno y sólo uno por DssHost en ejecución. El AgentHost recibe la información de los nuevos agentes que se crean (su dirección y tipo lógico), y mantiene esa información en su propio estado.

Recibe mensajes de sus agentes locales, y los reenvía a otros agentes locales o a un AgentHost remoto. En este último caso, serializa el contenido del mensaje en un string, usando serialización XML (no podemos enviar un objeto genérico, debido a limitaciones en el Proxy que usa DSS). Esta es la estructura de un mensaje remoto:

    [DataContract]
    public class RemoteAgentMessage
    {
        [DataMember]
        public string From { get; set; }

        [DataMember]
        public string To { get; set; }

        [DataMember]
        public string Action { get; set; }

        [DataMember]
        public string PayloadTypeName { get; set; }

        [DataMember]
        public string Payload { get; set; }
    }

Notemos que el mensaje remote tiene un string Payload, que es la serialización XML del contenido original, y también tiene su tipo calificado, así el host destino podrá deserializarlo a su tipo correspondiente al objeto original.

Un AgentHost soporta subscripciones. Otros AgentHosts pueden subscribirse a recibir información de sus nuevos agentes. En general, si tenemos tres máquinas, debemos susbcribir a los tres AgentHosts entre ellos, así tendrán toda la información de los agentes que se encuentre corriendo, en las distintas máquinas.

Un ejemplo de Web Crawler con VPL

El ejemplo WebCrawlerVpl2 en VPL contiene dos diagramas, el primero:

Hay un Dispatcher, dos Downloaders y dos agentes Harvesters. El Dispatcher lanza la URL inicial a procesar, y mantiene una lista de URLs ya procesadas. El Downloader obtiene el contenido de cada página en proceso. El Harvester examina el contenido y obtiene los nuevos links a procesar.

Notemos que hay dos AgentHosts, y ellos se relacionan por notificaciones para informar sus nuevos agentes al otro.

Todos estos agentes y componentes se distribuyen en dos nodos:

El nodo Windows ejecutará en localhost:50000/50001, y el nodo Windows0 usar localhost:50002/50003 como dirección. Podemos modificar estos parámetros, agregar más agentes y nodos, sin cambiar el código de la aplicación.

Para ejecutar la distribución en forma distribuida, debemos compilarlar usando Build -> Compile as a Service en el menú de VPL. Deberá cambiar las propiedades de VPL, ahora en el ejemplo están apuntando a directorios locales en mi máquina de desarrollo:

Al compilar, VPL mostrará su avance:

Luego de la compilación, ir a la consola de DOS de MRDS, cambiar al directorio bin y lanzar el comando rundeployer.cmd:

Yo ejecuto el deployer en mi máquina local. Uds. pueden ejecutar el ejemplo en otras máquinas remotas, iniciando el deployer en cada una de ellas.

Ahora, estamos listos para ejecutar el web crawler. Seleccionamos la opción Run -> Run on distributed nodes , y la aplicación comenzará a ejecutar. Un ventana de diálogo nos pedirár la URL inicial. La ingresamos, y el proceso comienza a recuperar las páginas de ese sitio. Pueden ver el estado del primer AgentHost (ejemplo) en:

http://localhost:50000/agenthost

Hay tres agentes locales y dos agentes remotos.

En el otro DssHost, hay otro AgentHost:

http://localhost:50002/agenthost0

Vemos la diferencia: aquí hay dos nodos locales y tres remotos.

Para ver el avance del proceso, pedir en el navegador

http://localhost:50000/console/output

Conclusiones

Con estas ideas, podemos implementar aplicaciones tipo grilla, ejecutándose en varios nodos físicos. Perdemos la orquestación de VPL, no podemos dibujar el camino de los mensajes. Pero ganamos en balanceo de carga y deploying dinámico. Con algo de esfuerzo adicional, podemos escribir un servicio que inicia e instale el sistema en una nueva máquina remota, en el medio de un proceso en ejecución. La serialización de objetos arbitrarios es posible, ahora está usando serialización XML, podemos cambiarla por serialización "custom" o binaria.

Podría agregar subscripción a mensajes, en una futura versión. Un agente podría recibir mensajes que no estaban destinados a él, especificando algún criterio de subscripción. Esos criterios se mantendrían en los AgentHosts. Cuando un AgentHost rutea un mensaje saliente, podría reenviar una copia del mismo a cualquier agente interesando, ya sea local o remoto.

Tienen la versión original de este post en "Anglish":

http://ajlopez.wordpress.com/2008/06/15/distributed-agents-using-dssvpl

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/en

Intérprete tipo Lisp usando DSS y VPL

lopez — Wed, 11 Jun 2008 14:22:24 GMT

Este fin de semana estuve programando algunas primitivas de un intérprete Lisp usando DSS Service Compoenntes. El núcleo del intérprete fue derivado de mi trabajo previo con AjLisp, un intérprete que todavía no publiqué. Escribí el ejemplo usando Visual Studio 2008 con el CTP v2.0 de Microsoft Robotics Developer Studio. El ejemplo está publicado en mi Skydrive como DssLisp.zip.

La solución

Consiste de dos proyectos: una librería de clases llamada AjLisp (una versión revisada de mi intérprete original en VB.NET):

y un proyecto C# de Dss Service, que tiene varios service components implementados:

No tiene manifiesto inicial. El proyecto está pensado para ser usado desde diagramas de Visual Programming Language (VPL).

Varios de estos componentes reciben y retornan una SymbolicExpression, el tipo base de mi intérprete. Veamos por ejemplo, los mensajes del componente Rest, que dada una lista devuelve la misma lista sin el primer elemento:

    [DataContract()]
    public class ExecuteRequest
    {
        [DataMember]
        public SymbolicExpression Expression;
    }

    [DataContract]
    public class ExecuteResponse
    {
        [DataMember]
        public SymbolicExpression Result;
    }

Para compilar estos componentes, deben ajustar las referencias y directorios del proyecto DSS (ahora apuntan a mis directorios locales y a mi instalación local de Microsoft Robotics Developer Studio).

Usando VPL

Hay tres programas VPL incluidso en los ejemplos. Usan los componentes compilados de la solución. Tuve un problema con estos programas VPL. No pude ejecutarlos desde la opción de Run. Hay que usar Build -> Compile as a Service, y ahora, lanzarlos con Run -> Run Compiled Services. Creo que el origen del problema es que al armar el diagrama estoy mapeando mensajes propios, no solamente tipos primitivos o Strings. Para recompilar los diagramas, tienen que ajustar las propiedades en cada proyecto VPL:

El primero, DssLispVpl1, calcula (first '(a b c)):

Hay dos componentes LispParser y LispToString, que ayudan a convertir de string a SymbolicExpression y viceversa.

El segundo diagrama es DssLispVpl2:

Usa el componente LispAppend para concatenar dos listas predefinidas como Data.

El tercero es un min intérprete DsspLispInterpreter:

Tengo que mejorar el tratamiento de errores. Ahora, si ocurre una excepción, no devuelve un Fault, y encontes se genera una causality, que hace que el programa se interrumpa.

Podría implementar contratos genéricos, y reusarlos en los componentes, por ejemplo, un contrato GenericBinaryOperation.

Problemas

Fallé completamente cuando quise escribir una Activity, para implementar una función Reverse de una lista. La actividad se llamaba a sí misma recursivamente, pero en el código generador retornaba desde la última invocación recursiva, sin pasar por las intermedias. El problema es causado porque en todo ese proceso se utiliza la misma instancia de actividad, y al retornar por una puerta el resultado, TODOS los procesos pendientes de esa actividad están escuchando por esa puerta (eso es lo que veo que pasa). Otra piedra en el camino es que las actividades solo aceptan valores primitivos o string como datos en el mensaje de entrada. Puedo solucionar el problema, generando el código de la actividad, levantando la solución, y cambiando los parámetros que trata de, digamos, string a SymbolicExpression.

Un componente interesante, es el componente Uncons, que retorna DOS expresiones simbólicas en su mensaje de respuesta: dada una lista, retorna su cabeza y su cola. Esos dos miembros de la respuesta pueden ser procesados luego en paralelo en dos ramas del diagrama.

Conclusiones

Como en otros posts y ejemplos, encontré la orquestación de componentes DSS via VPL como algo poderoso e interesante, pero le faltan algunas cosas, como el soporte de un objeto genérico o tipos nuestros. Creo que se puede implementar varias primitivas de lenguajes funcionales y usar a VPL para programar sobre ellas. VPL tendría problemas con la recursividad (o no encontré una forma aceptable de hacerla funcionar). Este ejercicio, podría expandirse a otras ideas:

- Manejar una pipeline/tubería para procesar un mensaje genérico (puedo usar un object como DataMember en un mensaje, siempre y cuando no lo envía a otro Host de DSS)
- Tener balanceo de carga
- Serializar/deserializar objetos entre hosts
- Implementar algún workflow o patrones de integración de aplicaciones usando VPL

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

Ejemplo de Web Crawler usando DSS (Decentralized Software Services)

lopez — Wed, 28 May 2008 18:18:54 GMT

Hace unas semanas, escribí una aplicación tipo Scribble distribuido usando DSS. A fin de la semana pasada, escribí otra aplicación, para aprender conceptos de DSS: una aplicación que visita y baja páginas web de un sitio, con servicios DSS coordinados desde Visual Programming Language (VPL). Hay un programa VPL adicional que lee una página web, usando un control Texto to Speech. Pueden bajarse el ejemplo desde mis carpetas en Skydrive:

DssWebCrawler2008May.zip

La solución

Está compuesta de tres proyectos: un assembly DSS, uno de librería de clases con algunos utilitarios para analizar contenido HTML, y una librería de clases para hacer testint del parser HTML. La librería de test usa NUnint: pueden removerla de la solución, si quieren, porque sólo es usada para testing, no para la solución final.

El assembly que usa DSS assembly se llama DssWebCrawler. Definí ahí 5 servicios DSS:

Dispatcher: Recibe una URL inicial para bajar, y la envía al Resolver.

Resolver: Este servicio mantiene una lista de URLs visitadas, y controla si las nuevas URLs a bajar son válidas, que pertenezcan al mismo dominio, y que no hayan sido ya procesadas. Está limitado por código a explorar hasta 3 niveles de enlaces.

Downloader: Este servicio lee el contenido de una URL. El contenido obtenido es parte del mensaje de respuesta.

Harvester: Examina el contenido recibido y recolecta nuevas URLs de los enlaces que encuentra dentro. Para cada uno de esos enlaces, envía una notificación a cualquier servicio interesado en esa información.

Reader: Usa el simple parser HTML que escribí para el proyecto. Puede obtener el título de una página, o el contenido, descartando tags de HTML y scripts.

The VPL Program

Hay un program VPL (Visual Programming Language), llamado VPLWebCrawler. Consiste en tres diagramas. El primero define el envío de la primer URL a bajar:

El segundo define el proceso de notificación de nuevas URLs encontradas por el componente Harvester:

El tercer diagrama es un "plus": procesa las notificaciones del Downloader, informando nuevo contenido, lo examina, y envía el título de la página bajada a un componente Text to Speech:

Para lanzar la aplicación, ir al menú Run -> Start . Aparece una ventana, pidiendo de ingresar la URL de la página para comenzar a "crawlear":

Comienza el proceso de "crawling":

Despues de algunos segundos, los títulos de las páginas bajadas son enviados al servicio Texto to Speech: escucharemos el proceso de cada página.

Leyendo páginas

En otro programa VPL, el VPLWebReader, podemos leer "en voz alta" el contenido de una página web, usando el componente Text to Speech:

Es interesante ver que estamos usando los mismos componentes que en el anterior ejemplo. Pero usando composición VPL, podemos usarlos para otros programas.

Pueden usarlo para leer mis experimentos en "Anglish" (Angel's English) apuntando a http://ajlopezen.zoomblog.com.

Conclusiones

Los componentes fueron escritos para ser usados desde orquestración de VPL. No tienen "partners", ni conexiones directas entre ellos. Esta es ua nueva manera de programar: definimos nuestros mensajes de entrada y de respuesta, y luego los usamos desde VPL. La posibilidad de usar notificaciones es algo interesante: se puede usar para usar la misma salida en diferentes componentes destinos.

Podemos jugar un poco más: pruebe de colocar algunos de estos componentes en otro nodo/máquina, usando las nuevas capacidades de "deployer" automático desde VPL.

Espero que encuentren este ejemplo útil: me divertí escribiéndolo, hay más aplicaciones que quisiera pasar a código usando estas tecnologías.

Gracias a Fernando Tubio, por sus ideas iniciales para implementar un web crawler.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

Presentando Microsoft Robotics en el Regional Architect Forum 2008

lopez — Tue, 27 May 2008 07:42:56 GMT

Hoy voy a presentar en el RAF 2008 del Cono Sur, en Pilar, Buenos Aires, conceptos y demos de Microsoft Robotics Developer Studio. Como la semana pasada, voy a usar como base una versión reducida de la presentación de Arvindra Sehmi:

A Data-Driven Approach to Distributed, Concurrent Software - ASEHMI - April 2008.pptx

Esta vez, la charla estará más centrada en las capacidades de armar aplicaciones distribuidas, y analizar el modelo de servicios que ofrece. Es un poco difícil explicar algunos de los conceptos claves sólo en 50 minutos, pero espero que pueda marcar que estas herramientas son para más allá de robótica.

Para más información sobre Microsoft Robotics, visitar:

http://www.microsoft.com/robotics

Ejemplos presentados por Arvindra Sehmi en su RAF México:

CCRBasics.rar

En estos días escribí un ejemplo de uso de DSS, para implementar un Web Crawler:

Web Crawler example using DSS (Decentralized Software Services)

Ya vendrá el post correspondiente en español.

Un ejemplo anterior:

Distributed Scribble with Microsoft Robotics Developer Studio and DSS

Varios de los ejemplos que presento, están incluidos en el propio producto. El año pasado estuve implementando AjMessages usando DSS/CCR, pero todavía no tengo algo publicado. Para un cliente, estoy desarrollando una aplicación distribuida, configurable, usando todas estas tecnologías, espero que quede publicada, para poder bloguear sobre el tema.

Para una detallada explicación de CCR, leer:

MSDN Mag - Concurrent Affairs - Concurrency and Coordination Runtime

Concursos, desafíos, videos explicativos, desde el nuevo sitio

http://www.robochamps.com/

He dejado enlaces sobre estos temas en:

http://del.icio.us/ajlopez/dss

http://del.icio.us/ajlopez/ccr

http://del.icio.us/ajlopez/robotics

http://del.icio.us/ajlopez/msrs

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Presentando Microsoft Robotics Developer Studio

lopez — Wed, 21 May 2008 03:54:30 GMT

Hoy voy a estar presentando esta tecnología en la Universidad Tecnológica Nacional, de La Plata, provincia de Buenos Aires. Página base en:

http://www.microsoft.com/robotics

Es una de las conferencias del

Congreso Nacional de Estudiantes de Ingeniería en Sistemas de Información

Mi conferencia es

Microsoft Robotics Studio

Uso una versión resumida de la presentación del bueno de Arvindra Sehmi, que pueden bajar completa de:

A Data-Driven Approach to Distributed, Concurrent Software - ASEHMI - April 2008.pptx

La idea es mostrar, en dos horas, las ideas principales en las que se basa:

- Decentralized Software Services

- Concurrent and Coordination Runtime

- Visual Programming Language

- Simulation Environment

- Robots simulados

- Soporte de la industria

Es muy fácil de instalar, y la última versión funciona y se maneja desde Visual Studio 2005 o 2008.

Más información sobre estas tecnologías en

http://www.robochamps.com

http://del.icio.us/ajlopez/robotics

http://del.icio.us/ajlopez/dss

http://del.icio.us/ajlopez/ccr

Tengo algunos ejemplos a publicar, con CCR y DSS. Ya vieron algunos en:

Genetic Algorithms with AjAgents and Concurrency and Coordination Runtime (CCR)

Distributed Scribble with Microsoft Robotics Developer Studio and DSS

Agents using Concurrency and Coordination Runtime (CCR)

Artículo introductorio a CCR en

Concurrent Affairs- Concurrency and Coordination Runtime

Espero repetir esta charla en otros lugares, como el MUG de Argentina o el Club de Programadores. La semana que viene doy una charla sobre el mismo tema, pero más orientada a aplicaciones distribuidas, en el Regional Architect Forum 2008 de Cono Sur. Algo más sobre grid computing en varios artículos:

http://msmvps.com/blogs/lopez/archive/tags/Grid+Computing/default.aspx

Todo lo de Microsoft Robotics Developer Studio se puede aplicar para eso.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Scribble Distribuido con Microsoft Robotics Developer Studio y DSS

lopez — Mon, 28 Apr 2008 09:58:51 GMT

Estuve jugando con el nuevo CTP release de Microsoft Robotics Developer Studio. Tiene nuevas características, como instalación y ejecución de un diagrama de Visual Programming Language en muchos nodos.

Para explorar algo de esta nueva funcionalidad, escribí el sueño de todo programador: un programa de dibujo distribuido multiusuario...;-)... Bueno, es uno bastante simple, pero funciona, y puede ejecutarse en varias máquinas, exponiendo y compartiendo nuestros más inspirados dibujos de mouse. El código puede ser descargado desde aquí.

El proyecto

Tengo la versión 1.5 del MSRS y el nuevo CTP MRDS (nueva sigla), ejecutándose en la misma máquina, sin mayores problemas. Comencé creando un nuevo proyecto del tipo Simple Dss Service RDS 2008:

El proyecto contiene un service component llamado DssScribble, y un Windows form, que está a cargo del dibujo:

Al comienzo del service component, crea el formulario, y lo connecta para usar los ports y su cola de dispatcher:

protected override void Start()
{
    base.Start();
    // Add service specific initialization here.
   WinFormsServicePort.Post(new RunForm(CreateForm));
}

private Form CreateForm()
{
    return new CanvasForm(_mainPort, linePort, TaskQueue);
}

Cada línea que el usuario dibuja en la ventana es enviada al service component, para ser distribuido a cada subscriptor interesado en el dato:

[ServiceHandler(ServiceHandlerBehavior.Exclusive)]
public IEnumerator<ITask> PostLineHandler(PostLine postLine)
{
    SendNotification<PostLine>(_submgrPort, postLine);

    yield break;
}

Las líneas son recibidas en el NewLineHandler (el modo de conectar dos componentes es via VPL, como veremos más adelante). El linePort es el port para comunicarse con la instancia del formulario:

[ServiceHandler(ServiceHandlerBehavior.Exclusive)]
public IEnumerator<ITask> NewLineHandler(NewLine newLine)
{
    linePort.Post(newLine.Body);

    newLine.ResponsePort.Post(DefaultUpdateResponseType.Instance);

    yield break;
}

El service component no tiene estado. Uso una clase para transportar la información de las nuevas líneas a dibujar y distribuir:

    [DataContract()]
    public class DssScribbleState
    {
    }

    [DataContract()]
    public class DssScribbleLine
    {
        [DataMember()]
        public int fromX;

        [DataMember()]
        public int fromY;

        [DataMember()]
        public int toX;

        [DataMember()]
        public int toY;

        public DssScribbleLine()
        {
        }

        public DssScribbleLine(int fromX, int fromY, int toX, int toY)
        {
            this.fromX = fromX;
            this.fromY = fromY;
            this.toX = toX;
            this.toY = toY;
        }
    }

Dibujando con VPL

El Visual Programming Language es una herramienta fascinante, lleno de "features". Se puede arrastrar y soltar services components desde la toolbar. Cuando esta herramienta es lanzada, se puede buscar el DssScribble service en el área inferior izquierda:

Arrastré dos instancias del DssScribble service component, y las renombre a DssScribble1 y DssScribble2:

Conecté las instancias, así pueden escuchar sus notificaciones. Cada línea producida en una instancia es transmitida a la otra. De esta manera, lo que dibujemos en una ventana, aparecerá en la otra.

La conexión es entre la notificación PostLine y la notificación NewLine:

Para lanzar la aplicación, ir al menú Run -> Start. Aparece una ventana, mostrando el log de mensajes:

Esperamos unos momentos, y dos instancias del componente DssScribble son creados, cada uno mostrando un formulario. Podemos dibujar en cualquiera de los dos, arrastrando el mouse, siendo reproducido el dibujo en el otro formulario:

Este es mi autorretrato: una lágrima se me escapa, de la emoción de un dibujo distribuido.... ;-)

Ejecutando en nodos distribuidos

La IDE del VPL IDE tiene un diseñador de nodo. A la derecha, hay una rama Node en el árbol del proyecto. Cada nodo representa un DSS host conteniendo servicios DSS. Agregué dos nodos, el primero conteniendo una instancia del Scribble y arrastré la segunda instancia al segundo nodo:

Noten el panel inferior derecho: definí ahí las propiedades para el nodo Windows0, en el mismo localhost, pero con otras puertas (el primer nodo correrá en las puertas 50000/50001). En otro proyecto, probé tener una máquina remota, y la aplicación distribuida funcionó sin problemas. Podemos definir varios nodos, cada uno en una máquina distintas, poner en ellos instancias de DssScribble, enlazarlas por notificaciones, y podemos dibujar con nuestro compañeros de trabajo.... ;-)

Para ejecutar la aplicación en forma distribuida, se debe compilarla. Usar el menú Build -> Compile as a Service . Debe ingresarse un directorio donde generar el código y la solución. Entonces, la herramienta VPL compila solución, y genera los paquetes de instalación. Se puede abrir la solución generada con Visual Studio (el código es muy interesante, bastante astuto, implementando, por lo que ví, una máquina de pila, ver los métodos Decrement, Increment).

Cada nodo debe tener corriendo un servicio llamado package deployer, que ejecuta en otra puerta (la misma para todos los nodos, el valor asumido es 55555). Ir a ejecutar el directorio bin de Microsoft Robotics Developer Studio, y ejecutar el rundeployer.cmd:

Nota: si queremos compilar el servicio de nuevo, debemos parar el deployer: el generador de código usa el directorio bin y trae conflictos con el deployer andando.

Ahora, estamos listos para distribuir nuestra "killer app": ejecutar Run -> Run on distributed nodes. El sistema avisa de tener los deployers ya andando:

Y la magia comienza: cada nodo es contactado, y la aplicación es instalada en ellos. Un nodo DSS es iniciado en cada nodo, y sus correspondientes instancias de servicios son creadas. En este ejemplo, tendremos dos nuevas ventanas de consola, ejecutando cada una un nodo DSS. Esta es la ventana de mi segundo nodo:

Ahora, cada noda muestra su ventana de dibujo, y la diversión comienza.... :-)

Notas

No estoy usando partners en este ejemplo. En cambio, uso notificaciones de eventos, en este caso, nuevas líneas, así otros componentes pueden recibir esas notificaciones. Podemos escribir otros componentes, otras ventanas de dibujo, para recibir y procesar las líneas. Una idea es usar las coordenadas de una nueva línea para controlar el motor de un robot, o para persistir las líneas producidas usando un componente de persistencia nuestro. Para controlar el motor de un robot, podemos usar VPL, sin necesidad de reescribir el componente original.

Conclusiones

Usando VPL podemos componer nuevas aplicaciones usando componentes ya existentes. Podemos crear nuestras propias actividades. Y usando diagramas de nodos (en VPL o usando el DSS Manifest Editor) con el packager deployer, podemos distribuir la aplicación en muchos físicos nodos, en cualquier manera que creamos conveniente. Pero debemos definir cada nodo y componente: no hay facilidades para programar una grilla, con nodos dinámicos. Una aplicacion gridificada para DSS puede ser escrita, pero en mi opinión, debe ser creada con código nuestro. Idea para explorar: escribir una aplicación de control, usando package deployer, instalara tareas en los nodos en una grilla.

Todas estas herramientas abrieron mi cabeza. Escribir DSS services components es una nueva forma de pensar y programar, algo que quise explorar por años: cómo escribir objetos con un proceso de mensajes de una vía, en una forma distribuida y paralala (AjAgents está motivado por esa objetivo). Me imagino un sistema que modele las ideas de Minsky sobre la mente humana.

Bueno, es un nuevo mundo. Dorothy: no estamos más en Kansas... ;-)

Angel "Java" Lopez
http://www.ajlopez.com

Algoritmos Genéticos con AjAgents y Concurrency and Coordination Runtime (CCR)

lopez — Sun, 13 Apr 2008 15:03:48 GMT

El año pasado había implementado un ejemplo con AjAgents usando CCR:

Agentes usando Concurrency and Coordination Runtime (CCR)
Agents using Concurrency and Coordination Runtime (CCR)

Escribí en mi blog en "anglish" (Angel's English) algunas ideas para explorar:

Agents in a Grid

Recordemos que Concurrency and Coordination Runtime es parte de Microsoft Robotics Studio, puede leer más sobre esta librería en

Concurrent Affairs: Concurrency and Coordination Runtime

y consultar mis enlaces de Delicious

http://del.icio.us/ajlopez/ccr
http://del.icio.us/ajlopez/msrs

En estos días, extendí mi ejemplo AjAgentsCCR-0.1.zip con dos nuevos proyectos. Uno de consola AjAgents.Genetic01, y otro de ventanas AjAgents.WinGenetic01:

La idea básica es ejecutar un algoritmo genético usando agentes, los elementos de AjAgents, que se envían mensajes usando ports de CCR. Cada agente procesa sus mensajes entrantes, y envía mensajes salientes a otros agentes, en paralelo. El problema que encaro es el clásico Travelling Salesman Problem. Leo en la Wikipedia:

If a salesman starts at point A, and if the distances between every pair of points are known, what is the shortest route which visits all points and returns to point A?

La ventana de ejemplo es sencilla:

La clase Genoma representa el viaje (una lista de Points y un valor de distancia total):

    class Genoma
    {
        public List<Point> travel = new List<Point>();
        public int value;
    }

    class Point
    {
        public int x;
        public int y;
    }

Al comenzar la ejecución, los agentes son creados y conectados:

            best = new BestSoFar();
            evaluator = new Evaluator();
            mutator = new Mutator();
            collector = new Collector();

            evaluator.Collector = collector;
            collector.Mutator = mutator;
            collector.Evaluator = evaluator;
            collector.BestSoFar = best;
            mutator.Evaluator = evaluator;

Un genoma inicial es creado:

            Genoma genoma = new Genoma();
            Random rnd = new Random();

            for (int k = 0; k<40; k++)
                {
                    Point pt = new Point();
                    pt.x = rnd.Next(12);
                    pt.y = rnd.Next(12);

                    genoma.travel.Add(pt);
                }

            genoma.value = evaluator.CalculateValue(genoma);

El agente BestSoFar dispara un evento. El formulario se registra como observador de ese evento, para refrescar el mejor viaje calculado y dibujarlo. El programa envía el genoma inicial generado al agente Mutator, varias veces, para generar la primeras poblaciones:

            best.NewBest += BestGenoma;

            for (int k = 0; k < 60; k++)
            {
                mutator.Post("Mutate", genoma);
            }

Noten el uso del método Post, básico en AjAgents. Cada agente implementa ese método, que invoca un método en el agente, usando una puerta de CCR para invocar el método final. El método es ejecutado entonces no en el momento, sino en forma "paralela", en un thread que maneja el pool de threads de CCR.

Un diagrama simple para explicar la interacción entre agentes:

El Mutator envía cada genoma al Evaluator. Este agente calcula el valor asignado a ese genoma. Lo envía a el Collector. Este implementa una nueva idea para este ejemplo: en vez de tener una clase Population o similar, el Collector recive genomas, y cuando tiene n o más genomas, determina los mejores del conjunto, envía el mejor a BestSoFar, y reenvía los mejores a Mutator, para generar una nueva lista de genomas a evaluar. Como método típico de ejemplo, tomemos uno de la clase Collector:

        void ProcessList(List<Genoma> list)
        {
            list.Sort(comparer);

            bestsofar.Post("Process",list[0]);

            evaluator.Post("Evaluate",list[0]);
            evaluator.Post("Evaluate",list[1]);

            for (int k = 0; k < 4; k++)
            {
                mutator.Post("Mutate",list[k]);
                mutator.Post("Mutate",list[k]);
            }
        }

Tengo que mejorar el algoritmo genético. Ahora, sólo usa mutación, sin hacer "crossover" (cruzamiento) entre los mejores genomas. El resultado que consigue ahora, no es óptimo: puede dar como resultado un máximo local, pero no la mejor solución. La idea del ejemplo es ver ejecutando AjAgents con CCR, en una prueba de concepto.

Conclusiones

Uno puede ver cada agente como una pequeña célula u organismo, que reacciona a mensajes externos y envía mensajes a otros agentes. Cada agente está levemente acoplado a los demás. En estos ejemplos, los agentes son creados y relaciones por código, pero bien podrían ser creados y relacionados usando algún framework de inyección de dependencias, como Spring.NET o el nuevo Unity Application Block de Microsoft.

En lugar de usar solamente ports de CCR, podría escribir los agentes como DSS Service components (ver Microsoft Robotics Studio para más información sobre DSS); el algoritmo podría ser distribuido en una grilla ("gridified") y cada agente interactuar con otros, independientemente de su ubicación..

Pero eso es otra historia....;-)

En esta semana, ha sido anunciada la nueva versión de Microsoft Robotics Developer Studio 2008:

http://blogs.msdn.com/msroboticsstudio/archive/2008/04/09/microsoft-robotics-developer-studio-2008-ctp-april-available.aspx

La tercera nueva característica ahí anunciada, sería muy interesante para implementar "miniagentes" distribuidos:

Support for creating applications that run on multiple DSS nodes using Visual Programming Language and DSS Manifest Editor. This makes it much simpler to create applications that run across nodes, either on the same machine or across the network. When an application containing multiple nodes is to be started, VPL creates individual deploy packages for each node and fires them up across the network.

(este artículo es la versión en español de mi versión "anglish":
Genetic Algorithms with AjAgents and Concurrency and Coordination Runtime (CCR)

)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Agentes usando Concurrency and Coordination Runtime (CCR)

lopez — Sat, 20 Oct 2007 00:24:29 GMT

En estos días, escribí un ejemplo mínimo, para explorar algunas ideas, usando el Concurrency and Coordination Runtime, la librería de Microsoft library que viene en su Robotics Studio. Más sobre CCR en el artículo:

Concurrent Affairs: Concurrency and Coordination Runtime

Mi idea es implementar el pase de mensajes entre componentes, de manera asincrónica. El código de ejemplo puede bajarse de AjAgentsCCR-0.1.zip

El agente

En el ejemplo, la interfaz a implementar por cada componente, que llamamos agente, es:

public delegate void ReturnHandler<T>(T t);

public interface IAgent
{
    void Post(Message msg);
    void Post(string action, 
        params object[] parameters);
    void Post<T>(string action, 
        ReturnHandler<T> handler, 
        params object[] parameters);
}

El agente puede recibir mensajes (que son objetos de una clase Message, ver más abajo). En el mensaje viene un texto con la Action a ejecutar (como si fuera un nombre de método) y una lista variable de parámetros.

El tercer método Post implementa un delegado, un método a ejecutar cuando el envío del mensaje produce una respuesta, un valor de retorno. Esa vuelta se produce en el futuro, no se queda esperando la respuesta. Podemos enviar un mensaje a otro agente, sin esperar la respuesta, o podemos escribir el delegado para procesar esa respuesta cuando llegue.

El mensaje

Es una clase con

action: un nombre que identifica la acción asociada al mensaje

body: el contenido del mensaje

response port: la puerta CCR donde enviar el valor de retorno, si es necesario

He aquí el código de esta clase:

public class Message
{
    private string action;

    public string Action
    {
        get { return action; }
        set { action = value; }
    }

    private object body;

    public object Body
    {
        get { return body; }
        set { body = value; }
    }

    private Port<object> returnport;

    internal Port<object> ReturnPort
    {
        get { return returnport; }
        set { returnport = value; }
    }
    

    public Message()
    {
    }

    public Message(string action)
    {
        this.action = action;
    }

    public Message(string action, object body)
    {
        this.action = action;
        this.body = body;
    }

    public Message(string action, object[] bodyvalues)
    {
        this.action = action;
        if (bodyvalues != null && bodyvalues.Length == 1)
            this.body = bodyvalues[0];
        else
            this.body = bodyvalues;
    }
}

Notemos que el mensaje tiene puede manejar un arreglo de valores en el body, y que puede enviar un objeto dentro de su contenido.

La implementación

En este ejemplo inicial, la interfaz IAgent tiene una implementación basado en Invoke, via Reflection, que termina invocando un método en el agente, que tiene el mismo nombre que la acción recibida. Se pueden pensar otras formas de manejar el mensaje, pero esta manera permite codificar el agente como una clase más, con métodos normales.

El mensaje, una vez recibido, se coloca en una puerta CCR, para que se pueda manejar de manera asincrónica. Hay un Receive arbiter de CCR para atender los mensajes entrantes, que son ruteados al correspondiente método en el objeto.

Creo que es una solución interesante: se puede escribir una clase con métodos normales, y convertirla en agente, heredando de la clase Agent.

Podemos enviar un mensaje con

agent1.Post("Decrement",20);

Puede "consultar" algún valor con:

agent1.Post<int>("GetCounter", PrintCounter);

Próximos pasos

Estoy trabajando en:

Escribir un Enviroment, o clase Host, donde los agentes "vivan". El Host sería responsable de mantener una lista de agentes por nombre.
Escribir un archivo de configuración donde pueda especificar qué agentes crear y cargar a comenzar a funcionar el Environment o Host, y que los relacione usando alguna implementación de inyección de dependencias. Me imagino servidores de agentes que pueda cargar un agente remoto de assemblies que se encuentren en otros servidores de la red.
Usar estos agentes en forma distribuida, con Windows Communication Foundation (WCF), o con Decentralized System Services (DSS). En este último caso, un servicio DSS podría ser un agente o podría representar la entrada a un Environment
Implementar algún patrón Subscribe/Notify entre agentes.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/