Archivos de la categoría ‘Framework’

h1

Hello Flex, bye bye Ajax

Diciembre 3, 2007

Yesterday, Angel and Miguel, creators of the development Flex framework called Guasax visited Think in grid. After a visit to CitiLab and greet people of iWeekend, we started to talk about Flex and how to apply it in our Grid Portal.

One point for Diego, who started to defend it a few months ago. Flex it’s a very good RIA solution, maybe the best. Angel and Miguel solved our questions and my concerns:

1º I don’t want to use another technology if I can solve it with Ajax, gwt or other java solutions. Flex surpass the probe. It’s easy to learn, and the most important thing, it’s very easy to integrate with a Java architecture (I am thinking in Spring + hibernate). And the development time is shorter than a RIA application using Ajax. The result, no color, flex wins.

2º The performance. Our web application have on-line chart pages, Many nodes to manage, etc. This page answered our concerns.

3º How much does it cost? Flex is open source. The development IDE (Standalone or eclipse plugin) is unexpensive. Maybe the bad news are that some interesting solutions (data management module) are expensive when the application is stored on a production environment. But we can avoid this module using our own solutions.

4º No limits. Easy development for rich interfaces with usability and design. All in one.

Thanks to Angel and Miguel, now we will start to work and “think in flex”.

h1

Burning Framework

Abril 30, 2007

Con este título, robado de mi querido Albert abro este pequeño post. Digamos que está bien hablar de otras empresas o de externalidades, pero de vez en cuando toca contar como va el tema técnico.
La verdad que las cosas pintan muy bien, después de un proceso intenso de prototipaje en estos últimos 4 meses el FW entro hace 2 semanas en fase de testeo intensivo donde tenemos varios objetivos:

· Probar el sistema de Agentes desarrollado por Isaac y sacar conclusiones.
· Hacer sufrir el FW e ir depurando código para sacar el máximo partido y conocer los límites actuales con los que nos encontramos.
· ¿Cuanto fácil de instalar es?

Sobre el primero… creo que Isaac estará encantado de comentar sus resultados en otro post, hace 1 semana que se ha cerrado en su laboratorio de pruebas y anda allí jugando con el tema. De forma sencilla, en mis últimas pruebas pude observar como el FW descartaba uno de los nodos al comprobar que este andaba saturado haciendo cosas en local.

Sobre el segundo punto… Espero que Albert os comente algo, pero ya ha montado su servicio de saturación y ha empezado a realizar peticiones intensivamente a la arquitectura. Hasta el momento, 1086 conexiones abiertas entre el FW i los diferentes MW. No está mal ;). Encima se ha montado un interesante sistema de monitorización que nos permite ver bonitos gráficos online de la carga de CPU en cada MW y el estado de las diferentes colas de ejecución.

Por último, la prueba de fuego :). Diego ha cogido el FW y el MW y mediante documentación generada en nuestra wiki interna ha instalado todo el entorno en el despacho. Creo que ver su cara de satisfacción no tiene precio :). En 15 min. (Contando la instalación puramente estandard de Tomcat), a conseguido hacer correr un pequeño Grid con 7 nodos (1 Linux, 2 Mac y 4 Windows).

Bueno, después de lanzar retos a Isaac, Albert (Para que escriban un post) solo me queda añadir que todo y las interesantes resultados obtenidos en las pruebas (hasta el momento) ya tenemos una larga lista de @TODO’s para la próxima versión (de aquí la grandeza del prototipaje) que, añadido a la agonía a la que estoy sometiendo a Albert con la documentación del FW nos permitirá tener una versión de la que ahora ya, nos sentimos muy orgullosos.

Por cierto, ando buscando artículos, manuales, documentación que hable sobre testing de arquitecturas montadas con tecnología Java, cosas a tener en cuenta, herramientas, etc. El objetivo, añadir más conocimiento a lo que ya tenemos hasta el momento y encontrar otros puntos de vista en ejecución de pruebas de estrés. Por lo tanto, lanzo está petición a quien quiera contar sus experiencias.

Hasta la próxima…

h1

AgentGrid Repast Simulator

Febrero 16, 2007

Dicen algo para ti las palabras Grid, agente, y simulación en una misma frase? Entonces seguro que echabas de menos lo que vamos a presentar. Tranquilo, si no te dice nada la combinación, es muy posible que esto tambíen te parezca interesante o curioso. Sigue leyendo :)

Lo veníamos anunciando desde Navidades,  estábamos desarrollando un simulador de agentes en el Grid. Tenemos algún post explicando para qué queremos este simulador:

