[Serie] Enterprise 2.0: Parte 2- Elogio del Choreo

 Ésta  es una serie sobre el revenue detrás del concepto conocido como Web 2.0. En la intro analizamos los por qués/para qués de buscar plata en esta nueva web. En la parte 1 revisamos como el efecto red ha mejorado la calidad y precisión de aplicaciones basadas en la participación de los usuarios. En esta misma parte comentamos cómo los datos que exponemos no sólo en cantidad sino adecuada y oportunamente al usuario que los pueda estar necesitando, aumenta la confiabilidad en nuestra aplicación y ayuda a provocar el efecto red que, virtuosamente, va a mejorar nuevamente la calidad de los datos

En esta ocasión vamos a revisar mecanismos que permiten a terceros agregarnos a sus cadenas de valor si nosotros antes disponemos partes de nuestra aplicación a modo de ganchos (hooks), partes concretas, tanto funcionales como a nivel de datos

 

APIs para Re-Usar

Por ejemplo, de nuevo estos "buenudos" de Amazon, ofrecen una serie de servicios web (basados tanto en estándares WS-* como en REST, la simplista alternativa a WS-* -ya vamos a hablar luego de REST-) de modo tal que desde una aplicación tuya puedas exponer servicios de Amazon (búsqueda de catálogo, carrito de compras, ver imágenes de productos, comentarios de compradores, etc) agregando todo el valor que eso significa!! Lógico, los de Amazon ganan también porque se les abre la puerta a vender, pero vos ganás porque más gente podría querer usar tu aplicación ya que les gusta cómo vos clasificás y exponés la información, pero además eventualmente ofrecés la chance de comprar aquello que estás mostrando
Suena tirado de los pelos esto que te digo? A los de Image Database (IMDb) no, fijate. Y son la base de datos en línea del Séptimo Arte más visitada (por algo será, no?)


Enterprise 2.0 en acción: a esta base de datos no la llena un comité de ilustres cinéfilos sino
que vos, yo, cualquiera puede editar los contenidos. Es decir, el sitio es de comunidad y sin
embargo el que quiere saber de un actor o de una peli entra acá a buscar. Y si quiere adquirirla
(ver al costado derecho) Amazon ofrece vendertela ipso facto

Comercialmente hablando todo puede ser. Por ejemplo, en el caso de Amazon, su servicio de e-Commerce no tiene costo (es inversión pura por cuanto les da la chance de usar tu aplicación como sucursal) en tanto que otros servicios de esta gente sí se pueden usar pagando un fee (tasa)

Google, a través de su servicio AdSense descubrió un modelo comercial mejor: usales su aplicación y ganá plata por hacerlo. Te ofrece una API gratuita (un bloque de código HTML) que lo incluís en tu página y despliega avisos basados en un contexto que le indiques (presuntamente relevante a la página que estás mostrando)


"Google Ads" te ayuda a mostrar avisos en el contexto de la noticia que estás leyendo (ver rojo) o
al menos de la sección del diario que estás revisando (ver azul), asumiendo que un lector que se
interese en estas noticias, probablemente tenga mayor interés en esos anuncios que alguien que
lee el diario para saber los resultados de la NBA o de Roland Garros

Si alguien que visitó tu página hace click en el aviso… vos cobrás compre o no!! Google le cobra al anunciante (mediante un acuerdo entre ellos conocido como Google AdWords) y te paga a vos una comisión según lo estipulado en Google AdSense. En el ejemplo que te voy a mostrar, el que está aprovechando esa posibilidad es ni más ni menos que el matutino de mayor tirada de la Argentina: el diario Clarin. Alguna vez te preguntaste cómo van a sobrevivir los diarios cuando todo el mundo tenga Internet y nadie compre el diario de papel? Fijate acá cómo están sobreviviendo hoy smile_shades (y en verdad, gozando de muy buena salud!)


Suplemento "Viajes" del diario argentino Clarin: con diferentes tonos te muestro
cómo las ofertas de la derecha se relacionan directa o algo más vagamente con
las regiones a las que aluden las diversas notas (estancias bonaerenses, cordillera
andina o viajes en general)

Todas estas movidas, nuevos modelos comerciales, tendencias, etc, como siempre pasa en estos casos, obligan a un barajar y dar de nuevo. Porque a muchos "ganadores" de la vieja guardia si no evolucionan los van a pasar como a gordo en maratón. Justamente Microsoft (alguna vez opositor de los estándares abiertos y hoy, en cambio, uno de sus más fervientes adherentes), conciente de esto, hace un tiempo que viene lanzando una serie de servicios gratuitos, conocidos como Windows Live. Te invito a que te pegues una vuelta porque creo que te va a sorprender la capacidad de innovación y de re-creación de una compañía que hasta hace poco se venía basando en software cerrado (lo que en su momento le valió varios juicios por monopolio más un rechazo generalizado tanto en la comunidad de desarrolladores como de consumidores)

Por ejemplo, este post lo estás leyendo en Windows Live Spaces, y a su vez yo lo escribí usando Windows Live Writer (aún en versión beta)


Windows Live Writer: la trastienda de ZonaDiegum

Acá viene, entonces, la parte que te pueda interesar: si sos desarrollador de software o de sitios web, Microsoft te da la posibilidad de que añadas valor a tus aplicaciones con el Windows Live SDK. Por ejemplo, este artículo te cuenta cómo, mediante la inclusión de un archivo JavaScript en ciertas páginas de tu aplicación, podés consumir el servicio de búsquedas de Windows Live Search (el "google" de Microsoft). Para más información, novedades y ejemplos acerca de desarrollo basado en Windows Live, visitá el portal en MSDN

Y en lo que a vos y a tu organización respecta? Cómo podés copiar estos modelos para que otros usen tu aplicación desde las de ellos? Primero que nada, negocios son negocios. Quiero decir, no vayas a pretender que usen servicios de tu aplicación sólo porque se los expusistes. Les tiene que aportar realmente algún valor, sea porque se van a ahorrar costos, sea porque incluso puedan llegar a ganar algún ingreso. Del mismo modo, en lo que a vos respecta: no expongas servicios sólo por contar después que lo hiciste. Si tu aplicación se sostiene en una arquitectura de la participación que hace que sus resultados mejoren en la medida en que es usada, exponé justamente esos servicios que al ser usados maduren su calidad. Finalmente, acá sin dudas aplica lo que te expuse en el Boletín Extraoficial de Arquitectura #2, en aquella sesión de Krzysztof (alias "El Pocho") Cwalina: querés hacer un framework o API altamente re-usable? Diseñá entonces algo sencillo de entender, de asimilar. Es típico de varios arquitectos hacer diseños oscurantistas, por así decir, barrocos, creyendo que así los van a respetar mejor. Es posible que los respeten, sí. Pero vos diseñá algo que de tan simple y a la vez potente, lo termine usando y recomendando todo el mundo. Y cuando eso pase y sepan que fuiste vos el creador de eso que todos usan y recomiendan, quiero ver quién te va a faltar el respeto

 

Datos for Export

