Inicio > General, VAR & Channel > Multichannel Access Gateway

Multichannel Access Gateway

¿Qué es una MAG?

Un Portal de Acceso Multicanal (MAG) provee el middleware crítico para dejar que las aplicaciones de oficina puedan ser utilizadas en ambientes cableados e inalámbricos a través de un único portal de acceso. Una MAG es un puente necesario para la convergencia para asociar sistemas del backend, diferentes dispositivos móviles, diferentes sistemas operativos y centenares de redes diferentes cada uno con atributos diferentes.

 

Acerca de Portal de Acceso Multicanal (MAG)

Una MAG es una plataforma de software residente en el cliente y en el servidor que extienden la funcionalidad de los sistemas de escritorio, basados en servidores para dispositivos móviles.

Las MAG pueden interconectar con múltiples sistemas esporádicos y disímiles de una empresa, pueden comunicar la información a una gran variedad de dispositivos por una multitud de redes, y pueden dejar a los empleados móviles acceder a los accesorios periféricos que requieren en el campo. Estas capacidades son permitidas en un set solo de comercial código lógico y aplicativo.

Una MAG le proveerá una plataforma arquitectónica que le permite definir su táctica de desarrollo de soluciones del móvil.

 

Ya es hora que las empresas se decidan por una arquitectura estratégica para soportar todo el espectro de soluciones de computación móvil. Este movimiento es llamado “Getting Mobility Right” y consideran que las empresas deben dejar de trabajar con soluciones fragmentadas que no requirieron un compromiso global, para pasar a una arquitectura estratégica móvil de punta a punta dentro de la organización.

 

También es necesario remarcar: “Ninguna Arquitectura” ahora no es una opción. Esta es la posición previa, en ausencia de arquitecturas centralizadas robustas, las implementaciones móviles deberían tener en cuenta:

 

Mientras que antes nos preocupábamos por llevar las soluciones al lugar de trabajo, fuera de la oficina, hoy, la diversidad de soluciones es tan basta que en realidad debemos ocuparnos de la convergencia.

 

¿Y cuál es el punto de convergencia? Es necesario que comencemos a hablar acerca de la tecnología del corazón de una arquitectura móvil — algo llamado el Portal de Acceso de Multicanal (Multichannel Access Gateway) o MAG para abreviar. Los MAG, se advierte, no son soluciones como Research in Motion’s Blackberry Enterprise Server o Microsoft’s Mobile Information server.

 

Más bien, una MAG es una forma de middleware que facilita en forma agnóstica de la red (LAN, WAN, WWAN, etc.)  la conectividad entre múltiples, desintegrados y algunas veces disímiles sistemas de empresariales y, en el cliente encontramos un inmenso rango de dispositivos (Hand Held robustos, PDAs, Notebooks, teléfonos, etc).

 

El contenido podría ser información de texto, audios, o video. Cualquiera de estas cosas montadas sobre cliente y el middleware debe cubrir la integración hacia atrás, facilitándolo en cualquier momento, dondequiera, y con cualquier acceso del dispositivo hacia la información corporativa. Lo que vemos es que, “las Soluciones móviles no construidas en una arquitectura multicanal en el futuro costarán dos veces más durante su ciclo biológico que una solución similar basados en portales de acceso multicanal”.  En otras palabras, una estrategia fragmentada que implicar una desordenada estrategia en el desarrollo de soluciones móviles es realmente mala idea.

 

Para ayudar a los tecnólogos corporativos a compartimentar arquitecturas móviles, en categorías con características bien definidas, sus pros y contras, definimos seis estilos fundamentales de Arquitecturas Móviles:

 

 

Cliente Grueso — Esto supone trabajar con dispositivos con capacidad y recursos locales (Hand Held, PDAs, Smartphones, y PCs), los clientes gruesos son muy adecuadas para aquellos entornos donde los usuarios finales deben trabajar con datos cuando en lugares donde ninguna red está disponible y dónde la seguridad de los datos es una preocupación primaria (esta solución nos da la posibilidad de contar con una rango muy amplio de opciones para asegurar los datos).  Sin embargo, como negativo, podemos decir que el costo está relacionado con la sofisticación y complejidad. Es la opción más cara, pero la de más alta calidad de servicio.

 