Acabamos de montar en sourceforge el proyecto que da cobijo la alpha de nuestro simulador de sistemas multiagente en el Grid.
AgentGrid Repast Simulator at sourceforge

La idea central es crear una comunidad (es un dominio muy específico, pero hay bastantes investigadores a nivel europeo y mundial) al rededor de la herramienta, que es pionera ya que no existe otro simulador de Grid  enfocado a Inteligencia Artificial y que sea accesible públicamente. Por un lado los investigadores obtienen una herramienta agil y flexible para analizar de manera sencilla sistmas mulitiagente en el Grid. Por el otro contribuyen a la mejora de la herramienta. La licencia, GPL. Tendremos un lugar en la web de la empresa para complementar la info sobre el simulador.

En un post posterior (en 1 semana digamos) daremos cumplida cuenta de los detalles técnicos (los imprescindibles) sobre el simulador, así como acceso via sourceforge al simulador en sí, el código y el manual de usuario. La idea  central es que cualquira con algún conocimiento de los entornos Grid y algunos (escasos) conocimientos de Java, y una idea de lo que quiere que sus agentes hagan  y como quiere que aprendan (eh, esta  parte no la podemos hacer por ti, esa es tu aportación creativa a la receta;) podrá disponer de una herramienta sencilla para testear sus hipótesis.

De momento os pasamos este video para que podais verlo en acción. Pedimos disculpas por la baja calidad del video, de momento lo nuestro es el Grid y no la edición de video / optimización de formatos para youtube. Agradecemos consejo de algún entendido en la materia sobre herramientas/trucos para pulir la edición del video ;)

h1

Web Services, sockets y ThinkInGrid (II)

Diciembre 29, 2006

Creo que los comentarios e inquietudes expuestas por Luís y Lluís se merecían un nuevo post.  Nos hemos sentado Albert y yo, un par de vasos de Coca-cola y este es el resultado:

Web Services e interoperabilidad… ese gran dilema. No creas que no hemos hablado de ello. Si una cosa está clara es que los web Services fueron definidos para solucionar la interoperabilidad. Y después de mucho darle vueltas, creemos que Axis cubre nuestras expectativas. Así, como funcionalidad, se puede desplegar el framework como web service. Esto nos permite conectarnos a un framework remotamente a través de una interface web (pudiendo administrar o requerir ejecuciones).

Como dice Luís "…no es un problema atacar un SW implementado en Java desde un cliente .Net, Python o Symbian C++.." . Yo incluso creo que cosas sencillas y un poco complicadas, que realmente por mi justa experiencia creo que cubrimos el 90% de las necesidades de todos nuestros clientes potenciales. Pero ya puestos a pedir, y espero que no me cobres por ello , conoces alguna tecnología que te cubra todo el abanico de posibilidades?

La API de aplicaciones (ya hablaremos más adelante de que lenguajes soportaremos) permitirá la representación en objetos para su manipulación,  que en última instancia se traduciran a mensajes xml a enviar al FW (a través del puerto nativo). Por lo tanto destacar que tanto los mensajes que llegan a través del web service como en socket son equivalentes.

Lo que se comentaba sobre la API REST, quizás no me he explicado bien. Es justamente lo que tenemos :). Un servidor web + AXIS + XML. Todo y eso, creemos que no debemos olvidar tener un soporte clásico de sockets, porque como dices tu en otras palabras, no se puede pedir todo en esta vida y menos a los web Services.

Ligero, si, ligero, ligero, ligero. Por suerte, el diseño de nuestra arquitectura requiere de un módulo ligero en cada nodo de la red (El middleware) pero nos podemos permitir el lujo de decidir que FW exponen sus servicios en forma de web services, que es la parte central (que no centralizada) de nuestra arquitectura.

Los beneficios que nos aportaba tener sockets y SOA era mayor a los perjuicios de no hacerlo. Encima, está montado de tal forma que se reaprovecha gran parte del código en las dos interfaces (Que en el fondo es una pero con dos puertos de entrada).

La liberación de código está planificada para finales del mes siguiente (si todo va según lo planificado). Como comentábamos en el post del KICK OFF, de entrada no liberaremos el framework.

Sin más me despido. Gracias por vuestros comentarios :)

h1

Web Services, sockets y ThinkInGrid

Diciembre 28, 2006

hspace="4Creo que de entre todas las cosas que estamos desarrollando en ThinkInGrid la más importante se encuentra en la pasarela de entrada (API) a nuestra arquitectura basada en la comunicación por mensajes XML y donde esperamos que empresas de todo el mundo programen sus aplicaciones.

Como conseguir llegar a ser lo suficientemente específicos para que nuestra arquitectura sea sencilla de usar y como llegar a ser lo suficientemente abiertos para no limitar las mentes perturbadas (En las  que me incluyo) a la hora de diseñar una nueva aplicación.

Llegados a este punto y como si de un hijo se tratara actualmente estamos trabajando en ello. Es por eso que hoy quiero mostraros un par de pinceladas sobre la decisión tomada sobre el acceso a la API.

La decisión… no cerrarnos a un solo tipo de acceso. Es por ello que hemos preparado un entorno que permitirá trabajar con web services o con el sistema tradicional de sockets (Habilitando un puerto para dicho proposito). Por supuesto…a gusto del consumidor.

Sobre la primera, el motivo es claro, subirnos al carro de las nuevas arquitecturas SOA, facilitar la comunicación entre máquinas en una red y ofrecer al desarrollador la posibilidad de brindarle las ventajas que proporciona dicha tecnología. Para ello,  mediante un servidor de aplicaciones (Tomcat, WebLogic, etc.), nuestro framework y Axis ofrecemos la posibilidad de interactuar fácilmente con toda la arquitectura grid que pueda tener un dominio o grupo de dominios determinado. Como ejemplo de uso y que nos servirá para accelerar implantaciones en cliente estamos desarrollando un entorno web para el mantenimiento de dominios Grid.

Los sockets, para los nostálgicos, para los que prefieren seguir realizando comunicaciones entre máquinas sin depender de un servidor web, o simplemente para los que por necesidad de entorno precisan de esta comunicación.

¿Que creéis vosotros? En ThinkInGrid creemos que no podíamos descartar ninguna de las dos opciones y es por eso que hemos dedicado nuestro tiempo a implementar las dos posibilidades. Por ejemplo, Albert está acabando unos scripts muy chulos con el ANT para facilitar la carga del framework.

Y eso es todo lo que os puedo contar… seguimos en contacto.

h1

Grid Computing y GMPLS

Septiembre 25, 2006

Ando unos días buscando información sobre el tema. El otro día me entró el gusanillo mientras pensábamos en nuevos recursos que añadir a nuestro catálogo de "plugins" para el middleware. Y es que, como ya sabéis (Y si no lo sabéis ahora es el momento), soy Ingeniero de Telecomunicaciones y de entre los temas que más me atrajo en mi dorada época estudiantil, las redes ópticas y las nuevas arquitecturas definidas sobre ellas.

Las redes ópticas actuales constan de un elevado número de capas que otorgan la capacidad de manejar perfiles determinados de información, lo que estaba tendiendo a redes demasiado específicas y difíciles de gestionar. Pero a algunos  iluminados se les encendió la bombilla y  pensaron que las redes debían simplicarse, evitando funcionalidades redundantes entre capas. Esto derivo hasta llegar a tener solo dos.  Esto ha permitido desarrollar un plano de control común, y entre algunos protocolos de gestión, se encuentra GMPLS.

GMPLS es el resultado del trabajo entre Optical Internetworking Forum, Optical Domain Service Interconnect consortium y la Internet Engineering Task Force que pretende estandarizar un protocolo que pueda servir para todo tipo de tráfico. La clave se encuentra (y aquí os empezará a sonar a Grid) en la capacidad que tiene la capa de control de extender la topología de la red y la gestión del ancho de banda a lo largo de todas las capas para lograr un sistema eficiente que integre servicios y transporte.

Siguiendo con la filosofía Grid, GMPLS necesita tres componentes básicos para su correcto uso:

  1. Exploración de recursos: se obtiene información acerca de los recursos de red tales como conectividad o capacidad de los enlaces. Los mecanismos utilizados para diseminar esta información de estado se basan en una extensión del Internet Gateway Protocol (IGP).
  2. Selección de ruta: se utiliza para seleccionar una ruta apropiada a través de la red óptica inteligente en base a unas ciertas restricciones impuestas por el entorno y las limitaciones de la capa física.
  3. Gestión de ruta: incluye distribución de etiquetas, así como establecimiento, mantenimiento y terminación de ruta. Estas funciones se realizan por medio de un protocolo de señalización extendido como Resource Reservation Protocol for Traffic Engineering (RSVP-TE) o Constraint-routed Label Distribution Protocol (CR-LDP).

Estos tres componentes deben estar diseñados para su correcta utilización independiente entre si, permitiendo a las operadoras diseñar sus redes en consonancia con su modelo de negocio.

Aquí entra ThinkInGrid y nuestros componentes desarrollados. Queremos llegar a desarrollar un plugin capaz de virtualizar los datos provenientes de una red óptica. Esto debería permitir a empresas mucho más especializadas desarrollar productos o proyectos a medida para gestión de redes troncales:

  • Uso de información descentralizada y distribuida por la red.
  • Uso del plano de inteligencia artificial para optimizar y automatizar procesos de control y balanceo de carga.
  • Monitorización de red añadiendo un plano de decisiones automatizadas.
  • Desarrollo rápido y estandarizado de aplicaciones mediante el Framework.
  • Creación de mecanismos de colaboración entre operadoras o empresas complementarias.
  • Generación de nuevos modelos de negocio. Lo que permite una clara diversificación de servicios.

Bueno, creo que la cosa está clara. ¿Algún directivo de Telefónica, Wanadoo, JazztelOno, etc en la sala y que quiera desarrollar la idea con nosotros? Las líneas de teléfono y de mail quedan abiertas :).

h1

El concepto Grid sobre redes Ad hoc

Septiembre 8, 2006

Entre línea y línea de código son comunes los brainstorming entre el grupo de trabajo con el humilde propósito de descargar nuestras apretadas mentes y porqué no, encontrar esa idea que nos expulse del anonimato.

Hoy le ha tocado el turno a las arquitecturas ad hoc. Para quien no sea entendido en el tema, os comentaré que estas infraestructuras pretenden inhibir el concepto de nodo central para tender a un entorno en el que todos los recursos estén en igualdad de condiciones, o lo que es lo mismo, los elementos en una red, comparten las funcionalidades de cliente/servidor por igual.

Actualmente, uno de los máximos exponentes que se ha popularizado gracias a la implantación en un sinfín de "gadgets" es el sistema Bluetooth, que ha facilitado la interconexión entre dispositivos sin necesidad de pasar por entornos centrales, lo que ha facilitado saturaciones, colapsos, mal humor, etc.

Pues si señores, en ThinkInGrid hemos, estamos y vamos a seguir pensando en el concepto mientras desarrollamos nuestro entorno MIDDLEWARE - FRAMEWORK con el objetivo de descentralizar al máximo las "Funciones Grid" y de esta forma aprovechar las ventajas que proporciona las redes Ad hoc tanto en protección contra errores, transmisión de información, etc.

Nuestro Middleware basándose en estos conceptos proporciona una arquitectura muy ligera a cualquier estructura de recursos heterogéneos (Ordenadores, SCADAs, PDAs, camiones, dispositivos domóticos, etc.), sobre cualquier tipo de comunicación: Wireless, bluetooth, satélite, Powerline Communications, etc.; y mostrándose dentro de la misma estructura de información para nuestro FRAMEWORK, lo que permitirá a nuestros clientes afrontar infinidad de problemas (proyectos) de origen variante en un entorno homogéneo de análisis y desarrollo.

Por otro lado el FRAMEWORK, entre otros, proporciona los protocolos de protección de errores, descubrimiento de recursos, seguridad y gestión de colas que todo sistema Ad Hoc necesita. Todo embalado en un elegante sistema orientado a servicios (SOA) y que ha de facilitar el desarrollo estructurado de cualquier entorno empresarial.

En resumen, veamos las ventajas que proporciona durante la fase de desarrollo de un proyecto:

  • Reducción de tiempos de análisis. –> El desarrollo se define siempre para un mismo entorno.
  • Generalización de problemas –> Para un programador, la forma de utilizar un recurso CPU será igual que para utilizar un recurso EMBOBINADORA .
  • Fácil adaptabilidad de los equipos de desarrollo –> El desarrollo siempre se realiza sobre una misma plataforma
  • Disminución de impactos –> Si el entorno es conocido, los riesgos son fácilmente cuantificables.
  • Minimización de desviaciones. –> Si el entorno es conocido, las desviaciones son medibles.

En resumen, REDUCIMOS COSTES en los proyectos de desarrollo. Y aún nos falta por contabilizar el beneficio económico derivado de la propia aplicación o las ventajas técnicas que adquirirá el proyecto por el uso de nuestros entornos.

Nunca el pensar en entornos ad hoc fue tan fácil, con ThinkInGrid ese día ha llegado.