Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Internet
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Grupo de Teaming del ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 01-05-2004
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
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
Responder Con Cita
  #2  
Antiguo 01-05-2004
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: may 2003
Ubicación: Guatemala
Posts: 6.254
Poder: 27
jachguate Va por buen camino
Cool

Cita:
Empezado por roman
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.
Hasta aqui todo iba mas o menos bien... pero esto si no lo he entendido muy bien. Hay alguna razón extra para meter esta tercera capa contra la BD??

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:
Empezado por roman
Lo que quiero es su opinión acerca de este esquema. ¿Es adecuado para la situación planteada o me estoy complicando la vida?
Honestamente me parece que si... si las operaciones con la BD son sencillas y los clientes no son muchos... yo dejaria que cada cliente se entienda con la BD, y probablemente que AppAdmin se conectara directamente con AppUsuario.

Hasta luego.

__________________
Juan Antonio Castillo Hernández (jachguate)
Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
Responder Con Cita
  #3  
Antiguo 01-05-2004
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
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
Responder Con Cita
  #4  
Antiguo 01-05-2004
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: may 2003
Ubicación: Guatemala
Posts: 6.254
Poder: 27
jachguate Va por buen camino
Cool

Cita:
Empezado por roman
A ver, nada de analista experimentado, al contrario.
ufff... que modesto
Cita:
Empezado por roman
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.
Bueno, creo que esto ya es suficiente justificación. No habias mencionado antes que podria haber mas de un Admin.

Cita:
Empezado por roman
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.
Y las consultas... no son muy complicadas?.. si te es posible, evalua el uso de ClientDatasets, comunicados también por Sockets a la capa intermedia, pero aprovechando lo ya encapsulado en estos componentes.

Cita:
Empezado por roman
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.
El problema del cuelgue de la pc... sin "despedirse" lo vas a seguir enfrentando... asi que vas a llegar tarde o temprano a una solución similar a esta; entonces por qué no dejar la que ya tenes? (me refiero a la lógica... la implementación, claro, seria desde la capa intermedia)

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
Responder Con Cita
  #5  
Antiguo 01-05-2004
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Cita:
Empezado por jachguate
evalua el uso de ClientDatasets, comunicados también por Sockets a la capa intermedia, pero aprovechando lo ya encapsulado en estos componentes.
Bien a bien no sé a qué te refieres. Lo que estuve leyendo hace un rato fue acerca de RemoteDatamodules, ClientDataSets y Providers aunque sólo llegué al ejemplito de Login que viene en la carpeta Demos\Midas que parece relacionado aunque todavía me falta para ver cómo un cliente le dice al servidor cositas como "muéstrame en mi ClientDataSet la lista de usuarios". Bueno, sí vi que podría colocar un dataset enlazado a la lista de usuarios en el servidor y conectado al clientdataset del cliente pero me falta ver cómo podría hacer consultas más complicadas.

Cita:
Empezado por jachguate
El problema del cuelgue de la pc... sin "despedirse" lo vas a seguir enfrentando... asi que vas a llegar tarde o temprano a una solución similar a esta; entonces por qué no dejar la que ya tenes? (me refiero a la lógica... la implementación, claro, seria desde la capa intermedia)
Bueno, es que cuando estuve echándole un ojo a los ejemplos de las Indy me quedé con la idea de que la lógica del timeout ya estaba de alguna manera ímplicita y por ello pensé que cuando el IdTcpServer detectara una conexión cortada, en ese momento mandaría la consulta SQL a la BD para registrar que la sesión había terminado.

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
Responder Con Cita
  #6  
Antiguo 05-05-2004
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: may 2003
Ubicación: Guatemala
Posts: 6.254
Poder: 27
jachguate Va por buen camino
Cool

Cita:
Empezado por roman
acerca de RemoteDatamodules, ClientDataSets y Providers
Por alli van los tiros..
Cita:
Empezado por roman
me falta para ver cómo un cliente le dice al servidor cositas como "muéstrame en mi ClientDataSet la lista de usuarios"
En realidad, vas a tener un client dataset por cada Query o tabla de tu RemoteDataModule, asi que estos estaran "especializados" de entrada.
Cita:
Empezado por roman
. me falta ver cómo podría hacer consultas más complicadas.
. Esto es en la capa intermedia... podes meter cualquier sentencia SQL en un TQuery, conectarla a un provider, e "invocarla" desde el cliente...

Cita:
Empezado por roman
Bueno, es que cuando estuve echándole un ojo a los ejemplos de las Indy me quedé con la idea de que la lógica del timeout ya estaba de alguna manera ímplicita y por ello pensé que cuando el IdTcpServer detectara una conexión cortada, en ese momento mandaría la consulta SQL a la BD para registrar que la sesión había terminado.
No he trabajado de esta manera con las INDY, pero si ya lo encontraste... pos ya'sta, no??
Cita:
Empezado por roman
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.
Eso es cierto... pero en mi humilde opinión, creo que ese costo es justo... habrá que ver.

Cita:
Empezado por roman
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.
Esto depende de la complejidad de las consultas, y de la cantidad de datos que viajarian. Por este otro lado, un cliente, incluso no tendria que mandar toda una consulta SQL al servidor... sino un comando (con los parámetros adecuados) para que el servidor ejecute una consulta ya conocida por este.

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
Responder Con Cita
  #7  
Antiguo 05-05-2004
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Hola jachguate

He estado no diré que estudiando sino leyendo algunas cosas y vagando por aquí y por allá. Veo que lo de los RemoteDataModules es más sencillo (igual me equivoco pero de entrada así parece) de lo que pensaba. O mejor dicho, que Borland colocó todo para que fuera prácticamente igual que en una aplicación de una sola capa.

