Desde el año pasado, y más en estas últimas semanas, he estado investigando sobre Grid Computing, buscando enlaces, recursos, "papers", implementaciones. Este post es el resultado de esa investigación.
Como siempre, un artículo de la Wikipedia:
http://en.wikipedia.org/wiki/Grid_computing
Si Ud. se está iniciando en el mundo de Grid Computing, estas son buenas introducciones
New to Grid Computing
Grid Computing according IBM
The anatomy of the grid
The physiology of the grid
Interesante lista de lecturas para desarrolladores en Grid
Recommended reading list for grid developers
Grid Café tiene varios artículos y recursos
Grid Cafe Grid Projects in the world
Grid Cafe The place for everybody to learn about the Grid
What is "the Grid"?
Grid @ CERN
Sobre el estado de la industria:
http://www.gridtoday.com/ (un poco demasiado abarcativo, no es sólo sobre grid computing)
http://www.gridblog.com/
La lista completa de enlaces que mantengo, en:
http://del.icio.us/ajlopez/gridcomputing
Algunos productos para examinar:
http://www.gridgain.com
http://www.digipede.net algo más sobre Digipede en http://dotnetjunkies.com/WebLog/stefandemetz/archive/2006/12/09/Free_Grid_Computing_software.aspx
http://www.gridgistics.net/
http://sourceforge.net/projects/ngrid/
Algo relacionado, que comienza a "estar de moda":
http://en.wikipedia.org/wiki/Cloud_computing
He escrito artículos en este blog sobre Grid Computing:
http://msmvps.com/blogs/lopez/archive/tags/Grid+Computing/default.aspx
y en "Anglish", Angel's English:
http://ajlopez.wordpress.com/category/grid-computing/
donde hay algunas implementaciones sencillas de ideas a seguir explorando, como AjAgents, y AjMessages.
Esta lista de recursos, en Anglish, desde:
Grid Computing Resources
Angel "Java" Lopez
http://www.ajlopez.com
El año pasado participé del desarrollo de una aplicación que se ejecuta en una grilla de máquinas sin disco. Este año, estoy volviendo a actualizar el proyecto, espero poder bloggear sobre el resultado dentro de un mes. Mientras, quisiera escribir sobre algunas ideas a explorar.
En este post, uso el término "agente", de una forma algo libre. No definiré precisamente el concepto, quiero usarlo como término base a refinar en el futuro (llegando en algún momento a tratar el tema de agentes autónomos, que me parece más interesante). Por ahora, exploremos algunas ideas básicas (¿ingenuas?) para entender mejor los problemas relacionados con agentes y aplicaciones en grid. Algunas de las ideas acá presentadas pueden ser vistas como ingenuas, pero siento que es un ejercicio necesario, para aprehender los conceptos clave y los problemas a ser resueltos en este tipo de aplicaciones. Al final de este post, presentaré algunas sugerencias de implementación.
He descripto algunas aplicaciones para ejecutar en una grid en mis anteriores post:
Grid Computing Programming
Más programando para una grid
Programando para una Grid
Conceptos de Agentes
En este post, un agente es una pieza de software, con conducta y estado. Se ejecuta en un host de agentes, una aplicación que provee los servicios de base para que el agente pueda "vivir" y trabajar. Representaremos al agente con esta figura:
Patrones de comunicación de agentes
Hay mucha literatura sobre comunicación de agentes, desde simples técnicas hasta elaborados contratos, negociaciones, y más. Podemos tener agentes con creencias, deseos e intenciones. En este post, un agente es más simple: sólo tiene estado, puede enviar y recibir mensajes. Puede recibir estímulos de otros agentes y desde el ambiente de su host.
El más simple patrón de comunicación es un agente enviando un mensaje a otro agente:
Algunas notas:
- El agente enviador conoce al agente receptor. Quiero decir, alguna forma de identidada debe ser implementada. El mensaje no es enviado a cualquiera: el que envía intenta enviar el mensaje a un determinado agente.
- El mensaje transporta datos, y debe ser entendido por el receptor, posiblemente procesado por uno de sus métodos de implementación.
- En enviador no espera por una respuesta. No está interesado en un mensaje de respuesta inmediato.
- Los agentes pueden residir en diferentes máquinas en la grila, y la comunicación se produce tanto local como remota.
Durante su vida un agente puede enviar muchos mensajes a distintos agentes, que debe conocer de alguna manera:
Algunas veces, el agente enviador recibirá un mensaje desde el agente receptor, notificando algun trabajo hecho, o enviando algún dato procesado. Dependiendo de la aplicación, el mensaje de respuesta podría acarrear información para identificar al mensaje original:
En este caso, el enviador original debe estar preparado para recibir la respuesta de una manera asincrónica. Esto podría ser un interesante problema a resolver: un agente puede enviar varios mensajes, y sería mejora si puede seguir ejecutando sin recibir todas las respuestas a tiempo. Por ejemplo, en una aplicación de un juego de tablero, un agente puede delegar la exploración de un árbol de jugadas a otros agentes, y, luedo de un tiempo, sería posible tomar una decisión, con sólo algunas respuestas recibidas.
Nubes ("clouds") en el cielo de la grilla
Otro caso: un agente puede estar interesado en enviar un mensaje, pero no a un receptor determinado. Al contrario, quiere enviarlo a una "nube" de agentes, así cualquiera interesado en el mensaje tendría la oportunidad de procesarlo.
Esta característica puede ser implementada usando estas estrategias:
- Un agente envía un mensaje a un sistema de pizarra (blackboard), que otros agentes están vigilando.
- Una agente enviaría una mensaje a la aplicación host, indicando un tópico (como en una cola de mensajes), así cualquier agente subscripto recibirá el mensaje. Una variante: sólo algunos subscriptores reciben el mensaje, dependiendo de parámetros de aplicación.
- Un agente podría enviar un mensaje dirigido a alguna definición de proveedor de servicio. Un proveedor de servicio es un agente, que declara al comienzo de su vida, sus capacidades y los servicios que puede proveer.
Un ejemplo, tomemos una aplicación de un juego de tablero, ajedrez o go. Un agente en esa aplicación puede enviar un mensaje reclamando resolver cierta posición de ataque. En un sistema de pizarra, publicará el pedido. En un sistema de tópicos, lo enviaría al tópico "ataques". En una estrategia de proveedor de servicio, envía el mensaje a uno o más de los proveedores del servicio AttackResolver.
Como en el patrón anterior, un agente puede recibir una respuesta asincrónica, ahora desde "la nube":
Duplicación de agentes
Un agente tiene conducta y estado. Si el agente puede dividir su trabajo, podría tomar el camino de duplicarse a sí mismo:
Es algo extraño, pero podría ser útil, dependiendo de la aplicación a desarrollar.
Agentes y la Grilla
Cada agente puede ser albergado en un nodo de la grilla. El mecanismo de envío de mensajes debe ser capaz de enviar un mensaje a otro nodo. La aplicación host mantiene una lista de agentes por identidad, y conoce cúal es local o remoto. Una prueba ácida: una aplicación de grilla con agentes debe ser capaz de correr en una sola máquina, o en una grilla, sin cambiar el código o el algoritmo.
Como en otras implementaciones de grilla (discutidos en los post que mencioné al principio), un servidor central está a cargo de la distribución de las tareas entre los nodos de la grilla. "Grid as a Service" es una nueva frase que podemos aplicar a esta situación.
Moviendo al Agente
Un agente puede iniciar sus actividades en un node. Pero en algún momento, puede decidir de continuar su trabajo en otro nodo (la aplicación host que lo alberga también puede tomar esa decisión, independientemente del agente). Entonces, su estado sería enviado de un nodo a otro (otro caso: podría querer duplicarse y que su clon siga el trabajo en otra máquina).
Noten que la conducta del agente (que puede estar compilada o puede estar escrita en un lenguaje dinámico o de agente), no viaja. Pero bien podría ser que viaje, incluso, que haya agentes que vayan adaptando su conducta en el tiempo.
Inyectando conducta
La conducta de cada agente podría ser expresada en código compilado (archivos .jar en Java, assemblies en .NET). Otras alternativas son posibles: la conducta podría ser especificada en un lenguaje de scripting dedicado a agentes (pienso en una adaptación del AjBasic, por ejemplo).
Si la conducta se expresa en forma compilada, uno o varios servers puede tomar la responsabilidad de almacenar y distribuir esos componentes:
Ideas de implementación
Muchas de estas ideas pueden ser implementadas en cualquier lenguaje/tecnología apropiada, como Java y .NET, que soporte múltiples threads, invocación remota, serialización de mensajes, etc...
En los últimos tiempos estuve trabajando en mis projectos AjMessages y AjAgents, más información enestos post:
AjMessages: a message processor
Agents using Concurrency and Coordination Runtime (CCR)
AjMessages- hacia un procesador de mensajes
Agentes usando Concurrency and Coordination Runtime (CCR)
Algoritmos Genéticos con AjAgents y Concurrency and Coordination Runtime (CCR)
Genetic Algorithms with AjAgents and Concurrency and Coordination Runtime (CCR)
(Tengo otro proyecto, AjGrid, no publicado aún). Para este post, creo que el AjAgents podría ser una implementación de esas ideas. AjMessages tiene ahora soporte de ejecución remota, pero está más orientado a un proceso tubería ("pipeline"): es más difícil de implementar en semejante sistemas las ideas de este post.
Estoy agregando algunas características a AjAgents (ahora, AjAgents trabaja sólo en local):
- Configuración: Carga y creación de agentes en ejecución, según alguna información de configuración, ya sea al inicio o en el medio de la ejecución.
- Assembly remoto: Así un nodo de grilla pueder ser inyectado con nuevos agentes.
- Identificación de Agente: Para identificar al agente de manera única (un UID debería bastar).
- Transporte de mensaje: Windows Communication Foundation es un candidato, otro podría ser DSSP.
Un posible camino es tomar Decentralized System Services (DSS) del Microsoft Robotics Developer Studio. Un agente podría ser implementado como un servicio de DSS, ejecutando en un host DSS. La comunicación entre máquinas puede ser implementada usando DSSP como protocolo.
"Stay tuned", vendrá más código.
(Esta es una actualización y traducción de mi post en "Anglish", Angel's English:
Agents in a Grid
)
Angel "Java" Lopez
http://www.ajlopez.com/en
La tecnología Component Object Model (COM) de Microsoft hace años que prácticamente no la uso, más que de forma escondida. En la situación actual de .NET y otras herramientas, no parece hacer falta más. Pero como por una década a todos nos enseñaron sobre componentes COM distribuidos, y stateless y stateful, y transacciones requeridas, y esas cosas (como Apartment Threading Model, algo que sólo existe en el universo donde un runtime de Visual Basic no es reentrante), creo interesante poner algunos puntos de la situación actual. No soy un experto en todo COM, pero recuerdo haber devorado su implementación, y la curiosa IUnknown, que fue una solución pragmática a la diversidad de lenguajes, a la resolución de binding en runtime, y la necesidad de comunicar programas:
- COM Surge de OLE, y éste de DDE, que a su vez nacen de Office y el embebido de documentos en otros documentos, para tener componentes que binariamente, sin dependencia de lenguaje y de otros temas, se puedan comunicar entre si, como cajas negras, mediante una interfaz bien definida, o descubrible en runtime.
- Aparecen componentes COM visibles, luego llamados ActiveX Controls, que cumplen una serie de interfaces para poder ser albergados en cualquier contenedor de ActiveX controls, como el Visual Basic clásico.
- Aparecio COM distribuido, con los conceptos de tener marcados los metodos o componentes, para manejar transacciones (Required, Required New....) Habrán visto aparecer también esos conceptos en J2EE y otros lados, en los noventa del siglo pasado.
- Pero la realidad, es que hoy por hoy, todo se puede hacer sin COM, incluso el manejo de transacciones. En .NET 1.x dependiamos de System.Enterprise (no recuerdo el namespace) que interactuaba con COM, pero con .NET 2, practicamente no se necesita COM (nada más en lo de más abajo, sin verlo directamente).
- Los componentes visuales ahora son .NET, y hay varias empresas que migraron sus ActiveX controls a .NET "puro", desde hace años.
- El manejo de transacciones ahora esta en System.Transaction (muy interesante que haya transacciones en objetos, y que tus objetos puedan tener un "rollback")
- El manejo de threads es hermoso en .NET .... a la Java... ;-)
- El manejo de comunicacion distribuida, con seguridad y demas, esta en manos de Windows Communication Foundation, o por lo menos, con Web Services o Remoting (este ultimo se le esta "soltando la mano" de parte de MS, todo esta puesto en WCF).
- La necesidad de registrar el componente en el Registry, y solamente una versión del componente, ha conseguido crear el infierno de las DLL (DLL Hell), que en .NET es prácticamente inexistente.
Asi que, de alguna manera, COM no es indispensable. Puedo hacer todo lo de COM con esto que fue apareciendo con el tiempo.
Aunque se recomienda tomar con pinzas lo que aparece en Wikipedia, leemos ahí sobre COM:
The COM platform has largely been superseded by the Microsoft .NET initiative, and Microsoft now focuses its marketing efforts on .NET. COM was often used to hook up complex, high performance code to front end code implemented in Visual Basic or ASP.
To some extent, COM is now deprecated in favor of .NET. Since .NET provides rapid development tools similar to Visual Basic for both Windows Forms and Web Forms with just-in-time compilation, back-end code can be implemented in any .NET Language including C#, Visual Basic and C++.
Le dan algo de esperanza:
Despite this, COM remains a viable technology with an important software base. As of this writing, Microsoft has no plans for discontinuing either COM or support for COM. It is also ideal for script control of applications such as Office or Internet Explorer since it provides an interface for calling COM object methods from a script rather than requiring knowing the API at compile time. The GUID system developed for COM has wide uses any time a unique ID is needed.
Información sobre COM en Microsoft:
http://www.microsoft.com/com/default.mspx
Seguiremos teniendo COM en varios programas de Microsoft, pero no parece haber necesidad de incorporarlos en nuestros propios desarrollos.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
En enero, me vi sorprendido por una implementación de grid computing en el browser, leer
Grid Computing in the browser
En estos últimos años hemos asistido al crecimiento de potencia y uso de JavaScript, con nuevas librerias y el uso intensivo de sus capacidades de prototipos y redefinición de funciones. Eso y otros elementos (como el XMLHttpRequest) han hecho surgir lo que se ha llamado Ajax. También tenemos librerías que convierten código en el servidor en código en el cliente, tengo que estudiar Volta de Microsoft, por ejemplo.
Esta semana, gracias a la lista de ClubSmalltalk me entero del estado del proyecto de Diego Gomez Deck (a quien creo recordad de las reuniones de SUGAR, Smalltalk User Group de Argentina, en los noventa): el Smalltalk Web Toolkit, pueden ver el blog del proyecto:
http://ceibo.wordpress.com/
Copio la descripción que enviara Hernan G, a esa lista:
¿Cuáles son las cualidades de este nuevo framework?
SWT rompe con la asimetría del protocolo HTTP, es decir, a través del hack Comet, ahora el servidor puede enviar contenido a los clientes conectados. Esto hace que se quiebre la barrera impuesta por el protocolo HTTP y el servidor no solamente pueda enviar contenido solo con un pedido del cliente, sino que a través de esto, en cualquier evento que se produzca en el servidor pueden ser informados los clientes (o los navegadores).
¿Cuál es su arquitectura?
SWT consta de una parte cliente y una servidora. Es decir, el comportamiento del cliente lo desarrollamos íntegramente sobre Smalltalk. Gracias a un framework que traduce de Smalltalk a Javascript contamos con un mini-ambiente Smalltalk del lado del navegador. A partir de este esquema, se puede contar con un MVC (Model-View-Controller) distribuido. Este MVC logra ciertas optimizaciones para presevar el recurso más limitado, la red.
¿De donde obtengo más información?
En el blog ceibo.wordpress.com podrán encontrar información de cómo usarlo, ejemplos, links a downloads, tutoriales, etc.
Ceibo es un proyecto de barajas 3D sobre la web que usará SWT como arquitectura.
Interesante lo de Comet:
http://es.wikipedia.org/wiki/Comet
Comet es una técnica de programación Web muy similar a AJAX, que utiliza XMLHttpRequest, se utiliza para la entrega de datos entre cliente servidor a través del protocolo HTTP, y la entrega de datos se hace sin que el cliente lo haya solicitado.
Comet también es conocido como server push, HTTP push, HTTP streaming, Pushlets, Reverse Ajax, y otros.
Jeje... de nuevo el XMLHttpRequest... grande el chiquitín.... :-)
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
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
Esta semana pasado, el gigante de Redmond anunció su nueva creación, Live Mesh (tech preview):
https://www.mesh.com/Welcome/Welcome.aspx
Gracias al post de Arvindra Sehmi:
http://blogs.msdn.com/asehmi/archive/2008/04/24/introducing-live-mesh.aspx
tenemos ahí una lista de comentarios sobre el nuevo bebé Microsoft. Esta nuevo producto de Redmond no es fácil de describir brevemente, pero merece que se le preste atención. Es una incursión de Microsoft en Web 2.0 y en su propia creación, Software plus Service.
(para bloggers, noten el uso de enlaces con screenshots, buena idea Arvindra!)
Este video explica la arquitectura a alto nivel (gracias a Matias Woloski por este link)
http://channel9.msdn.com/Showpost.aspx?postid=399577
In la lista de artículos de Arvindra, encuentro esta introducción de la inefable Mary Jo Foley
Ten things to know about Microsoft's Live Mesh
Leamos el punto uno:
1. The definition. As has become the norm with so many of its Software + Services products and strategies, Microsoft isn’t the best at coming up with a succinct Live Mesh definition. The closest I found (in a Live Mesh reviewer’s guide) was this: “Live Mesh is a ’software-plus-services’ platform and experience from Microsoft that enables PCs and other devices to ‘come alive’ by making them aware of each other through the Internet, enabling individuals and organizations to manage, access, and share their files and applications seamlessly on the Web and across their world of devices.” If I were in charge of defining Live Mesh, I think I’d go with “a Software + Services platform for synchronization and collaboration.”
Acá detecto algunas ideas de Bill Joy para Jini, una tecnología que nació demasiado temprano:
The Jini Technology Vision
Jini technology redefines the concept of a client. Instead of a fixed set of "local" devices, Jini technology supplies the Java client with a federation of remote "plug and play" devices in a dynamic configuration (the Jini Federation) that is personalized for each client. With Jini technology, the network truly becomes the client computer!
Toda esta nueva movida de MS podría ser el resultado visible de algunas ideas de Ray Ozzie, expresadas hace años en el notable memo:
The Internet Services Disruption
Supongo que Microsoft se está moviendo más y más hacia (recordemos el asunto Yahoo). Es una compañía que adopta la frase de Andy Grove: solo los paranoicos sobreviven. Tienen apuesta en RIA (Rich Internet Applications), Silverlight, Web 2.0, Rich Client... Todos los números de la ruleta están cubiertos, aún el doble cero... ;-)
Una nota: me asombra, que después de todo este esfuerzo, Microsoft todavía siga revelando nuevas herramientas solamente pare residentes de EE.UU. Google, por el contrario, pone sus innovaciones a disposición del mundo, sean betas o lo que sea. Toc, toc, McFly.... algún MS VP leyendo esto? ;-)
Angel "EverMeshed" Lopez
http://www.ajlopez.com
El domingo pasado, el bueno de Arvindra Sehmi referenció en un post suyo a un trabajo mío sobre una killer application que escribí: un scribble distribuido :-) Pero luego también escribió sobre este robot:
Es de Boston Dynamics, according to Wikipedia:
http://www.bostondynamics.com/
http://en.wikipedia.org/wiki/Boston_Dynamics
Boston Dynamics is a small engineering and robotics design company best known for the development of BigDog, a quadruped robot designed for the U.S. military with funding from DARPA [1], and DI-Guy, COTS software for realistic human simulation. Early in the company's history, it worked with the American Systems Corporation under a contract from the Naval Air Warfare Center Training Systems Division (NAWCTSD) to replace naval training videos for aircraft launch operations with interactive 3D computer simulations featuring DI-Guy characters. [2]
Marc Raibert is the company's president and project manager. He spun the company off from the Massachusetts Institute of Technology in 1992.[3]
Que bien resuelto está el tema de caminar y mantener el equilibrio y balance en distintas situaciones, y hasta hacer algún galope. Es notable que se haya logrado un algoritmo que implemente esa conducta. Según el bueno de Leandro Boffi (que además de mago se dedica a la robótica), eso se llama equilibrio dinámico.
Bueno, dejo algunos enlaces en
http://del.icio.us/ajlopez/robotics (últimamente, muy orientado a Microsoft Robotics Developer Studio)
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
En estos días, estuve investigando algo sobre grid computing y Microsoft Robotics Studio, usando DSS y CCR. Encontré un interesante documento:
High Performance Multi-Paradigm Messaging Runtime Integrating Grids and Multicore Systems
Los autores son Xiaohong Qiu, Geoffrey C. Fox, Huapeng Yuan, Seung-Hee Bae, de la Indiana University de Bloomington, y George Chrysanthakopoulos, Henrik Frystyk Nielsen, de Microsoft Research. Nielsen y Chrysanthakopoulos son los "creadores" del Concurrency and Coordination Runtime (CCR) y de Decentralized Software Services (DSS), tecnologías que son pilares de Microsoft Robotics Studio, y que pueden ser usandas más allá de robótica. Más información sobre estas tecnologías en:
http://www.microsoft.com/robotics
El "abstract" del documento dice:
eScience applications need to use distributed Grid environments where each component is an individual or cluster of multicore machines. These are expected to have 64-128 cores 5 years from now and need to support scalable parallelism. Users will want to compose heterogeneous components into single jobs and run seamlessly in both distributed fashion and on a future “Grid on a chip” with different subsets of cores supporting individual components. We support this with a simple programming model made up of two layers supporting traditional parallel and Grid programming paradigms (workflow) respectively. We examine for a parallel clustering application, the Concurrency and Coordination Runtime CCR from Microsoft as a multi-paradigm runtime that integrates the two layers. Our work uses managed code (C#) and for AMD and Intel processors shows around a factor of 5 better performance than Java. CCR has MPI pattern and dynamic threading latencies of a few microseconds that are competitive with the performance of standard MPI for C.
¿Que es MPI? Son las siglas de Message Passing Interface. Según la Wikipedia:
Message Passing Interface (MPI) is both a computer specification and is an implementation that allows many computers to communicate with one another. It is used in computer clusters.
Hay una There is a implementación de Microsoft:
Microsoft Message Passing Interface (MS MPI) is an implementation of the MPI2 specification by Microsoft for use in Windows Compute Cluster Server to interconnect and communicate (via messages) between High performance computing nodes. It is mostly compatible with the MPICH2 reference implementation, with some exceptions for job launch and management. MS MPI includes bindings for C and FORTRAN languages. It supports using the Microsoft Visual Studio for debugging purposes.
Gua! FORTRAN..... Esos buenos viejos días! ;-). Recuerdo haber trabajado con la implementación de Lisp en Fortran del bueno de Gregory Chaitin, en el siglo pasado. Pero no hay vuelta atrás, parafraseando a David Hilbert: Nadie nos expulsará del paraiso que Java y .NET han creado para nosotros.... ;-). Pueden leer la cita original en este interesante thread.
Pero estoy divagando. Volvamos al tema.
Los principales sitios sobre MPI son:
http://www.mpi-forum.org/
http://www.open-mpi.org/
http://www.lam-mpi.org/
Yo estaba pensando en implementar algo de las ideas de MPI en .NET o Java, cuando encuentro:
http://www.purempi.net/
PureMpi.NET is a completely managed implementation of the message passing interface. The object-oriented API is simple, and easy to use for parallel programming. It has been developed based on the latest .NET technologies, including Windows Communication Foundation (WCF). This allows you to declaratively specify the binding and endpoint configuration for your environment, and performance needs. When using the SDK, a programmer will definitely see the MPI'ness of the interfaces come through, and will enjoy taking full advantage of .NET features - including generics, delegates, asynchronous results, exception handling, and extensibility points.
PureMpi.NET allows you to create high performance production quality parallel systems, with all the benefits of in .NET
Es una implementación lista para bajar y usar, con VS 2005 o VS 2008. Usa generics para implementar canales tipados en MPI.
Me bajé la librería, y la instalé en una máquina con Visual Studio 2008. El programa de instalación agregó un nuevo template de proyecto, Mpi.NET:
Cree un proyecto, que aparece:
Modifiqué el Program.cs a:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Mpi;
namespace Mpi.NET1
{
class Program
{
static void Main(string[] args)
{
ProcessorGroup.Process("MPIEnvironment",
delegate(IDictionary<string, Comm> comms)
{
Comm comm = comms["MPI_COMM_WORLD"];
Console.WriteLine(comm.Rank);
IAsyncResult result =
comm.BeginSend<string>(0, "", "Rank: " + comm.Rank, TimeSpan.FromSeconds(30), null, null);
if (comm.Rank == 0)
{
for (int i = 0; i < comm.Size; i++)
{
string receivedMsg =
comm.Receive<string>(i, Constants.AnyTag, TimeSpan.FromSeconds(30));
Console.WriteLine(receivedMsg);
}
}
comm.EndSend<string>(result);
});
}
}
}
La clase ProcessGroup se encarga de los procesos a ejecutar. Notar el uso de delegados para especificar el proceso. Un proceso MPI recibe un diccionario de objetos Comm, que son los canales para comunicarse con otros procesos MPI.
La clase ProcessGroup tiene esta estructura (según la información de metadata):
namespace Mpi
{
public class ProcessorGroup : IDisposable
{
public ProcessorGroup(Environment environment, Processor processor);
public ProcessorGroup(string environment, Processor processor);
public Environment Environment { get; }
public ICollection<IAsyncResult> Results { get; }
public void Dispose();
protected virtual void Dispose(bool disposing);
public static void Process(string environmentConfigName, Processor processor);
public void Start();
public void WaitForCompletion();
}
}
El número y configuración de procesadores puede ser definida en el archivo App.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="Mpi" type="Mpi.ConfigurationSection, Mpi"/>
</configSections>
<Mpi>
<Environments>
<Environment name="MPIEnvironment">
<Hosts>
<Host comms="MPI_COMM_WORLD"
client="MpiClient1"
service="MpiService1" />
<Host comms="MPI_COMM_WORLD"
client="MpiClient2"
service="MpiService2"/>
<Host comms="MPI_COMM_WORLD"
client="MpiClient3"
service="MpiService3"/>
</Hosts>
</Environment>
</Environments>
</Mpi>
<system.serviceModel>
<client>
<endpoint address="net.tcp://localhost:8080/MpiService" binding="netTcpBinding"
bindingConfiguration="" contract="Mpi.IMpiService" name="MpiClient1">
<identity>
<userPrincipalName value="" />
</identity>
</endpoint>
<endpoint address="net.tcp://localhost:8081/MpiService" binding="netTcpBinding"
bindingConfiguration="" contract="Mpi.IMpiService" name="MpiClient2">
<identity>
<userPrincipalName value="" />
</identity>
</endpoint>
<endpoint address="net.tcp://localhost:8082/MpiService" binding="netTcpBinding"
bindingConfiguration="" contract="Mpi.IMpiService" name="MpiClient3">
<identity>
<userPrincipalName value="" />
</identity>
</endpoint>
</client>
<behaviors>
<serviceBehaviors>
<behavior name="MpiServiceBehavior">
<serviceDebug httpHelpPageEnabled="false" httpsHelpPageEnabled="false"
includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MpiServiceBehavior" name="MpiService1">
<endpoint address="net.tcp://localhost:8080/MpiService" binding="netTcpBinding"
bindingConfiguration="" name="MpiServiceEndpoint" contract="Mpi.IMpiService" />
</service>
<service behaviorConfiguration="MpiServiceBehavior" name="MpiService2">
<endpoint address="net.tcp://localhost:8081/MpiService" binding="netTcpBinding"
bindingConfiguration="" name="MpiServiceEndpoint" contract="Mpi.IMpiService" />
</service>
<service behaviorConfiguration="MpiServiceBehavior" name="MpiService3">
<endpoint address="net.tcp://localhost:8082/MpiService" binding="netTcpBinding"
bindingConfiguration="" name="MpiServiceEndpoint" contract="Mpi.IMpiService" />
</service>
</services>
</system.serviceModel>
<system.runtime.serialization>
<dataContractSerializer>
<declaredTypes>
</declaredTypes>
</dataContractSerializer>
</system.runtime.serialization>
</configuration>
Jeje, usan <host..>... Me recuerda a AjMessages... ;-)
La ejecución de programa produce:
Bueno, no vamos a decir "Huy, que bruto que programa", pero es mi primer programa MPI. Hay 3 "ranks", porque así esta configurado en el archivo de arriba.
Encontran varios ejemplos ejecutables en la distribución de Pure MPI.NET. En mi opinión, es una interesante implementación de ideas de MPI, con algunas vueltas de tuerca adaptadas al mundo .NET: generics y delegates , bienvenidos.
¿Grid y MPI? Puede ser. Tengo que estudiar las referencias mencionadas en el "paper" que nombré al principio. Aunque ese trabajo está dedicado a cuestiones de alto rendimiento, tiene un buen resumen conceptual de los modelos de ejecución, y las relaciones posibles entre MPI, CCR, y DSS.
(Había publicado este artículo en "anglish", Angel's English, en:
Message Passing Interface, CCR, DSS, and Pure MPI.NET
)
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
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/
Ayer publiqué las primeras lecciones del curso de introducción a Java en línea. En este post, que iré actualizando, quiero listar las lecciones que voy agregando a cada curso. Este tipo de post me permite tener una evidencia de avance.
Actualización: 21 de Abril, aparecieron las primeras lecciones del curso de Sitios con PHP y MySQL
Acá van las primeras lecciones agregadas:
2008-04-08 El lenguaje Java
2008-04-08 Java y Unicode
2008-04-08 Comentarios
2008-04-09 Variables y Tipos
2008-04-10 Tipos de Datos Enteros
2008-04-11 Tipos Reales
2008-04-12 Caracteres
2008-04-13 Operando con bits
2008-04-14 Sentencias y comandos
2008-04-15 La sentencia if-else
2008-04-16 Funciones matemáticas
2008-04-17 Errores con operaciones enteras
2008-04-17 Operaciones con reales
2008-04-18 Problemas reales
2008-04-18 Conversiones
2008