VIENE DE: COMUNICACION >> ARTICULOS
Luis Esteban, Jefe de División Converged Communications & Building Blocks
Por Luis Esteban, Jefe de División Converged Communications & Building Blocks, Callware Voice Technologies
A lo largo del último quinquenio estamos viviendo lo que sin duda podemos calificar como una transformación espectacular en lo que en su día conocíamos como herramientas de desarrollo de aplicaciones vocales. Este cambio afecta no solo a las propias plataformas sino también al ecosistema completo, surgiendo nuevas tecnologías, nuevos players y cambiando dramáticamente lo que el usuario final, el propietario de los servicios, y las compañías que los desarrollan demandan de estas plataformas. No menos relevante es el cambio en la naturaleza de los servicios que se despliegan hoy en día, que comienzan a dar los primeros pasos para integrarse con lo que conocemos como Web 2.0
En su origen las aplicaciones predominantes eran exclusivamente aplicaciones vocales, en las cuales el usuario interaccionaba mediante DTMF o ASR y se reproducían o grababan mensajes. Estas aplicaciones se ejecutaban en base a servidores estándar utilizando hardware específico para realizar las tareas de media processing y que a su vez eran los interfaces con la PSTN. El desarrollo se llevaba a cabo mediante APIs propietarios entregados por el fabricante de estas tarjetas y posteriormente por herramientas de más alto nivel que típicamente permitían realizar el desarrollo mediante un interfaz grafico sin necesidad de escribir código.
El desarrollo tecnológico hace que los nuevos servicios empiecen a combinar voz y video: portales de video, video messaging, video greetings, video conferencia y unos particularmente novedosos servicios que permiten la visualización en el terminal 3G de contenidos web. No se trata en este caso de pura transmisión de archivos de video “enlatados” sino de la visualización de la misma página a la que accederíamos mediante un navegador web pero convenientemente adaptada al tamaño y características de la pantalla de nuestro terminal móvil 3G. Surge así la posibilidad de integrar los aplicativos de automatización con la Web 2.0.
Tecnológicamente hablando las nuevas plataformas de desarrollo se caracterizan por los siguientes aspectos diferenciales:
- Desaparece la necesidad de elementos hardware dedicados al media processing, permaneciendo transitoriamente la necesidad de elementos para conectar a la PSTN: están pasan a ser plataformas puramente software.
- Arquitecturas distribuidas: frente a las plataformas monolíticas y centralizadas en la cual todos los elementos y funcionalidades residen en ella, surgen arquitecturas distribuidas y mucho más flexibles. En estas se diferencia claramente entre los roles de cada uno de los componentes de la solución y se definen interfaces de comunicación entre ellos estándar y basados en IP.
Estas arquitecturas solucionan problemáticas como la escalabilidad y la redundancia y permiten la posibilidad de seleccionar ciertos componentes entre múltiples fabricantes que soporten dichos interfaces estándares sin necesidad de ceñirse a uno único. El ejemplo más claro de este concepto es el IP Multimedia Subsystem (IMS). Aparecen así elementos como los media servers, signaling y media gateways y como elemento clave los Application Servers.
Application Servers
El Application Server es el nuevo paradigma de lo que antes conocíamos como plataformas de desarrollo de servicios (SDP). Se puede definir como un elemento software que provee de un framework para la ejecución eficiente de aplicaciones. Su misión no debe de ningún modo limitarse a la ejecución de las aplicaciones sino que debe cubrir todo su ciclo de vida: diseño, desarrollo, testing, despliegue, provisioning y monitorización.
En esta arquitectura, múltiples aplicaciones pueden ejecutarse de forma concurrente sobre el mismo Application Server, que se encarga de asignar los recursos que cada una de ellas demanda. Asimismo se encarga de dialogar con el resto de elementos de la arquitectura distribuida antes mencionada de forma transparente a las aplicaciones. El tener un punto único para administrar las aplicaciones arroja ventajas como la seguridad, la simplicidad de los upgrades, la gestión de versiones, y facilita la provisión de una plataforma tolerante a fallos mediante la redundancia del Application Server. Adicionalmente debe proveer integración otras tecnologías como las siguientes: bases de datos, sistemas de email, SMS, ASR o TTS, sistemas de billing o SNMP.
Los Application Servers deben ser capaces de ofrecer un amplio espectro de posibilidades a la hora de elegir el API con que se debe desarrollar con el fin de facilitar la interoperabilidad con el mayor número posible de application vendors y permitir la portabilidad de aplicaciones. Existen múltiples posibilidades aunque las más difundidas son:
- Entorno gráfico de creación de servicios (SCE): se suministra un entorno en el cual las aplicaciones se desarrollan de forma gráfica mediante la concatenación de módulos predefinidos con una cierta funcionalidad y que solo necesitan ser parametrizados. Es una forma sencilla, rápida y eficiente de crear una aplicación. Estas aplicaciones no serian portables a otras plataformas a no ser que por debajo generaran cierto código en un API estándar que si pudiera ser ejecutado en otro Application Server. Habitualmente el desarrollador puede crear nuevos módulos mediante lenguajes de programación estándar de tal forma que se considera que es un entorno abierto y extensible
- Un subgrupo muy relevante de Application Servers se basan en tecnología Java Enterprise Edition (J2EE). J2EE es una plataforma de programación para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java basándose en componentes de software modulares ejecutándose sobre un servidor de aplicaciones.
- VoiceXML es un lenguaje de etiquetas basado en XML que permite describir aplicaciones vocales con independencia de la plataforma en la que corran. De esta manera no es necesario conocer detalles específicos de una plataforma para entender el funcionamiento del sistema de diálogo. La utilización del estándar promueve la integración de estos sistemas en los llamados Web Services, así como el aseguramiento de su portabilidad y la construcción de herramientas que faciliten al usuario la definición de servicios de diálogo. De la misma forma que un documento HTML es interpretado por un navegador web, los documentos VXML son generados por un servidor web y posteriormente interpretados y ejecutados por un Voice Browser que pude residir en el Application Server o ser un elemento complementario a este. En el caso de que se requiera realizar un call control más complejo, que incluya por ejemplo transferencias, es necesario utilizar otro scripting language llamado CCXML.
Web Services
Antes de definir que es un Web Service pensemos primero en qué es un servicio. Cualquier proceso, no solo en el ámbito IT, puede descomponerse en una serie de elementos que realizan cada uno una tarea determinada con un resultado concreto: cada uno de esos elementos pueden ser definidos como un servicio.
Diagrama Web Services
Los Web Services trasladan este concepto al mundo web. En lugar de diseñar macro-aplicaciones muy complejas se trata de crear pequeñas aplicaciones que prestan un servicio muy específico y que pueden ser reutilizadas por otras para crear nuevas aplicaciones. Por ejemplo una aplicación on-line puede constar de un servicio principal A, y de la interacción con otros servicios B y C, localizados en otro servidor y desarrollados por un tercero, y que están disponibles para cualquier otro. De esta manera el uso del software se hace reutilizable ya que distintos servicios pueden ser combinados de múltiples formas y ser utilizados como componentes de una aplicación. Un concepto interesante surgido a partir de este filosofía es el de Mashup, del que se habla cuando una aplicación web usa contenido de otras aplicaciones web para crear un nuevo contenido completo, consumiendo servicios directamente, siempre a través de protocolo http. A su vez un mashup puede utilizarse para crear un nuevo mashup y podríamos empezar a hablar de “mashups de mashups”.
También se suele definir un Web Service como el conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones que colaboran entre sí. Obviamente el concepto de reutilización sería inútil sin que los interfaces para acceder a los web services no estuvieran claramente estandarizados. Entre otros se han definido los siguientes:
- WSDL (Web Services Description Language): es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con un web service. Es la declaración publica que cualquier servicio web debe hacer para que otros sepan como acceder a él y que resultados va a entregar este
- SOAP (Simple Object Access Protocol) : es el protocolo sobre el que se establece el dialogo entre web services
- XML (Extensible Markup Language): formato estándar de los datos que se intercambian.
Integración de aplicaciones vocales y la Web 2.0
Llegados a este punto parece necesario el plantearse cómo establecer el nexo entre las aplicaciones vocales y los web services. La alternativa más inmediata es utilizar un Application Server con soporte para los protocolos arriba mencionados.
Integración de aplicaciones vocales y la Web 2
Un ejemplo es OmniVox3D de Apex Voice Communications. Se trata de un Application Server que implementa la arquitectura distribuida descrita anteriormente, con un elemento central que es un SIP Session Manager que trabaja como un Back-to-Back User Agent (B2BUA) y que está diseñado específicamente para soportar entornos mixtos TDM e IP. Uno de sus componentes es OmniView, un entorno gráfico de creación de servicios que posee un módulo predefinido para dialogar con Web Services. Este módulo permite invocar dentro del flujo de una llamada cualquier web service estándar identificado mediante un URL. Permite transmitirle información, recibir el resultado generado por este y utilizarlo posteriormente en la aplicación.
Otra forma de interaccionar con la Web 2.0 es la que ofrece el Dynamic Video Generator (DVG) de OmniVox3D. DVG es otro módulo con funcionalidad ya definida presente en OmniView y esta creado para generar contenidos de video para un IVVR. DVG produce este contenido a partir de templates HTML alojados en un servidor web. Estos templates se utilizan para generar video mediante una combinación de texto, GIF, JPEG, PNG y Scalable Vector Graphics (SVG). Puesto que DVG carga estos templates en cada llamada accediendo al servidor web mediante HTTP, este contenido puede ser generado dinámicamente utilizando cualquier lenguaje de programación web tipo ASP o PHP.
Esqema de Integración entre aplicaciones vocales y la Web 2
DVG puede utilizarse para crear pantallas personalizadas que son entrelazadas con mensajes vocales para proporcionar al usuario del servicio que accede a través de un terminal 3G o un softphone SIP una mejor experiencia.
Ejemplos de aplicación que utilizan DVG son los siguientes;
- Acceso a Google Maps para que el usuario pueda ver en su pantalla el mapa que desee e incluso interaccionar y desplazarse a través de él.
- “3G Finance” que utiliza el Web Service de “Google Finance” para construir un grafico “on the fly” del movimiento del mercado.
- “3G Weather” que utiliza el Web Service de “X-Methods”.
Dynamic Video Generator