De alguna manera veo que son dos opciones las que se ajustarían a lo que quiero: DCOM y Sockets. En varios lados mencionan la dificultad de configurar DCOM aunque como todavía no lo he probado más que en local pues no sé a qué se refiera dicha complejidad y por otro lado pareciera que los sockets darían más flexibilidad en cuanto al tipo de clientes que podrían acceder en un futuro. Pero veo que el problema con los sockets es que, tal como se maneja con los RemoteDataModules, la capa intermedia maneja un único cliente a través de ScktSrvr.exe que administra todos los accesos.

Poco después de mi mensaje anterior me di cuenta que la pregunta de las consultas SQL "especializadas" era un poco tonta, esto es, si puedo colocar un TTable (como en el demo de Delphi) seguro puedo colocar cualquier DataSet en la capa intermedia y esto incluye claro cualquier tipo de Query. Pero entonces me viene otra duda: muchas veces nos encontramos aquí sugieriendo construir consultas "al vuelo", ¿cómo se haría esto aquí?

Esto de los dos canales (DCOM e Idy o ScktSrvr.exe e Indy) entiendo lo que dices, quizá sea un justo precio pero pienso: si hago una comunicación por sockets ¿para que establecer otra igualmente por sockets?

Buscándole vi gente que propone usar una capa intermedia mediante Indy y ADO olvidándose de DCOM y ClientDataSets. No lo he visto en detalle pero quien lo propone parece ser muy convincente en cuanto a sus posibilidades o por lo menos contestó puntualmente a casi todos los peros que le ponían. Viendo esto me acordé entonces del demo que viene con las Indy (TCPDataSet) en donde usan componentes Indy junto con un dataset en memoria, el TKBMMemTable, que parece que tiene un buen manejo de envio y recepción de cursores mediante una binarización de los datos. A fin de cuentas, esto es lo que hace DCOM ¿no? empaquetar los datos de alguna forma para que sea fácil transportarlos. Si esta opción fuera viable me permitiría usar el mismo canal de comunicación para el envío de consultas así como de otro tipo de información.

Bueno, sé que por ahora sólo divago pero realmente nunca he trabajado así y apenas empiezo a picarle aquí y allá.

Una pregunta sí hago sin embargo:

En la capa intermedia, de cualquier forma que se haga habrá, a fin de cuentas varios accesos simultáneos y supongo que de alguna manera hay que controlar las concurrencias. Si uso DCOM o ScktSrvr.exe este manejo ¿ya está dado? O tengo que preocuparme de hilos y demás yerbas. Si uso Indy no sé porque pienso que sería más sencillo en cuanto a que Indy ya maneja un hilo por cada cliente.

Bueno, no espero que contestes ya que realmente no estoy diciendo ni casi preguntando nada pero seguiré curioseando.

// Saludos
Responder Con Cita
  #8  
Antiguo 06-05-2004
Toni Toni is offline
Miembro
 
Registrado: may 2003
Ubicación: Barcelona - España
Posts: 364
Poder: 21
Toni Va por buen camino
Hola amigos,

Solo comentar unas cosillas:

Si utilizas remote data modules bien sea con DCOM o con sockets no tienes que preocuparte de las conexiones en la capa intermendia, pues las gestiona automaticamente. Ahora bien los problemas con la concurrencia si que tienes que gestionarla tu desde el cliente.

Utilizando ClientDataSets puedes manejar un conjunto de datos remoto de forma local hasta que realizas un ApplyUpdates(); y envias los cambios al servidor, si en ese momento hubiese algun problema de concurrencia lo podrias tratar en el evento OnReconcileError del mismo.

Otra cosa, tambien puedes utilizar sin problemas varias conexiones por sockets por diferentes puertos para cada uso. Uno para el acceso a los datasets y otro para los mensajes a los usuarios.

Saludos,
__________________
Saludos,

Bitman
Responder Con Cita
  #9  
Antiguo 06-05-2004
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Hombre, muchas gracias por tus comentarios Toni.

Más o menos me quedan claros los conceptos pero esto

Cita:
Empezado por Toni
Ahora bien los problemas con la concurrencia si que tienes que gestionarla tu desde el cliente.
no lo entiendo. ¿No tendrían que manejarse desde el servidor?

// Saludos
Responder Con Cita
  #10  
Antiguo 07-05-2004
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: may 2003
Ubicación: Guatemala
Posts: 6.254
Poder: 27
jachguate Va por buen camino
Cool

Cita:
Empezado por roman
¿No tendrían que manejarse desde el servidor?
Desde el servidor de aplicaciones... que a su vez es el cliente de la base de datos...

Hasta luego.

__________________
Juan Antonio Castillo Hernández (jachguate)
Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
Responder Con Cita
  #11  
Antiguo 07-05-2004
Toni Toni is offline
Miembro
 
Registrado: may 2003
Ubicación: Barcelona - España
Posts: 364
Poder: 21
Toni Va por buen camino
Todo esto es en terminos generales, depende de la acción a realizar.

De todas formas me venia a referir que tu desde el cliente (interfaz de usuario) en determinados casos tendras que decidir si quieres realizar una operación que modifique un unico registro o varios y si envias los cambios uno a uno o en conjunto al servidor de aplicaciones.

Y en el momento del envio (ApplyUpdates) desde el propio cliente tienes que decir en cada caso si ocurre un error de integridad o concurrencia que acción realizas.

Todo es muy relativo según como enfoques tu aplicación, claro esta.

Saludos,
__________________
Saludos,

Bitman
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 19:08:59.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi