20 noviembre 2007

Creando aplicaciones multicapa (III)

Vamos seguir con la base teórica de como funcionan las aplicaciones multicapa antes de comenzar a crear un ejemplo práctico.

ELIGIENDO EL PROTOCOLO DE CONEXION

Cada protocolo de comunicación que podemos usar para conectar de las aplicaciones cliente a las aplicaciones servidor tienen sus propias ventajas e inconvenientes. Antes de elegir un protocolo tenemos que considerar que servicio va a prestar la aplicación, cuantos clientes va a ser atendidos, que reglas de negocio se van a establecer, etc.

USANDO CONEXIONES DCOM

DCOM es el protocolo que proporciona el acceso más directo y rápido de comunicación, no requiriendo aplicaciones externas aparte del servidor de aplicaciones.

Este protocolo proporciona servicios de seguridad cuando se utiliza un módulo de datos transaccional. Cuando usamos DCOM podemos identificar quien llama al servidor de aplicaciones (ya sea con COM+ o MTS). Por tanto, es posible determinar que reglas de acceso vamos a asignar a las aplicaciones cliente.

Son los clientes los que instancian directamente el módulo de datos remoto para realizar la comunicación, no requiriendo ninguna aplicación externa que haga de intermediario.

USANDO CONEXIONES SOCKET

La comunicación mediante sockets nos permiten crear clientes muy ligeros. Se suele utilizar este protocolo si no tenemos la seguridad que los sistemas clientes soporten DCOM. Los sockets proporcionan un sistema comunicación simple para establecer conexiones entre los clientes y el servidor.

En lugar de instanciar el módulo de datos remoto desde el cliente (como sucede con DCOM), los sockets usan una aplicación separada en el servidor (ScktSrvr.exe), la cual acepta las peticiones de los clientes e instancia el módulo de datos remoto usando COM. El componente de conexión en el cliente y ScktSrvr.exe en el servidor son los responsables de organizar las llamadas mediante la interfaz IAppServer.

El programa ScktSrvr.exe también puede ejecutarse como un servicio NT. Para ello habría que registrarlo como servicio usando línea de comandos. También se puede eliminar de la lista de servicios del mismo modo.

Uno de los inconvenientes que tienen los sockets es que no hay protección en el servidor contra fallos en la conexión con los clientes. Mientras este protocolo de comunicación consume menos ancho de banda que el protocolo DCOM (el cual envía periódicamente mensajes de comprobación y mantenimiento), no puede detectar si un cliente se está ausente o no.

USANDO CONEXIONES WEB

Una las ventajas de utilizar el protocolo de comunicación HTTP es que los clientes pueden comunicarse con el servidor de aplicaciones aunque este protegido por un cortafuegos. Al igual que las conexiones socket, los mensajes HTTP proporcionan un sistema sencillo y de poco consumo de ancho de banda para comunicar los clientes y el servidor.

En lugar de instanciar el módulo de datos remoto desde el cliente (como sucede con DCOM), las conexiones basadas en HTTP pueden usar un servidor de aplicaciones web (como Apache) o el servidor puede ser la librería httpsrvr.dll, el cual acepta las peticiones de los clientes e instancia el módulo de datos remoto usando COM. El componente de conexión en la máquina cliente y httpsrvr.dll en el servidor son los responsable de organizar las llamadas a la interfaz IAppServer.

Las conexiones web aportan también la ventaja de la seguridad SSL suministrada por la librería wininet.dll (una librería de utilidades de internet que corre en los sistemas cliente). Una vez que hemos configurado el servidor web en la máquina que hace de servidor de aplicaciones, podemos establecer los nombre y claves de acceso para los usuario aprovechando las propiedades de conexión que aporta el componente web.

Las conexiones web tienen la ventaja de tener en una memoria caché los objetos de módulos de datos que se van instanciando, conocido como pooling. Esto permite que nuestro servidor cree un número de instancias de módulos remotos limitado para dar servicio a los clientes, sin tener que estar instanciando y destruyendo objetos sin parar cada vez que se conecta o desconecta un cliente.

A diferencia de otras conexiones con componentes, no podemos crear funciones que permitan comunicar directamente el servidor de aplicaciones con las aplicaciones clientes, lo que se llaman funciones callback.

USANDO CONEXIONES SOAP

El protocolo SOAP es el estándar utilizado para crear aplicaciones de servicios web. Este protocolo envia y recibe mensajes codificados en documentos XML, y los envía utilizando el protocolo HTTP.

