2004-09-02 Aplicaciones Multi-Nivel: Primeros pasos...
Mientras reinstalaba mi sistema (super rápido gracias a Norton Ghost!) se me ocurrio empezar un seriado de artículos sobre la creación de software multi/nivel (o tipo cliente/servidor, multi-usuario, n-tier, etc...) ya que a pesar de que la idea lleva rondando mucho tiempo, aún es una fuente de dificultades, incluso para desarrolladores experimentados.

No voy a repetir la información que ya está disponible (como que es n-tier, ver aquí (inglés)) y la idea es enfocarse en los conceptos más que en las tecnologías como tales. Los artículos suponen un conocimiento suficiente de Delphi.... para darse una idea leer en las ayudas sobre MIDAS o DataSnap y/o SOAP (Servicios Web).

El plan a seguir:

  • Una introducción general (este artículo) (Listo)
  • Aplicaciones Multi-Nivel: Haciendo la Lista de compras: Consejos sobre elección de tecnologías y el porque de las elecciones (Listo)
  • Aplicaciones Multi-Nivel: Un ejemplo práctico (diseño): Un diseño completo de un servicio que se puede implementar con CUALQUIER herramienta
  • Aplicaciones Multi-Nivel: Un ejemplo práctico (implementación): Como implementar el ejemplo con RemObjects.
Donde radica el problema...

No... no es en la herramienta. No se soluciona con un buen framework como DataSnap (incluido en Delphi) o RemObjects... no se arregla conectando la base de datos a un equipo remoto (aunque funcione). El problema no es tecnología.... es de entendimiento o concepto.

Supongamos que estamos navegando en una tabla o consulta... algo como:

DatosClientes.Next;

La parte DIFICIL de captar es esta: cuando movimos el dataset de donde y hacia donde fueron los datos y acciones? Pues... en memoria... (hey, no me dijiste que era DIFICIL?).... Ok... pensar: Realmente como se hizo esto? Obviamente se envio una acción que mueve el registro, el cual va a la memoria, coje la memoria, la desempaqueta, la interpreta, etc... O sea, se hacen muchos pasos aqui.

El punto es, que al hacer aplicaciones n-tier NOS TOCA HACER CADA PASO a diferencia de una ejecución local, que Delphi se encarga de todo el trabajo, en una remota no es asi. Y cada paso es mucho más costoso en términos de tiempo, procesamient que cuando se ejecuta localmente.

Que compone una aplicacion n-tier?

  • Un canal de comunicación
  • Un protocolo de comunicación
  • Una especificación de como se envia/recibe la información
  • Componentes que empaquetan y desempaquetan los datos en cada puerta de comunicación
  • Una interface de como es el servidor
Eso es lo que se hace al hacer DatosClientes.Next, pero en memoria. El problema es que NO SE PUEDE hacer aplicaciones remotas de la MISMA manera que locales... eso es, si se quiere que queden bien...

La clave para hacer una aplicación n-tier es que entre el cliente y el servidor MEDIA un servicio de mensajeria: con las mismas características que la mensajería corriente con la que enviamos correos electrónicos. Si se entiende como funciona el correo electrónico ya tenemos la capacidad mental de entender como hacer n-tier.

Repito:

  • Necesitamos un canal de comunicación
  • Que es por medio de un protocolo (como TCP/IP o Http)
  • Definimos como es el formato de nuestros "correos"
  • Y los interpretamos a cada lado de la comunicación
Despues que hicimos TODO ESO, es que llegamos a DatosClientes.Next. No antes. Eso es lo dificil... no entender esto es la causa fundamental por la cual las aplicaciones no escalan bien, o toman años en hacerse. Aunque tengamos herramientas que nos automatizan procesos, no pueden ayudarnos en el diseño ni en la arquitectura de la misma.

Definir la interface del Servidor no es hacer un componente

Un error común es que al hacer la interface del servidor se cree que se está haciendo un componente o una función cualquiera. Por ejemplo:

function Logearse(Usuario:String;Clave:String):Integer;

se implementa igual tanto si es un programa local como uno remoto... entonces creimos que estabamos haciendo componentes o funciones y luego escribimos:

ClienteRemoto: Apunta a un servidor:


ClienteRemoto.First;
ClienteRemoto.Nombre:=....
ClienteRemoto.Fecha:=...
.
.
ClienteRemoto.Guardar;

Recordemos los pasos para llegar a ClienteRemoto.First:


Procesos locales
Encode(ClienteRemote.First) Definir el correo
Establecer comunicación... Recibir si se hizo
Usando Http.... autenticar canal?
Decode(Datos del cliente)
ClienteRemoto.First;
Esperar respuesta en el cliente
Recibir Respuesta Servidor
Decode(Respuesta Servidor)
Ejecución Local ClienteRemoto.First

Eso ocurre si se nos olvida que MEDIA entre nuestro cliente y servidor un sistema de correo o mensajería, que se agrava mientras mas lejana es la comunicación, mas pedidos de nuevos mensajes se hagan y más grandes sean eston. Si nos molesta esperar a que nuestro cliente de correo baje los emails para darnos cuenta la cantidad de basura que recibimos (y que igual toco procesar) nos damos a la idea de lo que DEBEMOS evitar !

Por lo tanto, nuestra definición de la interfaze del servidor debe ser amiga de los mensajes, que IMPIDA que los cliente tengan que hacer muchas solicitudes y que envie/reciba la información necesaria... algo como:

ClienteRemoto.Guardar(Nombre,Fecha....);

ya es mucho mejor...

En el proximo artículo mostrare nuestro "carro de compras" con componentes y herramientas recomendadas para hacer una aplicación de estas con Delphi.


Etiquetas: