[Fwd: Re: [suse-linux-s] Aplicaciones cliente - servidor - era ¿Donde comprar Kylix?]
Carlos E. R. wrote:
El 2005-03-15 a las 16:07 +0100, miguel gmail escribió:
Bueno, lo que estamos hablando es de las ventajas/inconvenientes de uno y otro sistema. Yo lo que digo es que estos que dices, los scripts en servidor, no me convencen para cosas que empiecen a ser serias.
¿Serias como que? Podemos considerar, que una aplicación seria, puede ser de Home Banking, y hasta donde yo se, no tienes una conexión de BD desde tu pc al servidor, via internet, tan solo https.
En cambio, para paginas web es ideal, porque no tienes que hacer accesible la pagina web desde internet, sólo el apache. Por ejemplo, para ver el listado de productos de la empresa por los vendedores.
Como todo en ingeniería y en casi todas las ramas del saber, hay que contrapesar las necesidades, ventajas e inconvenientes, y decidir la salución más apropiada en cada caso.
Si nosotros pretendemos defender el software libre, y promovoer la adopción de linux, debemos tratar de optar por las soluciones multiplataforma. O acaso, en una oficina, donde tienes computadoras con ruindous, con linux, por otro lado tambien tienes Mac's con sistema operatio 8.0 y otras con OSX, vas a compilar tu aplicación para 4 sistemas operativos diferentes? Amen de eso, debes instalar esa aplicación en cada computadora, con su respectivo cliente de base de datos.
A mi lo que no me gusta es que, por un lado, si la aplicación cliente es pesadita estamos cargando más el servidor, puesto que se ejecuta allí.
Si una aplicación web es pesada, se debe a que tienes muchas consultas sobre BD, por lo cual, si corriera en forma local, tambien las tendrías, multiplicado por la cantidad de usuarios conectados a la BD.
Y, que por otro lado, la base de datos sólo ve un cliente, una conexión, y no puede controlar quien accede y que modifica: todo quisqui es la misma persona.
Craso error, cualquier CMS decente te permite definir que clase de acceso, si solo lectura, o modificación, o agregar y quitar registros. Todo depende de como está implementada la aplicación.
Parece que nunca experimentaste, lo que es tomar cualquier pc de la oficina, y conectarte a la BD mediante phpPgAdmin (postgres) o mysqladmin (mysql), crear tablas, realizar consultas, y exportarlas en xml, txt, o lo que se te de la gana, sin haber instalado nada en esa pc, con la unica condición, que tenga un browser decente. Creo que el unico motivo, para que un programador opte (en terminos generales) por aplicaciones residentes en cada pc (con su respectiva conección a BD en el servidor), es para justificar mas cantidad de horas a cobrarle al cliente. Cuando miran el bolsillo, allí es donde se olvidan de la implantación de linux, y del software multiplataforma y libre. No recuerdo haber vista la respuesta a la pregunta que hice, de que metodo se usa en las registradoras de los grandes supermercados, y si cada terminal tiene su propio usuario de BD. Ya se que no suele ser via browser. Diganme Uds. Saludos, Juan
Creo que el unico motivo, para que un programador opte (en terminos generales) por aplicaciones residentes en cada pc (con su respectiva conección a BD en el servidor), es para justificar mas cantidad de horas a cobrarle al cliente.
No entiendo este razonamiento, ¿es que cuando tu vendes un programa vas tu personalmente a instalarlo? Bueno supongo que si tienes que instalar un servidor apache, configurarlo, y despues hacer la instalacion de la aplicacion, no te quedará mas narices porque eso no lo hace cualquiera. Con una aplicacion residente en PC yo a mi cliente le vendo una caja con un CD y un manual y tan solo tiene que dar a 5 botones para tener su aplicacion corriendo, y no le cobró más si lo instala en 1 maquin o en mil. El problema de tu planteamiento es que la fase de implantacion es mas costosa que la otra.
Cuando miran el bolsillo, allí es donde se olvidan de la implantación de linux, y del software multiplataforma y libre.
Si tengo que pagar a un tecnico a que venga a instalarme el sistema igual no sale tan barato.
No recuerdo haber vista la respuesta a la pregunta que hice, de que metodo se usa en las registradoras de los grandes supermercados, y si cada terminal tiene su propio usuario de BD. Ya se que no suele ser via browser. Diganme Uds.
Yo tambien estoy interesado en esto, a ver si alguien responde algo
Saludos, Juan
Salu2 Emi
Emiliano Sutil wrote:
Creo que el unico motivo, para que un programador opte (en terminos generales) por aplicaciones residentes en cada pc (con su respectiva conección a BD en el servidor), es para justificar mas cantidad de horas a cobrarle al cliente.
No entiendo este razonamiento, ¿es que cuando tu vendes un programa vas tu personalmente a instalarlo? Bueno supongo que si tienes que instalar un servidor apache, configurarlo, y despues hacer la instalacion de la aplicacion, no te quedará mas narices porque eso no lo hace cualquiera.
Con una aplicacion residente en PC yo a mi cliente le vendo una caja con un CD y un manual y tan solo tiene que dar a 5 botones para tener su aplicacion corriendo, y no le cobró más si lo instala en 1 maquin o en mil.
El problema de tu planteamiento es que la fase de implantacion es mas costosa que la otra.
Cuando miran el bolsillo, allí es donde se olvidan de la implantación de linux, y del software multiplataforma y libre.
Si tengo que pagar a un tecnico a que venga a instalarme el sistema igual no sale tan barato.
No recuerdo haber vista la respuesta a la pregunta que hice, de que metodo se usa en las registradoras de los grandes supermercados, y si cada terminal tiene su propio usuario de BD. Ya se que no suele ser via browser. Diganme Uds.
Yo tambien estoy interesado en esto, a ver si alguien responde algo
¿Acaso nunca fuiste a algun supermercado tipo Wall Mart, Carrefour o como se llame alguno en su tipo, y te fijaste en el terminal de la cajera (ademas de la cajera ;-) )? Saludos, Juan
Juan Erbes wrote:
¿Acaso nunca fuiste a algun supermercado tipo Wall Mart, Carrefour o como se llame alguno en su tipo, y te fijaste en el terminal de la cajera (ademas de la cajera ;-) )?
Je je, sobre todo en la cajera.....En mi pueblo Carrefour es el q manda, y si me he fijado, pero no tengo la mas remota idea del tipo de software que corren esos terminales. Lo que si que tengo oido que para TPV se usa mucho linux, aunque esto lo se por revistas, nunca me he enfrentado a uno.
Saludos, Juan
Salu2, Emi
El 2005-03-17 a las 13:13 -0300, Juan Erbes escribió:
No recuerdo haber vista la respuesta a la pregunta que hice, de que metodo se usa en las registradoras de los grandes supermercados, y si cada terminal tiene su propio usuario de BD. Ya se que no suele ser via browser. Diganme Uds.
Yo tambien estoy interesado en esto, a ver si alguien responde algo
¿Acaso nunca fuiste a algun supermercado tipo Wall Mart, Carrefour o como se llame alguno en su tipo, y te fijaste en el terminal de la cajera (ademas de la cajera ;-) )?
No he trabajado en eso, no lo se. Claro que he mirado, pero lo único que se ve externamente es una impresora doble como mucho (listado interno y de ticket), y una pantalla numérica especial, para mostrar el precio en grande y el estado. Terminal tipo consola no he visto, quizás un pequeño lcd o alfanumérico de un par de lineas en algunas cajas, pero me parece que suelen usar el mismo del precio. En cambio, en algunos sitios, especialmente bares, tienen una pantallita tactil con los iconos de las bebidas. Y eso se de un amigo hace años que empezó a hacerlo en msdos. No están en red. Si se de cosas que se hicieron en msdos, o en una versión que llamaron msdos para grupos, y se siguen usando. Y funcionan mejor que en windows, para lo que son. Los cajeros de muchos bancos funcionan con OS/2, los he visto rebotar. Aunque me suena haber visto alguno con una pantalla de windows, pero no pondría la mano en el fuego. -- Saludos Carlos Robinson
Hola a Todos. El Jueves, 17 de Marzo de 2005 17:13, Juan Erbes escribió:
¿Acaso nunca fuiste a algun supermercado tipo Wall Mart, Carrefour o como se llame alguno en su tipo, y te fijaste en el terminal de la cajera (ademas de la cajera ;-) )?
Las aplicaciones "grandes" como SAP o Peoplesoft (Wall Mart), son cliente servidor a 3 niveles (por eso SAP cambio su nombre a SAP R3), Nosotros en la Empresa tenemos JD Edwards, que a nivel tecnologico tiene un esquema similar. Basicamente estos sistemas tienen 3 capas : Servidor de BBDD Servidor de Aplicacion Cliente el Cliente NO ACCEDE al servidor de BBDD directamente, siempre a traves del SERVIDOR de Aplicacion. Bueno, JD Edwards extiende un poco mas el tema, tiene un Mapeador de procesos que te permite especificar por procesos o funciones, para quien y donde se ejecutan cada una, de forma que haya procesos que puede correr el cliente directamente y hay otros que se envian al servidor para procesar. en esos casos el cliente si interactua con la BBDD. Ademas en este esquema, se pueden tener varios servidores de BBDD y varios servidores de Aplicacion y balancear carga por usuarios, departamentos, tipos de procesos, etc. Por ultimo se ha extendido a este esquema la integracion de un portal Web y un Servidor de Aplicaciones Web, de forma que se pueden tener clientes web, que atacan al servidor de aplicaciones a traves del servidor de aplicacions Web. Esto ultimo permite pasar a tener clientes "ligeros" y balancear la carga todavia mas. Es mas, en este esquema Peoplesoft admite servidores y clientes Linux. En cuanto al acceso web, incluso tienen un sistema en el que no transmiten pagina a pagina, sino campo a campo al cambiar el foco de forma que el feeling es el de un cliente pesado. (mas paquetes por la red, pero mas pequeños). En fin. Creo que hoy en dia, los tiros van por crear aplicaciones con forntend web, de forma que te aseguras que el cliente tiene costes de mantenimiento 0 y el aprendizaje se reduce a saber usar un navegador. En cuanto al servidor, creo que sigue siendo aplicable el concepto de las 3 capas Cliente, Servidor de Aplicacion, Servidor de BBDD. En cuanto a la carga de la BBDD lo que importa son las consultas concurrentes, da practicamente lo mismo si las pide todas un usuario o si las piden n usuarios. las tareas a realizar por la BBDD son las mismas. Espero haber aportado mi granito de arena -- Un Saludo. Carlos Lorenzo Matés
Carlos Lorenzo Matés wrote:
Hola a Todos.
El Jueves, 17 de Marzo de 2005 17:13, Juan Erbes escribió:
¿Acaso nunca fuiste a algun supermercado tipo Wall Mart, Carrefour o como se llame alguno en su tipo, y te fijaste en el terminal de la cajera (ademas de la cajera ;-) )?
Las aplicaciones "grandes" como SAP o Peoplesoft (Wall Mart), son cliente servidor a 3 niveles (por eso SAP cambio su nombre a SAP R3), Nosotros en la Empresa tenemos JD Edwards, que a nivel tecnologico tiene un esquema similar.
Basicamente estos sistemas tienen 3 capas :
Servidor de BBDD Servidor de Aplicacion Cliente
el Cliente NO ACCEDE al servidor de BBDD directamente, siempre a traves del SERVIDOR de Aplicacion.
Bueno, JD Edwards extiende un poco mas el tema, tiene un Mapeador de procesos que te permite especificar por procesos o funciones, para quien y donde se ejecutan cada una, de forma que haya procesos que puede correr el cliente directamente y hay otros que se envian al servidor para procesar. en esos casos el cliente si interactua con la BBDD.
Ademas en este esquema, se pueden tener varios servidores de BBDD y varios servidores de Aplicacion y balancear carga por usuarios, departamentos, tipos de procesos, etc.
Por ultimo se ha extendido a este esquema la integracion de un portal Web y un Servidor de Aplicaciones Web, de forma que se pueden tener clientes web, que atacan al servidor de aplicaciones a traves del servidor de aplicacions Web.
Esto ultimo permite pasar a tener clientes "ligeros" y balancear la carga todavia mas.
Es mas, en este esquema Peoplesoft admite servidores y clientes Linux.
En cuanto al acceso web, incluso tienen un sistema en el que no transmiten pagina a pagina, sino campo a campo al cambiar el foco de forma que el feeling es el de un cliente pesado. (mas paquetes por la red, pero mas pequeños).
En fin. Creo que hoy en dia, los tiros van por crear aplicaciones con forntend web, de forma que te aseguras que el cliente tiene costes de mantenimiento 0 y el aprendizaje se reduce a saber usar un navegador. En cuanto al servidor, creo que sigue siendo aplicable el concepto de las 3 capas Cliente, Servidor de Aplicacion, Servidor de BBDD.
En cuanto a la carga de la BBDD lo que importa son las consultas concurrentes, da practicamente lo mismo si las pide todas un usuario o si las piden n usuarios. las tareas a realizar por la BBDD son las mismas.
Espero haber aportado mi granito de arena
Mas que un grano de arena! Muchas gracias. Espero que les quede claro a quienes se tiran contra las aplicaciones con frontend web. O estas no son "aplicaciones serias", como les llaman? :-D Saludos, Juan
El Jue 17 Mar 2005 11:45 AM, Juan Erbes escribió:
No recuerdo haber vista la respuesta a la pregunta que hice, de que metodo se usa en las registradoras de los grandes supermercados, y si cada terminal tiene su propio usuario de BD. Ya se que no suele ser via browser. Diganme Uds.
Saludos, Juan
Regularmente, se utiliza un solo usuario para el manejo de BD desde los POS. Pero, la autenticación por usuario que se hace en el propio POS, es para cargar los perfiles (roles) y el LOG se maneja muchas veces desde el propio software (los LOGs de eventos por usuario, no los del sistema ni de la BD). -- ********************************* Hugo Sandoval Consultor Senior www.softwarelibre.com.ve hugo@softwarelibre.com.ve spock@linux.org.ve hsandoval@ven.org hugospock@yahoo.com 58-261-7560687 58-416-4617402 58-261-7560836 ********************************* "Linux se escribe con 1 'L': L de Libertad. Microsoft se escribe con 4 'M': Monopolio. Malo. Muy Malo." HS: caviliáte!
Hugo Sandoval wrote:
El Jue 17 Mar 2005 11:45 AM, Juan Erbes escribió:
No recuerdo haber vista la respuesta a la pregunta que hice, de que metodo se usa en las registradoras de los grandes supermercados, y si cada terminal tiene su propio usuario de BD. Ya se que no suele ser via browser. Diganme Uds.
Saludos, Juan
Regularmente, se utiliza un solo usuario para el manejo de BD desde los POS. Pero, la autenticación por usuario que se hace en el propio POS, es para cargar los perfiles (roles) y el LOG se maneja muchas veces desde el propio software (los LOGs de eventos por usuario, no los del sistema ni de la BD).
Gracias por tu respuesta. Tenía la idea de que funcionase así, pero me puedes confirmar el tipo de conección de los POS, si es de tipo telnet? En mi trabajo, todavía se sigue usando una aplicación que originalmente, la interfaz ususrio eran terminales Wyse 60, pero por cuestiones practicas, hoy en dia se usa en pc con un emulador de terminal, y el servidor utiliza una base de datos Universe y se está estudiando la migracion a Oracle. Otra aplicación similar, se ha migrado a un entorno gráfico, con algunas adaptaciones en el servidor (ademas de su reemplazo por uno mas rapido), y donde ahora cada usuario se loguea en la BD, pero con un rendimiento final inferior al anterior. De paso, aprovecho a pasarles el link de una aplicación muy interesante, basada en php: http://phpremoteshell.labs.libre-entreprise.org/ Saludos, Juan
El Vie 18 Mar 2005 10:35 AM, Juan Erbes escribió:
Gracias por tu respuesta. Tenía la idea de que funcionase así, pero me puedes confirmar el tipo de conección de los POS, si es de tipo telnet?
Madre Santa de todos los bits ! Telnet! jejeje, si, puede ser telnet, pero actualmente se desarrollan muchisimas aplicaciones POS (PDV) en modo gráfico con n capas, ya sea a travéz de web (claro, en una LAN, es mas conveniente ;-) o como aplicación que corre del lado del cliente, en este caso el propio POS (PDV). El telnet se utilizó mucho como una forma de tener los recursos centralizados (datos, aplicación, carga, etc) y los POS eran equipos discretos solo con el SO cargados en una ROM (por ejemplo, no polemizar por fa.. jejeje ). La raza humana evoluciona. Ahora podemos tener los mismos POS discretos y cargando el SO desde una USB y conectandose a un servidor de aplicaciones o cualquier otra cosa que se les ocurra, sin necesidad de utilizar Tel-Net. Saludos. -- ********************************* Hugo Sandoval Consultor Senior www.softwarelibre.com.ve hugo@softwarelibre.com.ve spock@linux.org.ve hsandoval@ven.org hugospock@yahoo.com 58-261-7560687 58-416-4617402 58-261-7560836 ********************************* "Linux se escribe con 1 'L': L de Libertad. Microsoft se escribe con 4 'M': Monopolio. Malo. Muy Malo." HS: caviliáte!
El 2005-03-17 a las 12:45 -0300, Juan Erbes escribió:
Subject: [Fwd: Re: [suse-linux-s] Aplicaciones cliente - servidor - era ¿Donde comprar Kylix?]
Ya lo vi, no hace falta que hagas un forward. Estaba pensando ;-)
Carlos E. R. wrote:
El 2005-03-15 a las 16:07 +0100, miguel gmail escribió: Bueno, lo que estamos hablando es de las ventajas/inconvenientes de uno y otro sistema. Yo lo que digo es que estos que dices, los scripts en servidor, no me convencen para cosas que empiecen a ser serias.
¿Serias como que? Podemos considerar, que una aplicación seria, puede ser de Home Banking, y hasta donde yo se, no tienes una conexión de BD desde tu pc al servidor, via internet, tan solo https.
Cierto, touche. Aunque no se como están construidas. Y mucha guerra que dan, salvo las que están preparadas para netscape...
En cambio, para paginas web es ideal, porque no tienes que hacer accesible la pagina web desde internet, sólo el apache. Por ejemplo, para ver el listado de productos de la empresa por los vendedores.
Como todo en ingeniería y en casi todas las ramas del saber, hay que contrapesar las necesidades, ventajas e inconvenientes, y decidir la salución más apropiada en cada caso.
Si nosotros pretendemos defender el software libre, y promovoer la adopción de linux, debemos tratar de optar por las soluciones multiplataforma. O acaso, en una oficina, donde tienes computadoras con ruindous, con linux, por otro lado tambien tienes Mac's con sistema operatio 8.0 y otras con OSX, vas a compilar tu aplicación para 4 sistemas operativos diferentes?
¿Porque no? ;-P Dependerá. Lo normal en esos casos es que se exija un tipo de ordenadores determinado, o un par de tipos. En mi opinión, el cliente tiene derecho a elegir que es lo que quiere, y los informáticos, a plantearles "asépticamente" los costes de cada una de las soluciones posibles. Y, precisamente en ese contexto, herramientas como kylix, si están bien hechas, es donde cuentan con ventaja: la misma aplicación debería funcionar en varios sistemas. Es un objetivo un tanto utópico quizás, pero que estaría muy bien.
Amen de eso, debes instalar esa aplicación en cada computadora, con su respectivo cliente de base de datos.
Bueno... creo recordar que el vantive que mencioné las aplicaciones cliente se podían instalar remotamente. Es decir, se instalaba una imagen inicialmente, y luego las actualizaciones eran automáticas cuando decidían ellos. Para algo costaba millones.
A mi lo que no me gusta es que, por un lado, si la aplicación cliente es pesadita estamos cargando más el servidor, puesto que se ejecuta allí.
Si una aplicación web es pesada, se debe a que tienes muchas consultas sobre BD, por lo cual, si corriera en forma local, tambien las tendrías, multiplicado por la cantidad de usuarios conectados a la BD.
Posiblemente. Pero si es una base de datos con un considerable trabajo de edición y calculo, pues se nota. Y eso no es trabajo de la BD, sino de la parte cliente.
Y, que por otro lado, la base de datos sólo ve un cliente, una conexión, y no puede controlar quien accede y que modifica: todo quisqui es la misma persona.
Craso error, cualquier CMS decente te permite definir que clase de acceso, si solo lectura, o modificación, o agregar y quitar registros. Todo depende de como está implementada la aplicación.
¿Que es CMS? Recuerda que no soy programador de bases de datos.
Parece que nunca experimentaste, lo que es tomar cualquier pc de la oficina, y conectarte a la BD mediante phpPgAdmin (postgres) o mysqladmin (mysql), crear tablas, realizar consultas, y exportarlas en xml, txt, o lo que se te de la gana, sin haber instalado nada en esa pc, con la unica condición, que tenga un browser decente.
No, no he tenido ocasión de hacerlo con eso. He hecho multitud de consultas en Access que he importado en Excel y Word, para hacer informes semanales y mensuales y estadísticas diversas. Pero si he manejado otras aplicaciones en intranet via web, como una herramienta de control y vigilancia de redes de telecomunicación. Para empezar, tuvimos que aumentarle la memoria a todos los PCs de sus originales 64megas a 255 (previo pedido a compras y espera consiguiente), porque si no el iexplorer no daba a basto. Eramos media docena de usuarios a lo sumo, con un maquinon de servidor, y demasiado lento. La versión anterior usaba terminales tontos graficos X, de unix, con CDE (que no es KDE, pero se parecía horrores). Los clientes podían ser terminales tontos, Sun, windows, Linux... y funcionaban mucho, pero mucho más rápidos que la puñetera aplicación webis ultramoderna y fassion. No era una base de datos, aunque contenía una base de datos (y no me preguntes cual, porque no recuerdo. Oracle o propia incluso. Por eso les tengo tirria a las aplicaciones web grandes y centralizadas...
Creo que el unico motivo, para que un programador opte (en terminos generales) por aplicaciones residentes en cada pc (con su respectiva conección a BD en el servidor), es para justificar mas cantidad de horas a cobrarle al cliente. Cuando miran el bolsillo, allí es donde se olvidan de la implantación de linux, y del software multiplataforma y libre.
No. Como dije, cada proyecto lleva sus propias decisiones, a considerar todos los pros y contras de cada una de las soluciones posibles, incluyendo los costes de cada una. En cada caso, se tomará la que se crea conveniente... Eso es la teoría claro. Pero es lo que yo trato de hacer: con dos perspectivas distintas, según de que lado de la moneda esté. Si compro, puedo elegir más libremente (jefes aparte). Si vendo, y no se hacerlo de cierta manera, pues no la voy a ofrecer de esa manera precisamente ;-)
No recuerdo haber vista la respuesta a la pregunta que hice, de que metodo se usa en las registradoras de los grandes supermercados, y si cada terminal tiene su propio usuario de BD. Ya se que no suele ser via browser. Diganme Uds.
Pues porque no lo se. En otro mensaje he comentado lo que creo. -- Saludos Carlos Robinson
Carlos E. R. wrote:
El 2005-03-17 a las 12:45 -0300, Juan Erbes escribió:
Craso error, cualquier CMS decente te permite definir que clase de acceso, si solo lectura, o modificación, o agregar y quitar registros. Todo depende de como está implementada la aplicación.
¿Que es CMS? Recuerda que no soy programador de bases de datos.
CMS viene de la sigla inglesa Content Management System, y mira cuantos tienes (no se si estaran todos): http://www.cmsmatrix.org/matrix Por otro lado, hay una aplicación muy sencilla y flexible basada en php, para manejo de BD, carga, actualización, reportes, etc y se llama dadabik, muy facil de configurar, donde el tema seguridad, debes tomar la precaución de que tipo de acceso le das a cada usuario: http://www.dadabik.org/ http://www.dadabik.org/index.php?function=show_documentation Saludos, Juan
participants (5)
-
Carlos E. R.
-
Carlos Lorenzo Matés
-
Emiliano Sutil
-
Hugo Sandoval
-
Juan Erbes