Las conexiones SOAP tienen la ventaja de que son multiplataforma, ya que son soportadas por prácticamente todos los sistemas operativos actuales. Al utilizar como transporte el protocolo HTTP tienen las mismas ventajas: permite servir a los clientes a través de un cortafuegos y pueden utilizarse diversos servidores HTTP.

CONSTRUYENDO UNA APLICACION MULTICAPA

Resumiendo a grandes rasgos, los pasos generales para crear una aplicación de bases de datos multicapa son los siguientes:

1. Crear el servidor de aplicaciones.

2. Registrar el servidor de aplicaciones como un servicio o instalarlo y ejecutarlo como una aplicación (recomendado).

3. Crear la aplicación cliente.

El orden de creación es importante. Debemos crear y ejecutar el servidor de aplicaciones antes de crear el cliente. Esto se debe a que cuando vayamos a construir la aplicación cliente, en tiempo de diseño tenemos que conectar con el servidor de aplicaciones para realizar pruebas de conexión. Aunque se también se podría un crear un cliente sin especificar el servidor de aplicaciones en tiempo de diseño, pero no lo recomiendo porque es más incómodo.

Si no estamos creando la aplicación cliente en el mismo equipo que el servidor, y estamos usando una conexión DCOM, podemos registrar el servidor de aplicaciones en la máquina cliente. Esto hace que los componentes de conexión se enteren de donde está el servidor de aplicaciones en tiempo de diseño, así podemos elegir el componente Provider desde el inspector de objetos.

CREANDO UN SERVIDOR DE APLICACIONES DCOM

La mayor diferencia entre crear un servidor de aplicaciones y la típica aplicación de bases de datos cliente/servidor reside en el módulo de datos remoto. Vamos a crear una aplicación EXE que va a hacer de servidor de aplicaciones para una base de datos Firebird 2.0 que tiene una tabla llamada CLIENTES.

Para crear un servidor de aplicaciones, hay que seguir los pasos:

1. Crear un nuevo proyecto: File -> New -> Application.

2. Guardar el proyecto como ServidorDatos.exe

3. Añadimos un módulo de datos remoto al proyecto: File -> New -> Other.

4. Nos vamos a la pestaña Multitier, seleccionamos Remote Data Module y pulsamos Ok.

5. Rellenamos los campos:

CoClass Name: ServidorDCOM

Instancing: Multiple Instance

Threading Model: Apartment

6. Pulsamos Ok. Nos aparecerá una nueva ventana que representa el nuevo módulo de datos remoto creado.

7. Guardamos el módulo de datos remoto en disco con el nombre UServidorDCOM.pas

8. Insertamos en el módulo de datos remoto el componente TIBDatabase con el nombre BaseDatos.

9. Hacemos doble clic sobre el componente BaseDatos y configuramos lo siguiente:

Connection: Remote
Protocol: TCP
Database: 127.0.0.1:D:\Desarrollo\DelphiAlLimite\Multicapa\DCOM\BaseDatos.fdb
LoginPrompt: Desactivado

10. Pulsamos Ok.

11. Añadimos al módulo de datos remoto un componente TIBTransaction llamado Transaccion.

12. Vinculamos el objeto Transaccion al componente TIBDatabase a través de su propiedad DefaultTransaction.

13. Asignamos BaseDatos en la propiedad DefaultDatabase del componente Transaccion.

14. Insertamos un componente TIBQuery llamado TClientes. En su propiedad Database ponemos BaseDatos. Y su propiedad SQL escribimos:

SELECT * FROM CLIENTES

15. Hacemos doble clic en el componente TClientes y pulsamos la combinación de teclas CTRL + A para añadir todos los campos.

16. Insertamos un componente TDataSetProvider llamado DSPClientes. En su propiedad DataSet seleccionamos TClientes.

Con esto ya tenemos nuestro propio servidor de aplicaciones conectado a la base de datos Firebird. Como puede apreciarse es casi lo mismo que crear una aplicación cliente/servidor.

La diferencia está en que no es necesario instanciar en memoria el módulo de datos remoto ya que la aplicación cliente se encargará de hacerlo.

En la siguiente parte de este artículo crearemos la aplicación cliente encargada de conectarse con este servidor de aplicaciones que hemos creado.

Pruebas realizadas en Delphi 7.

11 comentarios:

l¬ll>l°\ll¬ll>l dijo...

Eres miembro de club delphi...?
Me gustaria compartirte algo...

Delphi al Límite dijo...

No soy miembro del club Delphi pero sí lo visito muy a menudo. Para mi es el mejor foro de Delphi en castellano.

