FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Comunicación en PCs y acceso a BD
Hola, espero darme a entender
Tengo la siguiente situación: Una sala de cómputo con varias pc para los usuarios que van a correr una aplicación que registre el tiempo de uso y las actividades que realicen. Llamémosla AppUsuario. Varias pc que van a ejecutar una aplicación de control que básicamente listará los usuarios activos con la posibilidad de mandar mensajes a uno o varios de ellos. Llamémosla AppAdmin. Una máquina Unix con el servidor de bases de datos que almacenará los usuarios, sus sesiones de trabajo y actividades, etc. -------------- La idea que tengo para desarrollar esto es usar componentes Indy de la siguiente forma: Utilizar una pc aparte con una aplicación que sirva de puente entre AppAdmin y AppUsuario, llamémosla AppControl. AppControl usaría un IdTcpServer mientras que AppUsuario y AppAdmin usarían un IdTcpClient, de manera que AppAdmin manda mensajes a AppControl indicando el usuario al que van dirigidos para que AppControl lo mande al AppUsuario correspondiente. Ahora bien, bajo este esquema me parecería conveniente que la comunicación con la base de datos se hiciera a través de AppControl en lugar de que cada AppUsuario registrara datos en el servidor de BD. Para ello pensaría mandar la consulta SQL de AppUsuario a AppControl vía el socket y AppControl mandaría la consulta al servidor de BD. -------------- ¿Qué quiero? Bueno, ningún detalle técnico, ya veré yo cómo lidiar con ellos. Lo que quiero es su opinión acerca de este esquema. ¿Es adecuado para la situación planteada o me estoy complicando la vida? De ser esto último, se les ocurre alguna idea? Muchas gracias y // Saludos |
#2
|
||||
|
||||
Cita:
Cuantos usuarios se conectarian directamente a ella... Hacer viajar las instrucciones SQL a un servidor intermedio, para que este las ejecute y retorne cursores al cliente no me hace mucho clic. En todo caso, quizas usando ClientDatasets, con Providers comunicados por sockets, te simplificaria bastante el asunto (creo yo)... aun asi no lo veo justificado, salvo que querras dejar reglas del negocio en este servidor intermedio, claro está. el resto del modelo... bueno, tampoco entiendo muy bien el porque del AppControl, supongo que vos, que sos un Analista experimentado has de tener tus razones para hacerlo, y me fiare de ellas. Cita:
Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#3
|
||||
|
||||
Gracias jachguate.
A ver, nada de analista experimentado, al contrario. El porque de AppControl lo pensé para reducir el número de conexiones. Si tengo 20 usuarios y 4 administradores requeriría 80 conexiones si las hago directamente. A través de AppControl requeriría sólo 24 conexiones. Por otro lado no sabría bien cómo hacerle, apenas comenzaría a estudiar sockets más en serio. Cada usuario tendría que ser servidor ¿no? pues tendría que atender a varios administradores y lo mismo va por cada administrador. Y lo de la bd lo pensé teniendo ya centralizado por la otra razón. También pensé que teniendo la comunicación con la BD centralizada podría lograr una independencia del tipo de servidor de bd que use y sí, manejar algunas reglas de negocio como no permitir que un usuario utilice más de una pc. Actualmente tengo hecha la aplicación sin comunicación usuario-administrador y cada usuario se comunica directamente con la bd. Para cumplimentar esta regla de negocio cada usuario consulta la BD y busca el valor de un campo para ver si tiene otra sesión abierta en otra pc y de ser así se le deniega el acceso. Dado que una pc se puede colgar, dicho campo no se actualizaría provocando que el usuario no pueda entrar a otra sesión. Para evitar esto uso un campo que actualizo desde el usuario cada x tiempo. Si hay una sesión que parece activa todavía pero que su último acceso pasó de cierto timeout entonces le doy entrada. Todo esto es como muy estilo sesiones en Web y pensé que usando sockets facilitaría las cosas dejando que una aplicación central se encargara del registro de sesiones. En cuanto a lo de los Providers comunicados con sockets la verdad ni idea tengo, pero voy a ver qué puedo leer por ahí. // Saludos |
#4
|
||||
|
||||
Cita:
Cita:
Cita:
Cita:
Bien.. me voy a dormir, dejaremos esto en el tintero y charlamos de nuevo mañana... Hasta luego
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#5
|
||||
|
||||
Cita:
Cita:
Ahora, por otra parte, suponiendo que no voy tan mal encaminado con lo de los RemoteDataModules queda el asunto de los mensajes que los administradores mandan a los usuarios, pues si uso Indy por un lado y RemoteDatamodules por otro pues tengo dos canales distintos. Por eso había pensado que usando el mismo canal de los mensajes podía mandar el texto de la consulta SQL al servidor (lo que llamé AppControl) y éste mandaría la consulta a la BD. Muchas gracias jachguate por tu atención y nos leemos pronto. // Saludos |
#6
|
||||||
|
||||||
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
En fin... solo son ideas, creo que funcionaría de ambas formas, siempre dependiendo de los detalles de tu aplicación... Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
|
|
|