Gol-Net, el camino elegido

Finalmente elegí cómo desarrollar la nueva versión de Gol-Net.

Durante mucho tiempo tuve Una duda razonable, pero ya tengo claro lo que voy a hacer.

ASP.NET 3.5

Finalmente Gol-Net seguirá siendo una aplicación .NET pero dejará el framework 2.0. Como dije antes, no será 4.5 porque el hosting no lo soporta.

Arquitectura

Me basé en la Arquitectura de aplicaciones corporativas para la nube que comenté en el blog de Wetcom, adaptandola un poco ya que se trata de un sitio chico sin tanta demanda de recursos.

La interfaz de usuario será del tipo "página única" con HTML5, CSS3 y jQuery. Esta capa se conectará a un Web Service que devuelve JSON. Este servicio se encargará de la seguridad y luego "hablará" con la aplicación Gol-Net.

La base de datos no será "en memoria", pero dejará de ser Access para pasar a un esquema SQL Server.

Novedades

El nuevo Gol-Net será "multi-tenant" lo cual permitirá la creación de campeonatos privados. Una vez terminados será posible borrar todos los datos (incluyendo los usuarios) sin afectar al Gol-Net tradicional.

La interfaz de usuario será basada en Bootstrap para que se adapte a diferentes resoluciones de pantalla.

¿Que tiene de interesante?

Utilizando este esquema, logré mantener cada capa completamente separada de las demás y me permitió mantener cada capa muy simple. Sin necesidad de MVC ni funcionalidades exóticas.

Lo único que estoy utilizando del framework 3.5 son los tipos genéricos que permiten que el código sea mucho más simple y claro.

Por último, podría modificar cada capa sin que esto afecte el resto. Bien podría migrar a Java y Spring para la aplicación y la interfaz de usuario sería exactamente igual. O podría desarrollar una aplicación de escritorio o mobile y utilizar el mismo servicio web.

Spring Tool Suite se cierra cuando usamos Run on Server

Todo parece funcionar bien con Spring Tool Suite pero, al hacer "Run on Server", STS simplemente se cierra.

Iniciamos nuevamente STS y al volver a ejecutar "Run on Server" nos dice que el puerto 8080 está siendo usado. Esto significa que tc server inició correctamente.

Revisamos el log creado en la carpeta de STS "hs_err_pidxxxx.log" y dice algo asó como "A fatal error has been detected by the Java Runtime Environment" y luego "C  [libwebkitgtk-1.0.so.0+0x462159]  webkit_web_view_get_type+0x2489" o algo similar.

Solución

Agregar la siguiente línea al final del archivo STS.ini (o eclipse.ini):
-Dorg.eclipse.swt.browser.DefaultType=mozilla

Solución encontrada en la siguiente URL luego de buscar por horas:
http://arecordon.blogspot.com.ar/2013/06/eclipse-problematic-frame-c-libsoup.html

RabbitMQ: cómo enviar objetos .NET y recibir objetos JAVA

Un nuevo post en el blog de Wetcom.

Cómo desarrollar un Servicio Web REST con Java y Spring

Mi post sobre servicios web con Spring en el blog de Wetcom.

vFabric SQLFire: la base de datos de las aplicaciones modernas en la nube

Mi post sobre SQLFire en el blog de Wetcom.

Manteniendo sesiones de usuario con tc Server y Gemfire

Mi post sobre tc Server y Gemfire en el blog de Wetcom.

Arquitectura de aplicaciones corporativas para nube (cloud)

Mi post en el blog de Wetcom.

Ubuntu 14.04 – Utilizar la red por cable y wireless al mismo tiempo

La red interna de mi oficina tiene varias redes ruteadas y se accede a Internet usando un proxy a través de un firewall. Existe una red wireless desconectada de la red Interna sólo para permitir acceso a Internet a los invitados.

Objetivo: lograr que mi notebook utilice la red por cable para acceder a los recursos internos y la red wireless para acceder a Internet.

Con Ubuntu 14.04 (seguramente con varias versiones anteriores también) esto es posible sin necesidad de instalar ningún software adicional. Todo gracias a que Ubuntu maneja las configuraciones de red (salvo el proxy) a nivel de conexión y no de “placa de red”.

Mi escenario de redes

La red interna de mi oficina consta de tres subredes ruteadas entre sí: la red de máquinas de escritorio 10.0.1.0/24, la red de servidores 10.0.2.0/24 y la red de servicios 10.0.3.0/24. Además, la red wireless (desconectada de la red interna) 127.16.0.0/24.

Tanto la red de máquinas de escritorio como la wireless usan DHCP.

Primer paso: forzar salida a Internet sólo por la red wireless

Vamos a Network Connections -> Ethernet -> Wired connection (la que corresponda) -> Edit -> Ipv4 Settings. Aquí agregamos el DNS interno de nuestra empresa y el dominio de búsqueda.

Luego hacemos clic en "Routes" y tildamos la opción "Use this connection only for resources on its network".

Listo, si nuestra red interna cuenta con una sola red, entonces ya está todo listo. Ya salimos a Internet por la red wireless y accedemos a los servicios internos por la red cableada.

Segundo paso: forzar el acceso a las redes internas restantes por la red cableada

Luego del paso 1, todo funciona bien pero no puedo acceder a la red interna de servidores ni la de servicios porque intenta buscarlas por la red Wireless.

Para solucionar esto, simplemente volvemos a la ventana de edicion de rutas de la red cableada y agregamos las siguientes rutas:
Address: 10.0.2.0 (la red de servidores en mi caso)
Netmask: 255.255.255.0
Gateway: 10.0.1.0 (la red de donde obtenemos ip via DHCP)
Metric: 1

Agregamos una segunda ruta para la red de servicios 10.0.3.0.

Terminamos

Ya podemos acceder a todos los recursos internos por la red cableada y a Internet por wireless. Y lo mejor, si desconecto la red cableada, sigue funcionando Internet. Si desconecto la red wireless, sigue funcionando la red interna. Si vuelvo a conectar todo, se reconfigura automáticamente.

Todo gracias a que las rutas están asociadas a la conexión de red por lo que se agregan y quitan del sistema en forma automática según se conecte o desconecte la red correspondiente.