Cliente Rico — En esta opción, el código puede residir en el dispositivo, pero no los datos — al menos no una gran cantidad de datos. Los mejores ejemplos podemos verlos en algunas soluciones verticales como las que usa FedEx y UPS. Sin embargo, se menciona BREW y la edición móvil de Java (J2ME) como una plataforma horizontal con características de un cliente rico dentro de una MAG. Pero dada la diversidad de versiones de J2ME existentes y el grado de sofisticación que requiere trabajar con todos ellos, también se advierte que J2ME es un desorden. Recomendamos implementaciones con cliente rico cuando “usted necesite mejorar usabilidad respecto de implementaciones con clientes delgado, pero mejorar el TCO respecto de implementaciones con clientes gruesos.

 

Cliente Delgado — Si bien no poseen la usabilidad como la que se puede obtener con clientes ricos o gruesos, el punto principal de venta de una solución con cliente delgado es el amplio rango de dispositivos soportados, mayormente debido a la confianza en la tecnología estándar del lado del cliente como los navegadores de HTML o XHTML o la versión móvil de Flash (Flash Ligth).  Los clientes delgados no requieren datos ni código persistente del lado del dispositivo, pero sufren completamente una crisis nerviosa cuando se pierde la conectividad con la red. Tambien, hay también menos opciones de seguridad (EJ: VPN o HTTPs) pero las buenas noticias son que el TCO es dramáticamente menor (respecto a clientes ricos o gruesos).

 

Streaming — Streaming es algo como la arquitectura de cliente delgado en lo que a software en el cliente se refiere pero esta arquitectura es ampliamente asociada con de los medios de comunicación y entretenimiento.  Es primordialmente una arquitectura con flujo de datos de ida pero no de regreso, adecuándola en ambientes corporativos, podríamos pensar en necesidades específicas como entrenamiento. En lo negativo, Streaming requiere una buena cantidad de ancho de banda y redes de baja latencia (no es exactamente algo que podamos encontrar en redes inalámbricas ciudadanas (GPRS)).  

 

Messaging – Confinado para aplicaciones limitadas como el correo electrónico o SMS messaging, el envío de mensajes se encuentra restringido para necesidad mas sofisticación como algo transaccional. La solución final comienza a parecerse a un cliente rico, o la carga es colocada en los usuarios finales dándole forma a los mensajes de acuerdo a algo que la sabra reconocer la infraestructura que se encuentra detrás. La seguridad puede o no ser una preocupación aquí, al confiar en mecanismos por correo electrónico propietarios como los ofrecidos por RIM o Microsoft. Pero el servicio de SMS sobre redes inalámbricas públicas no ofrece el tipo de seguridad que muchas aplicaciones requieren. Desde el punto de vista del TCO, seguramente es una opción barata

 

Ningún cliente – Es aplicable mayormente para las situaciones telefónicas simples donde el discado basado en tonos o el reconocimiento interactivo  de voz (IVR) son suficientes. Sin tecnología del lado del cliente por la que preocuparse, la arquitectura “Sin ningún cliente” es uno de las alternativas más baratas e implica que toda información puede ser transportada en un formato audio. Es fácil de implementar y desde el punto de vista de usuario final, en todo el mundo se encuentran familiarizados con teléfonos por tono.

 

 

En un punto, muchos indican que si bien llego más tarde, Microsoft’s Mobile .NET es mejor elección que la arquitectura SUN J2ME.  Técnicamente hablando, dado el grado de control que Microsoft tiene sobre .NET, esto puede ser cierto. Pero desde un punto vista de disponibilidad del dispositivo, J2ME es mejor para los desarrolladores cuando usted considera la gran variedad de dispositivos que incluyen la tecnología hoy. El problema con el que nos encontramos, y por lo que se dice que J2ME es un desorden, es que J2ME está muy fragmentado cuando comparamos específicamente distintos dispositivos. Sin embargo se espera que esto mejore en el corto plazo.

 

  1. Aún no hay comentarios.
  1. No trackbacks yet.

Deja un comentario

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

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

A %d blogueros les gusta esto: