En la Conferencia Mashup

Mientras saco tiempo para escribir, y aunque ya fue hace tiempo, quiero aprovechar para contar algunas de las notas que tomé en el Mashup Camp de Mountain View, en Julio.

Los mashups son combinaciones de datos y contenido procedente de la web. La integración de datos tal y como se la conoce "por defecto", tiende a centrarse en datos estructurados (bases de datos relacionales y amigos). En este caso, sin embargo, la información se espera en formatos "WOA" (web oriented architecture), término acuñado por Nick Gall, de Gartner (aunque el concepto existe desde hace bastante tiempo), al que pude ver en el Innovation Summit de Las Vegas, hace unas semanas.

Lo de Mountain View fue un "CodeCamp". La diferencia con otras conferencias reside en que no hay una agenda predefinida, sino que cualquiera, el primer día de conferencia, puede ofrecerse a comentar lo que quiera, creando un calendario "en tiempo real". En este caso, desde luego, fue bastante efectivo. Aquí os resumo algunas de las charlas.

La primera charla a la que asistí fue sobre personalización en los mashups. En USA la utilizacion del movil siempre ha estado por detrás de otros paises, pero con la salida de iPhone, eso cambia definitivamente, y las aplicaciones de mashups han de tenerlo en cuenta. Magnet muestra un ejemplo con iPhone.

Otro tema de interés que se trató, y que desde entonces ha adquirido cierta dimensión, es la necesidad de personalización y seguridad ante la entrada de los mashups como elemento de socialización de información. Estándares como OpenAuth, OpenID o técnicas más clásicas como la URL obfuscation tratan de resolver este nuevo desafío.

En otra charla, un punto interesante: la agregación de información estilo widgets trae un componente añadido, que es el que toda esa informacion puede llegar a estar en el contexto del browser. Hay que ser cuidadoso en cómo se gestiona esa información, sobre todo cuando el browser se encuentra en un iPhone o cualquier otro dispositivo móvil con memoria restringida.

Los "enterprise mashups", más centrados en la integración de información para un uso empresarial, requiere la redefinición de algunas de las premisas que la integración de datos y workflows más tradicionales daban por hecho: múltiples estructuras de datos, relacionales y jerárquicas; datasets no estructurados; y, sobre todo, algo que tuve la oportunidad de discutir con Anthony Bradley en el Web Innovation Summit de Las Vegas, el desafío que tienen las empresas que no quieran perder el tren de los mashups: muchas herramientas de mashup se posicionan como "herramientas para usuarios finales", un nuevo intento, en mi opinión, de lo ya intentado en otras ocasiones (recuerdo todavía el JavaStudio de 1996, y cómo iba a cambiar radicalmente el modo de desarrollar, siguiendo una metodología orientada a componentes... je je je). Sin embargo, es cierto que el concepto de mashups sí acelera la capacidad de las empresas de generar aplicaciones tácticas (vamos, de usar y tirar) con muchos menos recursos de los necesarios hasta ahora. Para ello, sin embargo, es requerida la participación del departamento de sistemas si deseamos un soluciones con una calidad mínima como para poder ser consideradas. En otras palabras, las cositas que se hacen con herramientas como Yahoo!Pipes o Popfly no tienen que ver con las necesidades que, incluso actualmente, las empresas tienen a ese respecto. Una adecuación entre las necesidades de negocio y el departamento de sistemas podrían llevar a la optimización de esos procesos de desarrollo táctico.

Otro de los temas de discusión en este mundo de los mashups es en qué se diferencian de las "composite applications", como AboveAll. Parece que en el mashup camp ha habido consenso en que las composite apps son más planificadas, mientras que un mashup se realiza más ad hoc. Una vez más, no lo tengo nada claro. Creo que hay otras diferencias que los alejan más, principalmente que las composite apps están más pensadas como simplificación de las clásicas aplicaciones de Integración de Aplicaciones, mientras que los mashups se ven más como herramientas de integración de datos. Evidentemente hay solapamiento, tal y como existe entre EAI y EII. Pero un mashup puede requerir de planificación para llegar a su objetivo, mientras que algunas aplicaciones gráficas permiten la construcción rápida de prototipos de composite apps.