Otra forma por demás sencilla de dejar cosas para que te las choréen y en el mismo acto te beneficien no pasa por dejar funcionalidades disponibles sino datos (nuevamente: LOS DATOS MANDAN!!)
Han surgido una serie de protocolos de datos que se han adoptado en forma asombrosa. Dejar tu info en cualquiera de estos protocolos (algunos son un "must" pero si podés incluir otros vas a ganar en alcance) hará que tu info pase a estar disponible desde lugares inimaginables. Te hablo de

  • Formatos para Suscribir: RSS y ATOM. Ambos son gramáticas XML que provéen información en forma de digesto. Es decir, similar al ejemplo que te ponía de Google que sólo expone fragmentos de la info pero fundamentalmente un vínculo (link) para que accedas a la misma en forma directa y ya sin Google como intermediario. Eso mismo procuran los formatos suscribibles (o "sindicables" para castellanizar la voz inglesa de "syndication"). Particularmente a RSS me había referido allá por Marzo (un screencast integral que te propongo que revises para no yo repetir todo acá). ATOM, según sus promotores, es más potente que RSS y supuestamente lo reemplazaría. Ahora, aún siendo verdad que es más potente -cosa harto probable- yo no sé si realmente lo reemplazará como tampoco ocurrió que el estándar para definición de gramáticas "XML Schema" (o XSD), claramente más potente que su antecesor "Document Type Definition"  (o DTD), no lo reemplazó debido a su mayor complejidad (a menudo innecesaria). Otro ejemplo donde el "más potente Goliat" no pudo con "el modesto pero suficientemente bueno David" tenés en el lenguaje BASIC respecto de C++, SmallTalk, incluso Java y C#. La clave del éxito, como te decía antes respecto de diseñar tu API re-usable, es que sea lo suficientemente simple de entender y lo suficientemente potente de aprovechar
    Un ejemplo posta de "RSS to go" (RSS para llevar) lo tenés en el portal de Arquitectura MSDN. Ese portal divide el espacio de la "Arquitectura de Software" en varios tópicos, y consiguientemente organiza sus páginas a razón de un tópico por sección (entendamos por sección un conjunto de páginas relacionadas)


    El sitio de arquitectura de Microsoft tiene una página donde se despliegan las 100 últimas novedades,
    las cuales en realidad están en un archivo RSS que puede ser suscripto desde cualquier lector RSS
    Justamente en la imagen se ve, solapado con el browser, un gadget de Windows Vista capaz
    de parsear y desplegar contenidos RSS. En este caso, claro, mostrando el mismo RSS del portal

    Ahora, cómo hacer para que la data que publicás en formato suscribible sea realmente "robada" por otros y, más importante aún, cuando ellos la expongan, invite a sus visitantes a consumirla (y, por ende, beneficiarte)? Acá está el secreto de viejo lobo de mar (aunque un auténtico mago no debería explicar los secretos): por empezar, reuní y publicá info que realmente le agregue valor al suscriptor, sea para consumo personal o para re-exposición desde su portal y aplicación, lo que tiene un efecto amplificador
    Ahora, lógico, puede pasar que otros se interesen en suscribirse a tus novedades y re-exponerlas, pero que después nadie se interese en hacer click en ninguno de los ítems por lo que el valor real de la información que vos ofrecés pasa desapercibido (por ejemplo, si querés contar cuánta gente miró cada pieza de contenido de tus páginas, el resultado puede ser muy exíguo)
    Cómo lograr que realmente se sientan interesados a entrar concreta y definitivamente a tu contenido, más allá de tus catálogos? La onda pasa por proveer un título y una descripción lo suficientemente largo como para que no dejé dudas de lo que se puede esperar encontrar si se sigue el vínculo a la pieza; pero lo suficientemente corto -este equilibrio es lo más difícil- como para que deje con ganas de más, de entrar de una vez y sacarse la duda
    Sabías que toda, absolutamente toda la información del sitio de Arquitectura MSDN es suscribible? Si no lo sabías es culpa mía de no comunicarlo bien. Es decir, vos te podés suscribir al flujo general, que permanentemente muestra las últimas cien novedades (según el componente suscriptor de este flujo que uses, vos podés no perder los previos "últimos cien" a medida que van dejando de serlo, ya que la mayoría de los componentes suscriptores son acumulativos: manejan su propia base de datos interna de manera que vos no pierdas la historia)
    De este modo vos podés suscribirte parcialmente a las novedades, por ejemplo

  • Suscripciones Agregadas: OPML (Outline Processor Markup Language). Es una vuelta de tuerca más de lo anterior, permitiendo suscribir simultáneamente a varias fuentes de datos, consolidando (aggregation) toda la data en un único flujo (el que a su vez se puede exponer como RSS, ATOM y otro formato para ser nuevamente reusado!! smile_whatchutalkingabout)
    Te la dejo a vos para que te maquines cosas que podrías hacer con esto. Sólo si no se te ocurre un soto te muestro lo que hacemos nosotros con los bloggers sobre Desarrollo Ágil en el equipo de Arquitectura de Microsoft


    Así es por dentro el OPML de los bloggers de Desarrollo Ágil de Microsoft. Un encabezado con
    info básica y un cuerpo donde cada <outline> apunta, mediante su atributo xmlUrl, a un RSS


    Así se ve el OPML anterior una vez que un lector de OPML lo parsea, accede a los RSS que
    están contenidos, los consolida, ordena por fecha, y finalmente transforma todo a un mega
    RSS


    Voila! La columna de la izquierda muestra formateadas las entradas del RSS resultante de
    leer el OPML anterior

  • Formatos para Programar el Browser: JSON (JavaScript Object Notation). El formato anterior es súper piola si lo van a consumir personas (digo, revisarlo visualmente es entendible) o componentes suscriptores como los ejemplos de readers (lectores) que te mostré antes
    En cambio si necesitás trabajar la info desde el código JavaScript de tus páginas, quizás te venga más a mano un formato que los intérpretes JavaScript son capaces de procesar en forma masiva (ché, a todo esto, JavaScript es el lenguaje de programación de facto de los navegadores, just in case que no lo supieras)
    Aca te muestro un ejemplito posta de JSON

    {
          "Grupo": {
             "Nombre": "The Cure",
             "CreadoEn": 1976,
             "Origen": "Inglaterra",
             "Lider": "Robert Smith",
             "Sitio": "
    http://www.thecure.com",
             "Imagen": {   // los brakets engloban las propiedades de un objeto
                "Url": "
    http://www.mcarecords.com/MCAImageUpload/1547685-Full.jpg",
                "Height": 164,
                "Width":
    275
             },
             "Discografia": [   // las llaves engloban los elementos de un Array
                "Three Imaginary Boys (1979)",
                "Seventeen Seconds (1980)",
                "Faith (1981)",
                "Pornography (1982)",
                "The Top (1984)",
                "The Head on the Door (1985)",
                "Kiss Me, Kiss Me, Kiss Me (1987)",
                "Disintegration (1989)",
                "Wish (1992)",
                "Wild Mood Swings (1996)",
                "Bloodflowers (2000)",
                "The Cure (2004)"]
          }
    }

    A partir de acá podrías acceder en forma programática a los componentes del objeto siguiendo la idea que te muestro a continuación

          // bandaStr es una variable string que contiene lo de mas arriba
          var banda = eval(‘(‘ + bandaStr + ‘)’);
          // segundoAlbum pasa a contener "Seventeen Seconds (1980)"
         
    var segundoAlbum = banda.Grupo.Discografia[1];

    La clave de preferir
    JSON en este caso sobre RSS u otros te la da el hecho de que en JavaScript tenés disponible el comando eval(<expresion>) que llama al intérprete JavaScript y te hace la transformación entre el string y la jerarquía de objetos. Lograr lo mismo con un formato basado en XML implicaría usar alguna biblioteca de parsing (que de hecho las hay, ya voy a hablar más adelante cuando cubra REST)
    Ambas alternativas son posibles y, ojo, ambas son lentas en ejecución pero al menos la de JSON es más rápida que la otra en tanto está incorporada (built-in) en el interprete
    Uses la que uses, lo súper piola de JavaScript es que permite acceder a partes del documento HTML en forma programática (gracias a la API DOM -por Document Object Model-, soportada ampliamente en las distintas versiones de JavaScript), y así modificarlo


    Una vez armada la jerarquía de objetos en JavaScript, producir HTML de ello es un trámite
     

  • Servicios Web: WS-*. El formato anterior es súper útil en su contexto: un interprete JavaScript. Ahora, y el resto del mundo qué? El resto del mundo tiene -hoy ya se puede decir- un formato de mensajería que va terminando de completarse y ofrece una robustez inigualable (seguridad, identificación, encriptación, mensajería confiable, contextos transaccionales, etc)
    Está también basado en XML y es el estándar de facto si tenés que hacer hablar procesos, digamos, Java EE y .NET (o cualquier otro! Incluso JavaScript: esperá que te cuente de AJAX, ya llego -paciencia-)
    Como te digo, la especificación de servicios es todo lo robusta que necesites (aún está evolucionando, ojo, no está ya-ya todo disponible pero se supone que va a estarlo en el mediano plazo)
    Pero para casos simples -digamos, internos a tu organización, que no requieren privacidad por ejemplo- podés usar el perfil básico de estos servicios web, consistentes en unos pocos protocolos ampliamente disponibles
    WSDL (Web Service Description Language): que se usa para describir el contrato del servicio. Es decir, qué datos recibe, qué datos devuelve más algunas que otras políticas de uso del servicio -que el framework de ejecución de servicios web deberá verificar que estén siendo cumplidas en cada invocación
    SOAP (Simple Object Access Protocol): este formato es la gramática de una invocación a un servicio web, o su respuesta. Es decir, no está repitiendo el formato anterior: el anterior describe los tipos y las políticas de la mensajería hacia y desde el servicio web. En cambio SOAP es el mensaje en sí (como en la facu, los parámetros formales y actuales de un método. Formal es "pepe es int" y actual es "en la invocación, pepe vale 5". Ok, "pepe es int" se declara en WSDL" en tanto que "pepe vale 5" se dice en SOAP
    HTTP y otros: los servicios web se llaman "web" y no "servicios" a secas porque al principio usaban protocolos de la web para transporte (HTTP), mensajería (XML), etc. Hoy eso ya no es mandatorio y es común transportar los servicios web directamente en la capa de abajo de HTTP: TCP. Además más allá de que SOAP presenta la ventaja de que puede ser entendido tanto por procesos como por personas, es muy charlatán (verbose) y consume mucho ancho de banda. Para lidiar con eso se agregó Infoset a WS-*, que sigue siendo basado en XML pero optimiza tags y otra información que a la postre pesaban
    Por esto mismo, se convirtió en una best practice que si tenés que hacer hablar Java con Java o .NET con .NET, quizás es preferente usar formatos nativos como Java RMI (Remod Method Invocation) o .NET Remoting. En este último caso, la API Windows Communication Foundation (WCF) te va a permitir abstraerte del formato de transporte usado por debajo, para que si fuiste por .NET Remoting y te arrepentiste o cambiaron las circunstancias, puedas hacer el switch a servicios Web sin impacto en el código
  • REST (REpresentational State Transfer). Es la venganza del XML puro (a veces llamado Plain Old XML o POX) contra JSON y WS-*. Velo como el XML más simple que te quieras imaginar (por ejemplo, volviendo al caso que vimos en JSON)

    <grupo>
        <
    nombre>The Cure</nombre
    >
        <
    creadoEn>1976</creadoEn
    >
        <
    origen>Inglaterra</origen
    >
        <
    lider>Robert Smith</lider
    >
        <
    sitio>http://www.thecure.com</sitio
    >
        <
    imagen
    >
            <
    url>http://www.mcarecords.com/MCAImageUpload/1547685-Full.jpg</url
    >
            <
    height>164</height
    >
            <
    width>275</width
    >
        </
    imagen
    >
        <
    discografia
    >
            <
    disco>Three Imaginary Boys (1979)</disco
    >
            <
    disco>Seventeen Seconds (1980)</disco
    >
            <
    disco>Faith (1981)</disco
    >
            <
    disco>Pornography (1982)</disco
    >
            <
    disco>The Top (1984)</disco
    >
            <
    disco>The Head on the Door (1985)</disco
    >
            <
    disco>Kiss Me, Kiss Me, Kiss Me (1987)</disco
    >
            <
    disco>Disintegration (1989)</disco
    >
            <
    disco>Wish (1992)</disco
    >
            <
    disco>Wild Mood Swings (1996)</disco
    >
            <
    disco>Bloodflowers (2000)</disco
    >
            <
    disco>The Cure (2004)</disco
    >
        </
    discografia
    >
    </
    grupo>

    Creo que no hace falta decirte que para parsear XML tenés APIs disponibles por todos lados. Java y .NET lo traen en forma nativa. En el caso de JavaScript hay quichicientas disponibles también (echale, por ejemplo, un vistazo a JKL.ParseXML)
    Las contras de XML, como comentaba antes, son la verbosidad que puede afectar el rendimiento por el mayor consumo de ancho de banda. Afortunadamente hoy ese problema está abordado con frameworks que, mientras que en tu entorno de desarrollo y para propósitos de debugging, te permiten ver el XML en la forma entendible del ejemplo más arriba, para la ejecución te convierten el stream en un formato más reducido (y también menos entendible por vos, claro, no así por el proceso que le va a dar lo mismo si el tag se llamaba <origen> o simplemente <o>)

  • Formatos Gráficos: SVG (Scalable Vector Graphic). Si lo que necesitás es transmitir dibujos (un torta estadística, un gráfico de barras o a Súper Mario Bros), este formato viene siendo de a poco soportado por más y más aplicaciones. Tiene una gran virtud por sobre los bitmaps que es, como su nombre expresa, que escala. Es decir, agrandás el dibujo y no se ven los pixels, lo reducís y no se pierde nitidez


    La revancha del ICQ: de ser una aplicación de escritorio, instalable, ICQ probó luego ser un
    applet Java pero finalmente se quedó en su versión vectorial (basada en Flash) y disponible
    en http://go.icq.com

Podría mencionar acá también a los Gadgets y los Mashups, pero en tanto la componente visual es realmente tan notoria, voy a cubrirlos en mayor detalle en Que No Se Retove el Usuario (próximo post de la serie). Pero sin duda que completan la idea global de este post

Para cerrar el post, algo a tener muy en cuenta cuando tomamos pedazos de otro para nuestra aplicación, directamente de su sitio, es que nuestro "socio" podría no estar disponible justo en el momento en que lo estamos queriendo acceder. Esto en términos de "Web 2.0" es "oh, qué garrón, yo quería entrar ahora". En cambio en términos de "Enterprise 2.0"… no, olvidalo: en "Enterprise 2.0" no podés darte ese lujo porque la experiencia de usuario cuenta mucho, y además tu competencia está a unos pocos clicks de distancia del frustrado usuario como para que tu oportunidad se le vaya a él (el usuario quizás ni se percate de que no sos vos el que anda con problemas porque sencillamente ni se haya enterado que estás usando piezas de terceros)

Para afrontar esto, ya son varios los proveedores de partes re-usables que ofrecen planes premium atados a un acuerdo de nivel de servicio (Service-Level Agreement o SLA). Claro que, en ese caso… poniendo estaba la ganza: hay que pagar

Nos volvemos a encontrar para proseguir con esta serie

Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Una respuesta a [Serie] Enterprise 2.0: Parte 2- Elogio del Choreo

  1. Gabriela dijo:

    Excelente

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s