Configura una IP fija a partir de una dinámica

En muchas situaciones es conveniente poseer una dirección IP estática, pero los costos adicionales que demandan los proveedores de Internet junto a la cada vez menor cantidad de números IP disponibles, hacen que este lujo sea prácticamente imposible de obtener. Sin embargo, existe una forma sencilla y gratuita para hacer que tu dirección dinámica se comporte como si se tratara de una dirección estática.

Esto se logra gracias al servicio gratuito de DNS dinámicos que ofrece la empresa DynDNS. Gracias a su pequeño cliente llamado Updater, cualquier usuario puede tener acceso a unsub-dominio completamente gratuito y asociarlo a un ordenador, independientemente del número IP que el proveedor de Internet haya asignado en esa conexión. ¿Para qué puedes usar esto? Bueno, para todo lo que involucre poseer una dirección y un dominio de Internet, ya sea una página web o un servidor FTP. ¿Quieres tener tu propia página usando algo como Apache? Con DynDNS y un par de ajustes, podrás hacerlo.

Ingresa con tu cuenta y accede para agregar un servicio

1) Lo primero es obtener una cuenta en DynDNS.Ve a la página, regístrate y confirma tu cuenta recién creada a través del correo que recibiste. Ingresa con tu cuenta al sitio de DynDNS y en las propiedades haz clic en Add Host Services. Allí debes escogerun nombre y un sub-dominio de la lista, hay varios para elegir. La opción Wildcard habilita el uso de “www” al principio de la dirección, activa la opción si lo deseas. En tipo de servicio, deja marcadoHosting with IP Address.

Configurar estas opciones es muy sencillo

En la secciónIP Addressverás que la página detectó automáticamente tu IP actual. Haz clic en el texto azul para ingresar ese IP. Esto es temporal, sólo necesario para activar el sub-dominio. El cliente de DynDNS cambiará luego este IP de forma automática. Deja el TTL en 60 segundos, e ignora la casilla de Mail Routing, salvo que planees montar un servidor de correo. Para finalizar, aplica los cambios. Eso es todo para esta parte de la configuración.

Puedes especificar que Updater se instale como un servicio

2) Es hora de descargar el cliente conocido como Updater, que mantendrá sincronizado tu IP dinámico con tu subdominio. Está disponible para Windows, Mac y Linux (usaremos la versión de Windows por cuestiones de difusión). Su instalación es muy sencilla, de hecho, la única pregunta que hará es si deseas instalarlo como un servicio. En caso de que seas el único que utiliza el ordenador y sólo usarás tu cuenta con el cliente, te recomendamos que utilices esta opción.

El siguiente paso es ejecutar el programa e ingresar nuestro nombre de usuario y contraseña. Si todo va bien, verás una tilde con un círculo verde y el estatus “good”. Eso significa que la actualización del número IP está funcionando como debería. En la sección Advanced verás varias opciones disponibles. Para nuestra prueba utilizamos todas ellas.

La ventana principal de Updater, con nuestro sub-dominio detectado y configurado	Las opciones avanzadas

Ejemplo de un módem-router Huawei con el puerto 80 configurado

3) Firewall y routers. Si el programa Updater te recibe con una tilde y un círculo verde las cosas son menos complejas, pero en caso de que el programa tire un error, es probable que algún firewall o la configuración del router estén dando problemas. No podemos darte los pasos específicos sobre cómo configurar un router debido a la gran cantidad de modelos que existen, pero lo cierto es que debesabrir o redireccionar los puertos relacionados con el servicio que planeas preparar. En caso de unservidor FTP, debes configurar el puerto 21 de TCP. Para un servidor web, debes especificar el puerto 80 y puede que también necesites abrir el puerto 443. En caso de servidores de correo, los puertos son el 25 para correo entrante y el 110 para correo saliente. Una excelente guía de apertura de puertos sobre routers específicos puede ser encontrada aquí.

Lo ideal es que hagas la apertura de puertos más allá del reporte de estatus que arroje el Updater, para evitar posibles conflictos. Al mismo tiempo, tanto la aplicación Updater como los puertos y los programas de servicios que utilices (por ejemplo, Apache como servidor web) deben ser agregados a la lista de excepciones del firewall de turno que esté en tu ordenador. A menos que el firewall detecte al programa intentando acceder a la red y cree automáticamente una regla de excepción, deberás configurar esto tú mismo/a. Por ejemplo, Apache no es detectado por el firewall de Windows XP SP2, lo que implica un ajuste manual.

Configurando Apache y Updater en las excepciones del Firewall de Windows

Burdo y básico sitio web armado sobre Apache para saludar a nuestros amigos

Eso es todo. En menos de veinte minutos podrás tener tu propia dirección web asociada a cualquier número IP que tu proveedor de Internet desee asignarte. Las únicas cláusulas que impone DynDNS para el uso de su servicio gratuito son las clásicas y esperables como“nada de porno” y “nada de software pirata”, con la obvia consecuencia de que borrarán tu cuenta de un plumazo si algo de eso puede accederse a través de tu dirección. Pero si necesitas un servidor FTP para uso personal o quieres experimentar teniendo tu propia página web, esto te será realmente útil. ¡Buena suerte!

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.