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 :)

We are getting ready for our leap towards public releases. What we expect to have just after Christmas is:

• Our open-source multiplatform middleware, along with the binaries for Windows, Mac, Unix/Linux and others such as PSP or Symbian S60; the documentation in Doxygen and the source code
• A developer portal in Track for the maintenance and improvement of the middleware
• A limited version of our framework interface available on the Web.
  
• Our corporative web, replacing the dull "visit our blog"
  

We are working hard in the middleware for this "kickoff". We are migrating it to as many platforms as possible, and working hard on the documentation, in and out of the code. Our goal is to get the grid community enrolled in this project.

Borja pointed out that there was not enough talking about how grid standards are being implemented in our middleware. In fact, the first release will not implement the standards, but we have specified, designed and implemented having OGSA and WSRF in mind. The papers about them have always occupied a main place in our desks. Therefore, we have planned to implement the wrapper - that will give the middleware support for the standards - before February 2007.

Last but not least, in this our first kickoff preview, here are the technological specifications of the middleware:

• Written in ISO C++
• Size of the binaries: varies, aprox. 400-500kb in Unix/Linux x86 - aprox. 55kb in PSP 1.5
• Four resource classes fully available in this release: shared memory, disk storage, process execution, MySQL database (their availability depends on the platform)
• Installation wizard for Windows, Preference Pane for Mac, configure + make scripts for Unix/Linux

In the next kickoff preview, we’ll talk about the inner design of the middleware. Stay tuned.

Tal y cómo hemos comentado en anteriores ocasiones, uno de los requisitos de nuestro middleware era que fuese posible instalarlo en cualquier dispositivo, incluidos los embedded.

Al estar programado en ISO-C++ la tarea de portarlo ha sido relativamente sencilla. Los principales quebraderos de cabeza los hemos tenido al utilizar la PSP-SDK por su complejidad y su escasa documentación en algunos aspectos.

Ingredientes:

• Sony PSP FW 1.5
• KDevelop
• PSP-SDK
• Nuestro middleware ;-)

Read the rest of this entry »

And I don’t know about you, but when I sample my nieces and nephews, even those in the USA, with "which would you rather have, a new iPod, a Motorola RAZR, a Sidekick, Microsoft’s XBox or Windows Vista?", I get a pretty consistent answer. (Hint: it ain’t Vista.)

Jonathan Schwartz

Y la respuesta es el Sidekick 3 de T-mobile. Quién tuviera un tío geek y CEO con ganas de regalar estos gadgets.

A pesar de seguir manteniendo el planteamiento "the network is the computer", la reflexión de Jonathan sobre killer-apps y cuál es el uso que se hace de los dispositivos móviles es interesante.

Compartimos la idea de que cada vez más gente tiene el teléfono móvil como puerta de acceso a internet y de que en un futuro demasiado cercano va a ser el dispositivo por excelencia de conexión a la red. El problema que existe actualmente con estos dispositivos y su conexión, no es tanto sobre cómo adaptar los contenidos presentes en internet a estos dispositivos, sino sobre qué aplicaciones pueden proveer servicios útiles a los usuarios.

Por ello cuando empezamos a diseñar nuestra plataforma, uno de los requerimientos principales era que fuese posible instalarlo en cualquier dispositivo. De mainframes a PDA’s. Por que la próxima revolución tecnológica va a venir de la mano de estos gadgets. Y si Adobe restringía el uso de sus readers en "embedded devices" (ellos que pueden pagar estudios de mercado bastante fiables), había que seguir la estela.

La prueba de la semana pasada con una PSP nos permitió pensar multitud de aplicaciones que sólo tendrían sentido en dispositivos móviles que formasen parte de un entorno distribuido. Los resultados de estos brainstormings los concretamos en funciones que estamos añadiendo a nuestra API.

En un futuro muy cercano vamos a hacer posible que todo el mundo pueda tener un grid en su bolsillo.

Después de varios días investigando sobre la SDK para PSP que corre por Internet, hace unos minutos hemos conseguido compilar y probar con éxito la primera versión de nuestro middleware para la pequeña de Sony. Recibe y procesa las peticiones del framework perfectamente. Sólo nos falta integrar nuestros plugins para poder aprovechar los recursos de la PSP de la mejor manera posible.

Ahora ya es tarde, pero prometo ampliar este logro con un post mas largo :D

Tras otra noche de programación intensiva, hemos conseguido unir en un mismo Grid los recursos  de diferentes sistemas. Muchos lo han intentado y pocos lo han conseguido. Es más, creo que somos los primeros en el mundo :-) Aunque la gesta sea importante, más importante es haber conseguido un middleware multiplataforma con un tamaño inferior a 400 kbytes (si un gadget tiene pilas, se lo instalamos).

Hemos probado 3 sistemas operativos: Win32, Linux y MacOSX. En estos momentos, cada uno contiene un port de nuestro middleware con un plug-in de CPU. Un script en PHP consulta al framework el estado de cada nodo y nos lo muestra en una interfaz Flash. Para ser nuestro primer intento con nuestras herramientas nos ha quedado bastante bien. Calculamos aproximaciones de Pi por el método MonteCarlo en un momento ;-)

Manteneos a la espera para una primera versión beta de nuestro middleware. En cuanto lo afinemos más (principalmente pasar el CheckStyle), lo documentemos ampliamente y configuremos la intranet de soporte publicaremos el código fuente.

Quede la foto de abajo para los anales registros de la historia de la informática.

Son las 7:23 de la mañana y nos vamos a dormir contentos :-)

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, Jazztel, Ono, etc en la sala y que quiera desarrollar la idea con nosotros? Las líneas de teléfono y de mail quedan abiertas :).

Son casi las 6 de la mañana y acabamos de vivir la sesión de programación más intensa que recuerde, pero ya podemos anunciar que tenemos versión "release candidate 1".

Y con sólo 2 días de retraso :)

Ahora queda lo más difícil: explicar claramente que es lo que hemos desarrollado. Aunque mejor se lo dejo a otro.

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.