Al hablar de la web 2.0 es difícil salirse de la visión no empresarial de este movimiento. En este caso vamos a hablar de este fenómeno desde la óptica estrictamente empresarial. Concretamente nos centraremos en los aspectos que pueden enriquecer nuestros sistemas y procesos corporativos utilizando técnicas y conceptos derivados de la revolución web 2.0.

El término ‘web 2.0’ fue originalmente acuñado por Dale Dougherty de O`Reilly Media durante un Brainstorming en una conferencia. Dale Dougherty utilizó este término para describir todo el conjunto de nuevos web con funcionalidades “sorprendes”.

En la actualidad se entiende la web 2.0 desde dos perspectivas:

• La primera engloba todos aquellos sitios web donde el usuario o cliente pasa de un papel más pasivo (lector) a un papel más activo (generador de contenido). Este tipo de sitio web sirven como vehículos para facilitar que sean los propios clientes los que creen el contenido o enriquezcan el mismo. Los ejemplos quizás más famosos son www.wikipedia.org o www.youtube.com.
• La otra perspectiva clasifica un sitio web o aplicación web como ‘Web 2.0’ si utiliza un conjunto de técnicas, tecnologías o enfoques propios de este movimiento. En este artículo nos vamos a centrar ésta perspectiva.

En general las técnicas, conceptos o tecnologías web 2.0 aplicadas a los sitios web corporativos hacen que estos sean altamente interactivos y permiten experiencias de marca más bidireccionales y participativas.

La alta interactividad, característica casi obligatoria en las nuevas aplicaciones web corporativas, se basa en el uso de tecnologías que permiten construir aplicaciones RIA (Rich Internet Applications – Aplicaciones Internet Ricas). Con éstas tecnologías evitamos que cada vez que el usuario interactúe con el interfaz de usuario se produzca una recarga de página, forzando al usuario a esperar innecesariamente. Además podemos ir más allá del modelo “clic-esperar-refrescar” permitiendo experiencias que tradicionalmente sólo estaban disponibles en entornos cliente-servidor con interfaces de usuario pesado. Experiencias como “arrastrar y soltar”, “cortar y pegar” o “gráficos interactivos” ya son posibles en aplicaciones web.

Las tecnologías RIA más utilizadas en la actualidad son AJAX, Adobe Flex y Microsoft WPF.

La segunda óptica anteriormente mencionada percibe la Web 2.0 como la aplicación en la web tradicional de un conjunto de técnicas y enfoques innovadores.

A continuación definimos algunos de estos conceptos o técnicas y esbozamos las posibles aplicaciones en el mundo empresarial:

• Wikis: Se entiende por un wiki un conjunto de páginas web accesibles y modificables por cualquier usuario. Este tipo de sitios web son de especial utilidad para crear una base de datos de conocimiento corporativo de manera cooperativa. En otros ámbitos este tipo de webs permiten al cliente participar en la construcción del producto aumentando la información disponible sobe el mismo. El Wiki más famoso es http://www.wikipedia.com.
• Blogs: Un blog es una página web donde uno o varios autores publican periódicamente noticias relacionadas con un tema en concreto. Adicionalmente existen los squizzer blogs que son blogs que tratan múltiples temas. En la actualidad muchas organizaciones fomentan la creación de blogs corporativos por parte de sus empleados. Estos blogs pueden ser para consumo interno o para consumo externo. Una buena manera de atraer a nuestros clientes a nuestro sitio web es un blog que trate temas afines a nuestro público objetivo. La combinación Blog + RSS o Atom (ver “syndication” más adelante) permite atraer a los lectores del blog publicando los cambios en el mismo directamente en sus respectivas aplicaciones de escritorio.
• Syndication: Es un proceso por el cual un sitio web comparte contenido con otros. El proceso normal es crear un web feed (una fuente de contenido RSS o ATOM) con los resúmenes de los cambios en el sitio web de tal manera que los agregadores puedan subscribirse a dicho canal. Así podrán conocer de primera mano los cambios introducidos y actualizar su contenido como proceda.
• RSS: Un RSS es una fuente de contenido web periódico (web feed) que envía la información en un formato estandarizado (RSS 2.0 Specification). Gracias a que el formato de la información está estandarizado los lectores/usuarios pueden integrar sus RSS preferidos en un único lector como Outlook, para así acceder a los mismos sin necesidad de visitar cada sitio web individualmente. Una buena idea es ofrecer las noticias corporativas a nuestros clientes o empleados como un canal RSS en la propia web.
• Atom: Es un formato XML para crear una fuente de contenido periódico en un formato estandarizado. Es muy similar a RSS y actualmente convive con este último auque en teoría fue diseñado para sustituirlo. Atom tiene más funcionalidades que RSS 2.0. Además, el estándar RSS 2.0 está “congelado” y está previsto que las mejoras sobre el mismo se realizarán mediante la creación de nuevos protocolos como ha sido el caso con Atom. Una de las principales diferencias entre RSS 2.0 y Atom es que este último permite contenido binario codificado en base64 y, lo que es más importante, XML. La posibilidad de crear un canal XML amplía notablemente los posibles usos de la sindicación mediante Atom.
• Podcasting/Videocasting: Un podcast es un mensaje corporativo en formato mp3 (o en formato vídeo en el caso de un videocast) que se distribuye a través de una fuente Atom de tal manera que el público objetivo pueda reproducirlo en cualquier otro momento y en cualquier dispositivo compatible. Hoy por hoy, el vídeocast poco a poco se está convirtiendo en el formato adecuado para enviar mensajes corporativos a los distintos públicos de la empresa. Es común encontrar en la web pequeños vídeocasts demostrativos de productos, versiones de los anuncios de las compañías, etc… Además, el componente viral inherente en Internet puede hacer que nuestro mensaje se transmita a través de canales tan populares como YouTube y alcance grandes cuotas de notoriedad.
• Content Tagging: Es una facilidad presente en algunos sitios web que permiten al usuario etiquetar el contenido según su propio criterio. Esta meta-información permite enriquecer notablemente las búsquedas que se realizan tanto en la web como en la intranet. Este tipo de funcionalidades ya está presente en muchos gestores documentales corporativos.
• Marshups: Un marshup es un sitio web que crea contenido nutriéndose del contenido generado por otras webs. Un ejemplo de ésta técnica es incluir una página en nuestro sitio web con un mapa de google maps customizado para que aparezcan nuestras sedes. El buscador por excelencia en el mundo del content tagging es http://del.icio.us/ y quizás el proveedor para marshups más utilizado es http://maps.google.com.
• Social networking: Muchas de las técnicas anteriormente citadas tienen como consecuencia la creación de sitios web que representan verdaderas comunidades de usuarios que comparten experiencias y actividades. Normalmente este tipo especializado de sitios web ofrecen múltiples herramientas de comunicación a sus usuarios: chat, email, foros de discusión, vídeos, podcasts … Quizás el más famoso de estos sea http://www.myspace.com. Algunas intranets de empleado funcionan como una verdadera social network puesto que van más allá del concepto tradicional de repositorio de información y crean una comunidad de empleados donde estos pueden trabajar cooperativamente en entornos multiculturales.

La plataforma web se ha convertido en la plataforma estándar para el desarrollo de aplicaciones.

En paralelo a éste proceso, ha aumentado la demanda de aplicaciones altamente interactivas que la plataforma web tradicional difícilmente puede satisfacer. Cada vez se demandan más aplicaciones web con una interactividad semejante a las aplicaciones desktop tradicionales.

Las nuevas aplicaciones web deben lidiar con:

• Complejidad de proceso: A la hora de implementar procesos no lineales que requieren múltiples pasos, se suele optar por su división en etapas y mapear las mismas a páginas web individuales. Este modelo requiere mucha navegación hacia delante y hacia atrás para poder completar el proceso, lo que se traduce en una experiencia lenta y frustrante. El modelo de página es válido para flujos lineales. De esto se deduce que hace falta un modelo para abordar procesos complejos.
• Complejidad de los datos: Es necesario nuevas formas de presentar los datos. Las aplicaciones deben permitir ver y manipular datos intrínsecamente relacionados, por niveles de detalle.
• Personalización de la presentación: Cada vez se requiere más ofrecer aplicaciones que permitan al usuario personalizar los productos entre cientos o miles de alternativas (por ejemplo nike id).
• Complejidad de la escalabilidad: El modelo tradicional de página requiere, que se refresque toda la página cada vez que se actualiza el interfaz de usuario. Refrescar toda página (incluyendo imágenes) tiene un impacto determinante en la escalabilidad de las aplicaciones. Si solo se refrescara las partes que cambian, se podría atender las mismas peticiones pero con menores recursos. El rendimiento en momentos punta sería mucho más eficiente que en la actualidad a pesar del uso de caches.
• Complejidad del feedback: La alta interactividad de las aplicaciones está reñida con el modelo “click-esperar-refrescar”. Este modelo interrumpe la interacción mientras dura el refresco.

Para representar ésta complejidad de la interacción con el usuario ha surgido RIA.

RIA es el acrónimo de Rich Internet Application (Aplicación de Internet rica).

Es parte de la filosofía Web 2.0, la segunda generación de servicios basados en Internet, que permite que los usuarios colaboren y compartan información online. Web 2.0 se concibe como una mejora sobre la World Wide Web. En ésta nueva ‘versión’ de la www se incluyen mejoras como los BLOGs, tagging …

RIA esencialmente permite desarrollar aplicaciones web de alta interactividad. Mejora la experiencia de los usuarios al trabajar con aplicaciones intranet/Internet, partiendo de la base de que cuanto mejor sea la experiencia con una aplicación mayor será la satisfacción del usuario. Cuanto más interactivo sea el interfaz de usuario de un sistema, mejor será la experiencia de uso y, por lo tanto, mayor la satisfacción en el usuario.

AJAX es el acrónimo de Asynchronous Javascript and XML. AJAX es una forma de programar y un estilo arquitectónico que permite desarrollar aplicaciones de interactividad similar a las desktop con tecnologías web.

Existe una gran variedad de ventajas en el uso de AJAX:

• Mejora la experiencia de usuario manteniendo las ventajas del deploy de aplicaciones en servidores:
  • Administración centralizada
  • Disponibilidad inmediata de los cambios a todos los usuarios.
• Disminuye los tiempos de espera de recarga de páginas mejorando la productividad del usuario
• Los tiempos de ejecución de las tareas también disminuyen al eliminarse la espera por recarga de páginas.
• No supone una ruptura tecnológica total y puede convivir fácilmente con los sistemas web existentes.
• Menor consumo de ancho de banda, disminución del tiempo latencia (se usa el ancho de banda para datos).
• Mejora de la escalabilidad al eliminar proceso en el servidor
• No es necesario plugin en el navegador

Principales frameworks

• DWR (Direct Web Remoting):
• Simplifica la comunicación entre browser y servidor web
• Clase Java de Servicio -> Recubrimiento JS (función remota se ejecuta en browser como si fuera función js)
• Se encarga de diferencias browser y transformaciones parámetros
• Integración fácil con aplicación existente (1 jar + 1 servlet punto de entrada + correspondiente fichero de configuración)


• GWT (Google Web Toolkit):
• Desarrollo Java -> conversión JavaScript AJAX
• Subconjunto del jre (java.lang y java.util) y widgets propios.
• Soporta todos los navegadores
• No es completamente abierto
• Aplicaciones 2 modos ejecución: hosted (JVM) o web (browser)
• Depuración se realiza en java (modo hosted)


• ASP.NET AJAX antes conocido como Microsoft Atlas:
• Consta de una librería cliente y un conjunto de componentes del lado servidor.
• Los componentes se integran en Visual Studio.
• Permite a los desarrolladores ASP.NET integrar AJAX fácilmente.
• No supone una ruptura, es un añadido.
• La librería cliente se puede utilizar en desarrollos client-centric.


• Open Lazslo:
• Es Opensource
• Se desarrolla en XML (OpenLazslo LZX) y javascript
• Es posible generar FLASH o AJAX
• Tiene un rico conjunto de componentes

Herramientas complementarias

• JSLint: comprobador de sintaxis y validador mucho más restrictivo que estándar (convención de nombres y estructuras prohibidas)
• AJAX Toolkit Framework (ATF): plugins eclipse para edición, depuración y monitorización aplicaciones AJAX
• Venkman JavaScript Debugger: Depurador de javascript para Mozilla FireFox
• FireBug: Plugin para debug de JavaScript, DOM, CSS en FireFox
• JsUnit: Porting de Junit a Javascript
• JsMock: Librería para pruebas con Mock Objects (objetos que simulan comportamientos anómalos)

Experiencia web tradicional

Tradicionalmente se ha contado con un modelo de navegación por páginas, con una iteración del usuario del tipo “click --> espera --> refresca”:

• Cada vez se refresca la página por completo
• La carga y el consumo de ancho de banda excesivo. Cada envío de datos requiere retransmitir todo, datos y presentación.
• La interacción con el usuario se detiene cada vez que se envían datos. El usuario tiene que esperar y no hay feedback inmediato.
• Interactividad reducida, no hay controles avanzados de manipulación de datos (data grids con ordenación) …
• No es recomendable para interacciones basadas en eventos, es el usuario el que determina qué información y cuándo recuperarla.
• Modelo de comunicación síncrono “request-response”.

Experiencia de alta interactividad

La Web 2.0, a través de su paradigma RIA, permite desarrollar interfaces de usuarios avanzadas, de alta interactividad, con tecnología web (sin el tradicional proceso de distribución). Se trata de crear aplicaciones que permitan una interactividad semejante a las aplicaciones desktop (word por ejemplo) pero con tecnologías web de última generación.

Éste nuevo modelo permite una respuesta rápida (ya no es necesario recargar cada página cada vez) y feedback instantáneo. La interacción ocurre naturalmente, no es necesario hacer click para recargar. Tras la carga inicial, la interacción dispara la actualización de una parte de la página (por ejemplo, el contenido de una lista desplegable) en vez de recargar toda la página. Solo aquellos elementos que puedan contener información nueva se refrescan.

La aplicación web ya no solicita páginas, solicita solo los datos que se necesitan, lo cual reduce la cantidad de datos que se transmiten y por lo tanto el ancho de banda necesario. Ya no es necesario transmitir continuamente los datos y la presentación.

Las solicitudes no detienen la interacción del usuario, las peticiones particulares se realizan de manera asíncrona. Ya no hay interrupciones largas, ni transiciones bruscas. En general el usuario espera menos y las peticiones al servidor son más numerosas pero más ligeras.

Desplaza parte de la carga del servidor al cliente, ahorrando CPU en el servidor y ofreciendo mejores tiempos de respuesta al usuario. Las aplicaciones RIA pueden contar con proceso de datos en el cliente.

La interacción está dirigida por eventos con un modelo de comunicación asíncrono. El usuario puede continuar utilizando el interfaz de usuario, sin interrupciones, porque las peticiones se realizan en segundo plano. Las aplicaciones RIA pueden mantener en cache datos y utilizar servicios solicitud/respuesta para realizar operaciones.

Proporciona una capa de presentación a los Web Services, pieza fundamental SOA, y es probable que tanto las aplicaciones desktop tradicionales como las web converjan hacia ésta tecnología.

Nuevo estilo arquitectónico para diseñar aplicaciones web. Habla de cómo debe ser la interacción entre el cliente y el servidor. Permite ofrecer un “interfaz uniforme”, fácil de entender por todos los potenciales clientes.

Requiere un cambio de enfoque a la hora de diseñar el interfaz de los servicios de la aplicación. En vez de centrarse en definir un API de métodos y parámetros, se definen recursos de información sobre los que se podrán realzar un conjunto preestablecido de acciones (recuperar, insertar, actualizar y eliminar).

A modo de ejemplo, supongamos que estamos diseñando un servicio de gestión de usuarios (este ejemplo ha sido sacado de la Wikipedia).

• En el enfoque API o RPC, definiríamos las acciones que se pueden realizar. En este caso en concreto se prevé el protocolo cliente-servidor resultante sería:
• getUser()
• addUser()
• removeUser()
• updateUser()
• getLocation()
• addLocation()
• removeLocation()
• updateLocation()
• listUsers()
• listLocations()
• findLocation()
• findUser()
• En el enfoque REST bastaría definir los recursos sobre los que se van a realizar las operaciones. Las operaciones posibles están ya preestablecidas en REST (PUT, GET, POST y DELETE). Desgraciadamente el protocolo HTTP no define operaciones para manejar conjuntos de recursos (operaciones list*). Ésta limitación se solventa definiendo recursos para definir los propios conjuntos.
• User
• Localization
• UserList
• LocalizationList.

Cada objeto REST se denomina “recurso” y la información contenida en el recurso se denomina “estado”. Este estado debe ser codificado para poder enviarse en los mensajes HTTP. Estos estados codificados se denominan “representaciones”. El MIME-TYPE es parte del interfaz ya que indica el formato en el que se desea la información.

Un aspecto importante de la interacción siguiendo las reglas de REST es que ésta no ha de tener estado. Es decir, cada mensaje se puede procesar sin requerir información de un mensaje anterior (salvo en el caso del método POST). Esto facilita a posterior el uso de los distintos tipos de caché existentes.

Las interacciones estándares son las siguientes (coinciden con los verbos del protocolo HHTP):

• GET, equivale a “Dame tu estado en un determinado formato”. No tiene efectos secundarios y es ídempotente.
• PUT, equivale a “Cambia tu estado interno por el contenido del mensaje anexado”. Puede tener efectos secundarios y es idempotente.
• POST, equivale “Crea un nuevo recurso”. Puede tener efectos secundarios y NO es idempotente.
• DELETE, equivale a borrar un recurso. Puede tener efectos secundarios. Es idempotente.

En el contexto en el que nos movemos idempotente significa que aunque se envíen n transacciones iguales sobre un recurso REST solo se procesará una de ellas. Esto facilita enormemente los reintentos y recuperación de errores.

La lógica inherente a los cambios de estado es transparente para el cliente del servicio REST. Realmente dicha lógica de negocio se ejecuta como un efecto secundario del cambio de estado del sistema. Por ejemplo: Pasar un pedido del estado actual a pagado (mediante un PUT) puede implicar interfaz con el subsistema logístico para planificar su envio.