sábado, junio 18, 2005

Intermedio: Comparación de Arquitecturas

En otra pantalla tengo Word abierto, estoy escribiendo un documento respecto a ciertas recomendaciones de Arquitectura, las cuales voy a aprovechar de detallar aquí también (sin algunos tópicos específicos, por supuesto).

Si hoy se plantea una arquitectura flexible y escalable, que permita la operación de sistemas a lo largo de una WAN, o en otras palabras, de una empresa con sucursales de cierto tamaño, ¿Qué arquitectura es la recomendable?

Para acotar las cosas, detengámonos en las alternativas de .NET (que es uno de los temas centrales de este Blog).

Por un lado tenemos arquitecturas antiguas que han sido "recargadas" por las nuevas herramientas, por un lado Cliente/Servidor tradicional y el enfoque tipo Windows DNA, que asume un esquema de N-Capas con un servidor de Negocios intermedio.

En general estas arquitecturas operan correctamente, pero están limitadas principalmente por la homogeneidad de la plataforma y por escalabilidad.

Otro punto en contra de estas plataformas es la interoperabilidad con otros sistemas sin generar acoplamiento (necesidad de "conocer" muchas cosas respecto a la otra aplicación).

De hecho, no es simple interconectar objetos COM a través de Firewalls, independiente de que hayan sido construidos con herramientas pre-.NET o con .NET.

Luego, descartemos esas tecnologías, ¿qué nos queda? Smart Clients y ASP.NET, es decir, aplicaciones que se comunican via Web Services de uno o más servidores, versus aplicaciones que corren sobre un servidor IIS (o Apache, si metemos Mono en el cuento, pero por el momento mantengámonos en el universo Microsoft).

¿Cuando escojer una versus la otra? Yo particularmente no soy un defensor a ultransa de ASP.NET, de hecho, pienso que los browsers no son buenas plataformas para desarrollar aplicaciones robustas, esencialmente por que inicialmente fueron diseñados para otras tareas, y que su uso para soportar aplicaciones es más bien circunstancial.

Por otra parte, el modelo totalmente atómico de los browsers, en que cada etapa es independiente de la anterior (y que cualquier estado debe mantenerse en forma "indirecta") tampoco me calza para todas las situaciones.

De hecho, me parece razonable para sitios de consulta o transacciones simples. En los otros casos creo que una plataforma Smart Client es más poderosa (con los inconvenientes propios de tener que instalar las aplicaciones).

Ok, esos son gustos u opiniones "subjetivas", ¿existen datos concretos?

Veamos si logramos tener algunos. Partamos por lo principal, si tengo una pantalla en un browser, por cada acción relevante debo hacer un round trip al servidor, ¿es esto eficiente?

La respuesta es depende, veamos unos ejemplos:

1) Imaginemos una pantalla en la cual tenemos un combo box (C1), el cual, se carga con el resultado de una consulta (Q1). Una vez que se selecciona un valor de C1, otro combo box (C2) se carga con el resultado de otra consulta (Q2), la cual es función del valor seleccionado.

Si [Q1] es el tiempo asociado a transmitir el resultado de Q1 y si [Q2] es lo mismo para Q2. Tenemos lo siguiente:

En el caso del browser, el tiempo para realizar una transacción es al menos 2[Q1] + [Q2], pues al seleccionar el valor en C1 se genera un refresh, lo cual obliga a enviar de nuevo los datos de Q1.

Nota: No estoy incluyendo el tiempo de realizar la consulta a la base de datos exprofeso, pues en una aplicación ASP.NET perfectamente pueden existir caché de resultados de consultas y eso complica el análisis.

Ahora bien, en el caso de una aplicación Windows Forms, con Webservices, el tiempo sería [Q1] + [Q2] pues no es necesario volver a traer Q1.

Ahora, si esta operación es realizada "n" veces por el usuario, y asumimos que [Q1]=[Q2]=q, tenemos que:

tbrowser = 2n[Q1] + n[Q2] = 2nq + nq = 3nq

Mientras que para la aplicación Windows:

twinforms = n[Q1] + n[Q2] = nq + nq = 2nq

Luego podemos ver que:

Ahorro = (3nq - 2nq) / 3nq = nq / 3nq = 1 / 3 = 33%

Pero, si además consideramos que en la aplicación Windows es posible realizar una vez Q1 para una sesión, el tiempo resulta ser el siguiente:

twinforms = [Q1] + n[Q2] = q + nq

Luego el ahorro es el siguiente:

Ahorro = (3nq -q - nq) / 3nq = q(2n - 1) / 3nq = 2/3 - 1/n

Lo cual significa un ahorro de hasta un 66% (ya que 1/n tiende a 0 rápidamente)

2) Otro caso, imaginemos que debemos seleccionar una forma de pago, por ejemplo, tarjetas de crédito, cada vez que se presente la lista de tarjetas disponibles se tiene un tiempo asociado, digamos "q", luego, en el caso del browser:

tbrowser = nq

Donde "n" es el número de transacciones que deben mostrar la lista.

Luego en el caso de Windows Forms, sólo es necesario traerse una sola vez la información, luego el ahorro es enorme:

Ahorro = (nq - q)/nq = (n-1)/n

Lo cual rápidamente tiende a un ahorro del 100%

3) Un tercer caso es el siguiente.

Por ejemplo si tenemos una aplicación en la cual ingresamos el rut, con lo cual se obtienen los datos del usuario (ya registrados), y tomamos ese tiempo como [Q1].

Si además, cada persona tiene un conjunto de convenios, y el tiempo para transmitir esa información es [Q2].

Luego, la persona ingresa productos, los cuales deben ser valorizados. Si el número de productos es "p" y el tiempo para valorizar cada producto es [Q3].

Tenemos que el tiempo del browser es el siguiente (asumiendo que todos los tiempos son iguales a q):

tbrowser = [Q1] + [Q2] + p([Q3] + [Q2] + [Q1]) = 2q + 3pq

Luego para Windows Forms es:

twinforms = [Q1] + [Q2] + p[Q3] = 2q + pq

Luego el ahorro es = (2q + 3pq - 2q - pq) / q(2+3p) = 2pq / q(2+3p) = 2p/2+3p

Si el producto es 1 entonces el ahorro es 2/5 = 40%

Si son 10 productos entonces el ahorro es 20/32 = 5/8=62%

Como puede verse de los tres ejemplos planteados, el tiempo implicado en transmitir la información es significativamente menor para el caso de Windows Forms, en un esquema de Smart Client. Se puede ver, que esto implica una menor carga sobre el servidor Web, y también una baja en el número de consultas a la base de datos.

No hay comentarios.: