Un Portal de Acceso Multicanal (MAG – Multichannel Access Gateway) provee el middleware cr\u00edtico para dejar que las aplicaciones de oficina puedan ser utilizadas en ambientes cableados e inal\u00e1mbricos a trav\u00e9s de un \u00fanico portal de acceso. Una MAG es un puente necesario para la convergencia para asociar sistemas del backend, diferentes dispositivos m\u00f3viles, diferentes sistemas operativos y centenares de redes diferentes cada uno con atributos diferentes.<\/p>\n
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\u00f3viles.
\nLas MAG pueden interconectar con m\u00faltiples sistemas espor\u00e1dicos y dis\u00edmiles de una empresa, pueden comunicar la informaci\u00f3n a una gran variedad de dispositivos por una multitud de redes, y pueden dejar a los empleados m\u00f3viles acceder a los accesorios perif\u00e9ricos que requieren en el campo. Estas capacidades son permitidas en un set solo de comercial c\u00f3digo l\u00f3gico y aplicativo.
\nUna MAG le proveer\u00e1 una plataforma arquitect\u00f3nica que le permite definir su t\u00e1ctica de desarrollo de soluciones del m\u00f3vil.
\nYa es hora que las empresas se decidan por una arquitectura estrat\u00e9gica para soportar todo el espectro de soluciones de computaci\u00f3n m\u00f3vil. 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\u00e9gica m\u00f3vil de punta a punta dentro de la organizaci\u00f3n.
\nTambi\u00e9n es necesario remarcar: \u201cNinguna Arquitectura\u201d ahora no es una opci\u00f3n. Esta es la posici\u00f3n previa, en ausencia de arquitecturas centralizadas robustas, las implementaciones m\u00f3viles deber\u00edan tener en cuenta:
\nMientras que antes nos preocup\u00e1bamos 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.
\n\u00bfY cu\u00e1l es el punto de convergencia? Es necesario que comencemos a hablar acerca de la tecnolog\u00eda del coraz\u00f3n de una arquitectura m\u00f3vil \u2014 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.
\nM\u00e1s bien, una MAG es una forma de middleware que facilita en forma agn\u00f3stica de la red (LAN, WAN, WWAN, etc.)\u00a0 la conectividad entre m\u00faltiples, desintegrados y algunas veces dis\u00edmiles sistemas de empresariales y, en el cliente encontramos un inmenso rango de dispositivos (Hand Held robustos, PDAs, Notebooks, tel\u00e9fonos, etc).
\nEl contenido podr\u00eda ser informaci\u00f3n de texto, audios, o video. Cualquiera de estas cosas montadas sobre cliente y el middleware debe cubrir la integraci\u00f3n hacia atr\u00e1s, facilit\u00e1ndolo en cualquier momento, dondequiera, y con cualquier acceso del dispositivo hacia la informaci\u00f3n corporativa. Lo que vemos es que, “las Soluciones m\u00f3viles no construidas en una arquitectura multicanal en el futuro costar\u00e1n dos veces m\u00e1s durante su ciclo biol\u00f3gico que una soluci\u00f3n similar basados en portales de acceso multicanal”. En otras palabras, una estrategia fragmentada que implicar una desordenada estrategia en el desarrollo de soluciones m\u00f3viles es realmente mala idea.
\nPara ayudar a los tecn\u00f3logos corporativos a compartimentar arquitecturas m\u00f3viles, en categor\u00edas con caracter\u00edsticas bien definidas, sus pros y contras, definimos seis estilos fundamentales de Arquitecturas M\u00f3viles:<\/p>\n
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\u00e1 disponible y d\u00f3nde la seguridad de los datos es una preocupaci\u00f3n primaria (esta soluci\u00f3n nos da la posibilidad de contar con una rango muy amplio de opciones para asegurar los datos).\u00a0 Sin embargo, como negativo, podemos decir que el costo est\u00e1 relacionado con la sofisticaci\u00f3n y complejidad. Es la opci\u00f3n m\u00e1s cara, pero la de m\u00e1s alta calidad de servicio.<\/p>\n
En esta opci\u00f3n, el c\u00f3digo puede residir en el dispositivo, pero no los datos \u2014 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\u00f3n m\u00f3vil de Java (J2ME) como una plataforma horizontal con caracter\u00edsticas de un cliente rico dentro de una MAG. Pero dada la diversidad de versiones de J2ME existentes y el grado de sofisticaci\u00f3n que requiere trabajar con todos ellos, tambi\u00e9n 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.<\/p>\n
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\u00f3n con cliente delgado es el amplio rango de dispositivos soportados, mayormente debido a la confianza en la tecnolog\u00eda est\u00e1ndar del lado del cliente como los navegadores de HTML o XHTML o la versi\u00f3n m\u00f3vil de Flash (Flash Ligth).\u00a0 Los clientes delgados no requieren datos ni c\u00f3digo persistente del lado del dispositivo, pero sufren completamente una crisis nerviosa cuando se pierde la conectividad con la red. Tambi\u00e9n, hay tambi\u00e9n menos opciones de seguridad (EJ: VPN o HTTPs) pero las buenas noticias son que el TCO es dram\u00e1ticamente menor (respecto a clientes ricos o gruesos).<\/p>\n
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\u00f3n y entretenimiento.\u00a0 Es primordialmente una arquitectura con flujo de datos de ida pero no de regreso, adecu\u00e1ndola en ambientes corporativos, podr\u00edamos pensar en necesidades espec\u00edficas 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\u00e1mbricas ciudadanas (3G\/4G\/5G)).<\/p>\n
Confinado para aplicaciones limitadas como el correo electr\u00f3nico o SMS messaging, el env\u00edo de mensajes se encuentra restringido para necesidad mas sofisticaci\u00f3n como algo transaccional. La soluci\u00f3n final comienza a parecerse a un cliente rico, o la carga es colocada en los usuarios finales d\u00e1ndole forma a los mensajes de acuerdo a algo que la sabra reconocer la infraestructura que se encuentra detr\u00e1s. La seguridad puede o no ser una preocupaci\u00f3n aqu\u00ed, al confiar en mecanismos por correo electr\u00f3nico propietarios como los ofrecidos por RIM o Microsoft. Pero el servicio de SMS sobre redes inal\u00e1mbricas p\u00fablicas no ofrece el tipo de seguridad que muchas aplicaciones requieren. Desde el punto de vista del TCO, seguramente es una opci\u00f3n barata.<\/p>\n
Es aplicable mayormente para las situaciones telef\u00f3nicas simples donde el discado basado en tonos o el reconocimiento interactivo \u00a0de voz\u00a0(IVR)\u00a0son suficientes. Sin tecnolog\u00eda del lado del cliente por la que preocuparse, la arquitectura “Sin ning\u00fan cliente” es uno de las alternativas m\u00e1s baratas e implica que toda informaci\u00f3n puede ser transportada en un formato audio. Es f\u00e1cil de implementar y desde el punto de vista de usuario final, en todo el mundo se encuentran familiarizados con tel\u00e9fonos por tono.
\nEn un punto, muchos indican que si bien llego m\u00e1s tarde, Microsoft’s Mobile .NET es mejor elecci\u00f3n que la arquitectura SUN J2ME.\u00a0 T\u00e9cnicamente 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\u00eda hoy. El problema con el que nos encontramos, y por lo que se dice que J2ME es un desorden, es que J2ME est\u00e1 muy fragmentado cuando comparamos espec\u00edficamente distintos dispositivos. Sin embargo se espera que esto mejore en el corto plazo.<\/p>","protected":false},"excerpt":{"rendered":"
\u00bfQu\u00e9 es una MAG? Un Portal de Acceso Multicanal (MAG – Multichannel Access Gateway) provee el middleware cr\u00edtico para dejar que las aplicaciones de oficina puedan ser utilizadas en ambientes cableados e inal\u00e1mbricos a trav\u00e9s de un \u00fanico portal de acceso. Una MAG es un puente necesario para la convergencia para asociar sistemas del backend, … <\/p>\n