Si quieres decirme algo en privado puedes escribirme a:

taxylon@gmail.com

Anónimo dijo...

Hola, quiero hacer esta pueba con DELPHI 2007, pero no encuentro el Remote Data Module ...

existe en Delphi 2007 ?? tiene otro nombre ???

gracias...

salu2!!!!!!!

Administrador dijo...

Tienes que seleccionar:

File -> New -> Other

Dentro de la carpeta "Delphi Projects" seleccionas la carpeta "Multitier" y eliges a la derecha "Remote Data Module".

Saludos.

Anónimo dijo...

este.... mmmm....
no esta dicha carpeta ....

http://img245.imageshack.us/img245/9076/ventanadelphinew.jpg

asi me aparece ....

se debe a las diferentes versiones de DELPHI ???

gracias...

salu2!!!!!!!

Administrador dijo...

Eso se debe a las muchas versiones de Delphi 2007 que hay (sobre todo versiones piratillas o demos no oficiales.).

He visto de todo en Delphi 2007.

Anónimo dijo...

Hola ...

muchas gracias por la atencion..

ahora me gustaria hacer una pregunta, espero se pueda ... :D

para hacer que este ejemplo funcione como MULTIUSUARIO, como se haria ???

me refiero a abrir dos veces el CLIENTE (en dos maquinas diferentes) y que al hacer cambios en un CLIENTE, se actualicen los datos en el otro cliente...

es posible con este tipo de conexiones que manejas en el ejemplo ???
que arreglos habria que hacer ???


Gracias

salu2!!!!!!!

Administrador dijo...

No tienes que hacer nada. Precisamente es una de las ventajas de las aplicaciones multicapa.

Si un usuario abre la ficha de un cliente, el servidor de aplicaciones creará una instancia del módulo de datos remoto exclusivamente para él.

Da igual si otro usuario abre también una rejila con clientes y se pode a editar otro registro. Será otro módulo de datos remoto para él.

El único inconveniente que tiene este sistema es que cuantos más usuarios simultáneos entonces más recusos se consumen del servidor, pero con la memoria RAM que hay hoy en día y los procesadores de doble núcleo se puede merendar decenas o cientos de usuarios sin problemas.

Saludos.

Anónimo dijo...

Ok... Hasta aqui todo bien...
pero mi pregunta iba hacia el modo de actualizar los datos.

Abro dos instancias del cliente, pero si modifico un dato de la tabla, el segundo cliente como se entera de eso???
o si se agrega o borra un registro, como se le notifica a la segunda aplicacion cliente ???

Dices que por cada cliente se 'crea' un MODULO DE DATOS ??? entonces, como se mantienen los datos actualizados en la BD ???

hay que crear alguna funcion o implementar algo en algun EVENTO de los componentes para realizar los REFRESH de los datos???

o como se haria esto ???

gracias

salu2!!!!!!!

Administrador dijo...

Si el usuario 1 tiene abierta una rejilla de datos con el listado de clientes y el usuario 2 da de alta un nuevo cliente, el usuario 1 no se habrá enterado de nada esta que no refresque esa rejilla.

Se podría solucionar con un temporizador que refresque la rejilla cada X tiempo. Creo (no estoy seguro) que no hay manera de provocar en el resto de clientes una actualización de pantalla.

Realmente si se podría hacer mediante un sistema de mensajes cliente/servidor tipo P2P pero hay que trabajarlo muy bien.

Eso tendría un inconveniente: si un usuario va recorriendo la lista de clientes en busca de uno en concreto y de repente se actualiza la lista se iría al primer registro y eso podría mosquearlo.

Igual podría ocurrir con un temporizador. Todo depende de las personas que vayan a manejar el programa y su prioridad.

Mientras que cada registro tenga su propio ID único no creo que esto de las actualizaciones sea algo prioritario, a menos que vayamos a programar un sistema en tiempo real como en la bolsa de valores.

Anónimo dijo...

ok.. muchas gracias ...

de hecho... yo estoy implementando una especie de MENSAJES entre aplicaciones, ( pero con la conexion por medio de SOCKETS ) ... asi, cada que un CLIENTE hace cambios en alguna tabla, le envia un mensaje al otro cliente para que haga un REFRESH a la BD ....

solo queria saber si conel ejemplo de los modulos remotos, habria algo mas sencillo, ya que todavia no logro hacer funcionar mi aplicacion al 100% ... :S :S :S :$

GRACIAS de nuevo

Salu2!!!!!!!

Publicidad