En una mesa redonda pude escuchar y charlar con Gregor Hohpe, el autor del libro Enterprise Integration Patterns, cuya materia mis alumnos del máster de Telemática de Coruña tanto tuvieron que aguantar :) Gregor, que ahora trabaja en Google, menciona algo que yo ya he comentado internamente: los mashups, tal y como se plantea ahora, son el Visual Basic del 2007. Permiten realizar pequeñas aplicaciones de manera autónoma sin control y planificación por parte de sistemas. Denodo, según esa definición, pasaría a ser un mashup enabler. Sin embargo, sigo sin estar totalmente de acuerdo. Considero que esa definición sólo tiene en cuenta el enfoque de las herramientas actuales de mashups como elementos visuales de combinación de datos procedentes de fuentes web 2.0. ¿Por qué limitarnos a ello? No me importa si dentro de 5 años el concepto mashup está olvidado y sólo se habla de integración de datos en un contexto más amplio que actualmente (cuando sólo se piensa en integración de información estructurada, proveniente principalmente de fuentes relacionales). Si hay empresas que quieren ser el Visual Basic o el Excel de los mashups, perfecto, hay mercado para ello. Quizá el enfoque de Denodo (para no ser tan teórico en este post) es más el ser el "Oracle" de los mashups. Aunque todavía quede mucho por hacer, claro.

En esa misma mesa redonda, Ed Julson, de Kapow (anteriormente en Sun), menciona un caso de una drilling station, donde parece que están obteniendo toda la información de la web pública. Una puntualización muy interesante de Ed fue que, por tanto, el valor añadido es DÓNDE ESTÁ ESA INFORMACIÓN. ¿Podría ser ese un nuevo modelo de negocio incipiente? Sin duda, en la parte técnica ya está habiendo investigación a ese respecto...

El segundo día asistí a una charla de Chris Slack, de Google, que realizó un recorrido por las diferentes APIs de Google: AJAX Search, AJAX Feed, Maps API. En este nuevo concepto de "cloud computing", la idea reside en que las aplicaciones no necesiten prácticamente infraestructura. "Utiliza la nuestra", parecen decirnos los Amazon, Google y compañía. "... a cambio de un coste mínimo... nosotros nos aprovechamos del concepto de la Long Tail".

Google, como otros en la actualidad, está proporcionando pequeñas APIs, pero muy completas para actividades relativamente simples (búsqueda en Google, obtención de feeds, ...). En definitiva, de lo que se viene hablando años ha, pero en un entorno global: Keep It Simple Stupid (KISS).

En ese momento, sacado por un investigador del Xerox PARC, hubo una interesante conversación sobre los términos y condiciones de uso de Google. Hasta qué punto se puede usar el conjunto de datos devuelto para un data mining programático fuera de la web. Realmente, esta discusión existe desde que está la web. Recuerdo cuando Yahoo! intentaba proteger el saqueo a su directorio, allá por el 96-97. Nosotros lidiamos con eso cada día, y, aunque "el arma no es quien mata, sino el asesino que la empuña", es un tema a considerar constantemente.

Por la tarde, en la última charla a la que asistí, el fundador de Apatar me demostró por qué hay que tener cuidado con los conceptos utilizados. No tengo nada contra Apatar, una herramienta open source de extracción, transformación y carga de datos, con algunas características de EII. Sin embargo, si te autodefines como EII, te expones a que te pregunten (¿quién habrá sido? Pues no, no empecé yo... aunque luego seguí, sí :) :) :) ) sobre temas tales como la propagacion de consultas, algo básico en federación de consultas. Nada de nada. Discutimos temas como la posibilidad de reescritura de consultas cuando tras el join hay un filtro, o la posibilidad de lanzar consultas con subselects y cláusulas between, o, en general, tareas de optimización de consultas. Por cierto, sienta bien poder aprovechar alguno de los conocimientos generados por la tesis para, al menos, charlar un rato con los "pares".

Para terminar, y como curiosidad, al ser un "CodeCamp", gratuito y con pocos recursos, y al surgir las charlas de manera bastante espontánea, los recursos son "escasos". Eso ha implicado que para alguna charla hubiera que buscar un carton sobre el cuál mostrar la presentación. Aún así, me quedo con este concepto, en el que mentes muy interesantes se juntan para charlar, discutir y mostrar sus últimos hallazgos.

Comments

Popular Posts