La pregunta que todos nos hacemos, o deberíamos, después de haber leído las dos entradas anteriores sobre cliente-servidor y aplicaciones Web (no dejes de hacerlo antes de leer ésta): Si las aplicaciones Web tienen tantas ventajas, ¿por qué se sigue utilizando la arquitectura cliente-servidor?
La respuesta es muy sencilla: el usuario. El usuario debería ser el centro de la discusión. Debería estar siempre presente en los departamentos de desarrollo, como lo está en los departamentos comerciales que tienen que venderle a él, y no a ingenieros ni programadores, el producto. El usuario manda, y el usuario no quiere productos «tecnológicamente avanzados», quiere programas cómodos, ágiles, intuitivos…
Y este es el talón de Aquiles de muchas aplicaciones Web: el interfaz y la «experiencia» de uso. Es aquí donde salen a la luz los dos problemas principales de los clientes Web (especialmente en programas de gestión documental):
1.- Los tiempos de espera para «subir» o «bajar» los documentos del servidor «remoto» (sea de «la nube» o de las oficinas centrales). En una red local corrientita, un PDF de varios folios puede tardar décimas de segundo en viajar desde el servidor (que está en la habitación de al lado). Si es un fichero realmente grande, igual tarda unos segundos. Pero en una «arquitectura Web», si no estamos en la NASA tenemos un cuello de botella importante en la conexión a Internet y las décimas de segundo pasarán a segundos y los segundos pueden llegar a minutos. Y, desafortunadamente, en España tenemos bastante experiencia con las conexiones lentas, lentas, a Internet.
2.- La «usabilidad» o «amigabilidad» (es una traducción horrible del muy expresivo «user friendly» inglés) de la interfaz de usuario. Este es mi tema favorito. Supongo que es una deformación de mis primeros pasos en la programación, hallá por el 83, cuando hice algunos videojuegos. ¡Me encantan las pantallas de los videojuegos! Tienen los mejores interfaces del mundo. ¡Un niño de 7 ú 8 años maneja la Wii o la PS3 sin ninguna ayuda! Eso es un interfaz intuitivo. Y, además, suelen ser muy bonitos. Pero, qué te encuentras en muchas aplicaciones Web: nada. Una basura. He llegado a ver un interfaz (por llamarlo de alguna forma) de un programa de gestión documental que era ¡una lista de opciones subrayadas!
Así que, cuando el usuario se enfrenta a dos programas de gestión documental, uno desarrollado con las herramientas propias de una aplicación cliente-servidor (como Delphi o Visual Basic) y el otro basado en un navegador Web (como Internet Explorer o Firefox) lo más normal es que se encuentre mucho más cómodo con la aplicación cliente-servidor. Y esta es una experiencia real, no es una elucubración teórica.
Y es normal. Los lenguajes que me permiten construir «clientes pesados» son mucho más potentes, además de tener muchos más años de desarrollo (pero esto es lo de menos). Son más «potentes» porque el hecho de montar un software «pesado» en el cliente proporciona al programador muchas más herramientas, componentes, objetos, libertad para hacer lo que quiera. Para controlar perfectamente el flujo de entrada de datos. Para mostrar ayudas, listas, atajos… sin ningún retraso.
En el otro lado, los programadores de páginas Web, porque a fin de cuentas la interfaz de una aplicación Web es una página Web, están mucho más limitados en sus opciones porque están creando un programa «limitado» a las opciones del navegador. Es verdad que recientemente hay herramientas de desarrollo (sobre todo sobre Java) que han mejorado mucho este aspecto, pero la realidad es que estas aplicaciones suelen ser mucho más incómodas para los usuarios. Y el usuario no entiende de excusas técnicas. No quiere esperas al introducir los datos. No quiere que se le borre un formulario completo porque le da a la tecla de retroceso y el navegador vuelve a la pantalla anterior.
Cuando la movilidad es la clave y los datos a introducir son pocos, la arquitectura Web es la ganadora. Pero en una aplicación de entrada de datos, con un uso intensivo y reducida a una o pocas oficinas, los programas basados en cliente-servidor son los preferidos por los usuarios (que son los que pagan).
El lector inteligente (que supongo que lo serán todos de este blog tan poco entretenido) habrá llegado a la misma conclusión que yo: lo ideal es una instalación mixta. ¡Claro que sí!
En la oficina central, en el departamento que más datos introduce instalamos clientes pesados conectados en red local con el servidor que contiene los datos. Trabajan a toda velocidad, sin retrasos, con un interfaz intuitiva, que les ayuda a introducir la información lo más rápido posible. A los usuarios que se limitan a consultar los documentos o introducir alguno de forma esporádica, le damos acceso usando un cliente ligero, un navegador Web. Ellos prefieren la movilidad, aunque sea a costa de un poco menos de «usabilidad». ¡Esta es la arquitectura mejor, la que combina lo mejor de los 2 modelos!
Una última reflexión para los fanáticos de los clientes ligeros y la arquitectura Web. ¿Cual es la empresa que siempre citamos como ejemplo glorioso de esta arquitectura? Google. Todo en la nube, todo descentralizado, un navegador Web para acceder al correo, a las búsquedas… hasta se habla de su inminente sistema operativo basado en la nube.
Ahora pensemos en uno de sus productos «estrella», el más vistoso, el que más nos ha sorprendido y maravillado: Google Earth. Y ¿qué utiliza Google Earth para conseguir esa maravillosa experiencia de volar por todo el mundo? un cliente «pesado«, un cliente que descargamos en todos y cada uno de los ordenadores que acceden a los mapas y fotos. Cuando queremos una buena experiencia de usuario, hay que usar clientes pesados. Y ahora ¡imagina lo que sería Google Earth si los datos estuvieran en tu ordenador local y no hubiera retrasos al cargas las fotos! ¿No sería una gozada? Así que la próxima vez que oigas hablar de una arquitectura cliente-servidor, no la desprecies tan rápidamente.
si som mente de pollos
mentira la imformacion esta muy interesante gracias por su servicio
No entiendo muy bien los dos comentarios, pero no quisiera censurarlos sin motivo.
Creo que he dado con el artículo :). Interesante reflexión Fernando, algún día estaría bien comentar sobre HTML5 y el almacenamiento local de datos, ese va a ser un buen paso en los tiempos de respuesta.
Creo que el 2º comentario de Luis viene a responderte a tu comentario:
Fernando: «El lector inteligente (que supongo que lo serán todos de este blog tan poco entretenido)»…
Luis: «mentira la imformacion esta muy interesante gracias por su servicio»
🙂
Salu2
Cuando quieras hacemos una mesa redonda, o simplemente quedamos a desayunar que es más cómodo.
Pero si hablamos de usabilidad, me refería a mi post de hace una semana.
Un saludo y gracias por el comentario.
Creo que hay factores esenciales a considerar , por ejemplo muchas de las las aplicaciones web son multiplataforma, esto supone una gran ventaja, ayuda a reducir costos de licenciamiento y a no necesitar equipos tan robustos del lado del cliente, aspectos sin duda atractivos para cualquier empresa.
Un Saludo
Sin duda llevas razón. Y si el número de usuarios es muy grande esta ventaja puede ser decisiva para elegir esta arquitectura.
Pero para una PYME de 4 ó 5 puestos de trabajo es irrelevante. ¡No van a tener unos Windows y otros MAC trabajando con los mismos programas en la misma oficina!
En estos casos, esta ventaja se diluye. Y no olvidemos que el 95% de las empresas son PYMES.
En resumen, a cada uno se le debe instalar lo que más se adecúa a sus necesidades.
Hola, soy ing.de sistemas y estoy pensando en una arquitectura mixta para un sistema y no he encontrado mucha info, hasta que caí en esta página.
Ultimamente se ha promocionado la arq. web como la solucion a todo pero me he dado cuenta que a los usuarios no les gusta. Estamos cambiando sistemas cliente servidor por sistemas web y los usuarios estan cada vez mas desconformes. Estamos generando toda una generacion de sistemas que a la vista de los usuarios son peores que la generacion anterior! y nos enorgullecemos por esta gran «innovacion».
Estoy a punto de iniciar el desarrollo de un sistema grande con arquitectura mixta. Alguien tiene alguna opinion o experiencia?
Otra pregunta: Alguien ha tenido alguna experiencia para resolver el problema de implantacion en cliente servidor y asegurar que todas las maquinas esten correctamente instaladas las nuevas versiones cuando se actualiza el sistema y instalar eficientemente? A mi se me ocurre que la aplicacion Cliente/Servidor se comunique con un servidor de aplicaciones al iniciarse y verifique si hay una version mas actual y se descargue automaticamente y instale la nueva version, en caso contrario que no se pueda ejecutar. Esto resolveria uno de los principales problemas de Cliente/Servidor que es el deploy.
Saludos!
Bueno, no puedo estar más de acuerdo contigo. El foco de un proyecto de software debe estar en el usuario, por encima de todo, y en las aplicaciones Web muchas veces se da prioridad a ventajas técnicas o de mantenimiento que al usuario, que es el que paga.
En cuanto a tu proyecto, nosotros hace muchos años que utilizamos un sistema similar. Incluso mejor.
Al arrancar la aplicación ésta se conecta con nuestro servidor y le informa de que hay una nueva versión (cuando la hay, claro). Le da la opción de descargarla y queda a disposición del resto de usuarios que ya no tienen que bajarla de Internet. Funciona muy bien.
Un saludo y gracias por tu comentario.
Quizás en un futuro, las aplicaciones web tengan la misma «usabilidad» que las cliente-servidor. No sé si las tendencias van por ese camino. Pero creo que el desarrollo web está ganando algo de terreno en ese sentido.
[…] Cliente-servidor Vs Aplicaciones Web enero, 2010 10 comentários 4 […]
Solo veo resistencia al cambio, incoherencias y mas resistencia al cambio… la migracion de escritorio a web es abismal y si haces una app web mal diseñada y poco funcional seguramente a nadie gustara, eso no tiene nada que ver con la tecnologia web… algunos se quedaron en los 80…
En las novelas de Agata Cristi el asesino siempre tenía un móvil (casi siempre el dinero). En este caso soy poco sospechoso de ser parcial porque no tengo ese móvil. Tenemos productos Web, además de cliente-servidor, por supuesto. Hay programadores, ahora mismo, desarrollando nuevas aplicaciones Web. ¿Por qué habría de criticarlas entonces?
Lo que me molesta es el «cambio por el cambio». «Todo lo nuevo es mejor. Lo viejo está obsoleto». Puede pasar con los productos (el iPad2 es mejor que el iPad1, por supuesto), pero no siempre pasa con la tecnología.
¿Trabajas tú exclusivamente en clientes Web? Quizás tú si tengas una visión subjetiva de la situación.
Pues han hablado mucho de html5… pero la verdad es que no le llega ni a los talones a Adobe Flex….han crucificado a Flash.. y si Flex utiliza el plugin de flash, pero no tiene nada que ver con juegitos y animaciones.. Flex es para crear Aplicaciones RIA.. y en ese sentido Flex se aproxima muchisimo mas a la interaccion que tiene el usuario con la PC desde la Web a como lo haria en una aplicacion de escritorio…. y depende del sapo es la pedrada, si me piden una pagina web con acceso a datos, una tienda, etc, evidentemente no usare Flex, pero si es una aplicacion donde se requieren consultas en pantalla, listas, botones, validaciones, alta interactividad con el usuario y no fuera requerimiento que funcionara en tablets o moviles definitivo lo haria en Flex..
aqui les dejo una muestra:
Ola! bueno la verdad soy un novato aun en esto, soi estudiante de ingenieria en informatica este es mi primer semestre en la carrera y la verdad estoy complicado con un proyecto en el cual debo realizar un análisis para la puesta en marcha de un Sistema de gestión Inter sucursales.
Se trata de una minera ficticia la cual tiene 10 sucursales a lo largo del país la cual debe incorporar un software de gestión que sea capaz de mantener la informacion online.
La Problematica es que cada una de estas sucursales posee su propia contabilidad y servicios financieros de pago de proveedores, emisión de cheques, pago de personal y gestión administrativa en general.
en base a esto debo tomar la desición del tipo de foftware más adecuado, carta gantt del proyecto, flujo de trabajo en cada área de la organización, puesta en marcha de la aplicación y los meses que se destinarán a esta implementación. Sistema de respaldo de información, planes de contingencia adecuados para alta disponibilidad, análisis de redes y soporte de red adecuado para el proyecto, seguridad de acceso y los costos asociados al proyecto. El personal necesario y solicitudes a los proveedores claras y precisas, topolog{ias de red, la compra de dispositivos de conexión dimensionado al proyecto, tiempos de ejecución, etc…
porfavooor si alguien me puede ayudar o dar algun tipo de orientación lo agradeceria mucho.
Es una pregunta interesante, pero creo que te lo tienes que trabajar tú, si quieres aprender.
Como punto de partida sí te doy un consejo sencillo: la base de datos tiene que estar en un único sitio, en un servidor compartido para todos, así que ya sabes que tendrás que montar un sistema que permita el acceso remoto a los datos.
De todas formas dejo tu comentario por si algún lector del blog se anima a ayudarte.
Un saludo y ánimo.
Se que el tema es viejo.. perooooooooooooooo
yo creo que si estas limitado de $$$$, pues si tu opcion seria un servidor con la base de datos centralizada, pero con el riesgo de que algo pase y todas las filiales se queden sin acceso a su infirmacion…. si el $$$$$ no es problema, optaria porque cada Filial tuviera su propio servidor y replicara la informacion hcia un servidor central y estuviera ahi en caso de alguna contingencia..
Muy interesante tu blog gracias por el aporte a gente con sed de conocimiento.
que buenos artículos, muchas gracias. tu blog a mis bookmarks
[…] consigue con los “clientes pesados” desarrollados a medida (sobre esto hay mucho que hablar, y ya lo he hecho antes en este […]
Muy interesante, pero el que tiene la ultima palabra de como quiere su aplicacion o su pagina es el cliente no? las herramientas nos toca decidirlo nosotros.
Por supuesto, el cliente siempre manda. La tecnología es un «medio» no un «fin».
Pero, a diferencia de la mayoría de post de este blog, este va dirigido a desarrolladores, no a los clientes finales.
Un saludo.
Que es lo recomendable para una empresa de unos 25 usuarios, que deben cargar muchas imágenes y documentos al sistema, además de generar documentos e informes para clientes en línea. Los usuarios trabajan en un 80% en a oficina y un 20% en la calle. Somos peritos de seguros. Muchas gracias por vuestra ayuda, estamos evaluando si usamos servidor cliente o aplicación web.
Mi recomendación es usar una arquitectura mixta: cliente-servidor para los usuarios que utilizan muy frecuentemente el sistema y un cliente-web para los que trabajan en la calle.
En general, un programa «cliente» en los puestos de trabajo de los usuarios frecuentes debería ser más cómodo y ágil, imprescindible para que estos usuarios trabajen productivamente. El coste inicial de instalar el programa en cada puesto se amortiza en pocos días si el software está bien diseñado y facilita el trabajo.
Los «clientes-Web» suelen ser menos ágiles pero la ventaja de la movilidad es crucial para estos usuarios que no necesitan tanta facilidad de uso.
Personalmente recomiendo esta arquitectura «mixta» en muchas ocasiones. Vuestra empresa es un caso «de libro» de esta tipología.
Si necesitas ampliar la información, no dudes en contactar directamente conmigo en direccion@mtcsoft.es
He escrito bastante sobre arquitectura de sistemas en las últimas semanas (febrero-marzo). Si no lo has hecho ya, te vendría muy bien leer esos dos posts.
Es Segura?, una aplicación cliente-servidor, con servidor linux de acceso remoto a la base de datos.
La seguridad de que depende? He leido que es mas seguro una aplicacion de tres capas.
Flavio
En el momento en el que das acceso remoto (vía Internet) al servidor existe la posibilidad de que accedan terceras personas no autorizadas. Un servidor en Linux lo pondrá algo más difícil que uno en Windows (por que es menos «corriente») pero no supone una diferencia para hackers profesionales.
Lo importante es implementar correctamente las medidas de seguridad del software del servidor. Y, por otra parte, utilizar contraseñas robustas para el acceso de los usuarios de la aplicación.
Una medida de seguridad adicional es guardar los archivos en una base de datos (como Oracle) en lugar de como ficheros gestionados por el sistema operativo. Para un intruso que accede al servidor significa una nueva barrera que superar y mucho menos conocida que la de acceso al sistema operativo.
Estoy totalmente de acuerdo con la conclusion de que debe ser una aplicacion mixta. Hasta hace poco tenia implementado aplicaciones Cliente-Servidor en mis clientes. Ahora las emigre a Web. Esto le dio comodidad y la ventaja a los empleados viajantes que pudieran acceder a la informacion de la empresa desde cualquier lugar del pais y con cualquier dispositivo disponible que cuente con un simple navegador web y a aquellos que por alguna razon y en algun momento podian hacerlo desde su casa. Tambien permitio que se pueda seguir teniendo acceso a la informacion con dispositivos alternativos cuando la PC de escritorio quedara fuera de servicio por cuestiones tecnicas. Pero no resulto para nada bien recibido el cambio en aquellos sectores, como por ejemplo, los de mostrador, con trato directo y continuo con clientes y los de facturacion por las razones ya dadas en este articulo. Por lo tanto, me vi obligado a desarrollar clientes pesados en aquellos departamentos donde primaba la usabilidad y velocidad en la carga de datos.
Gracias por tu comentario. Me alegra mucho leerlo porque no es habitual oir esta historia. Muchos programadores dejan de mantener sus «clientes pesados» cuando pasan a clientes Web pero veo que tú sí «escuchas» a tus clientes.
Ya somos dos, al menos.
Hola soy una alumna de Ing. de Sistemas, actualmente me encuentro desarrollando el prototipo de mi Tesis, en la cual estoy proponiendo la aplicacion de la arquitectura cliente/servidor en la Gestion administrativa , quisiera saber que ventajas resaltantes me traeria utilizar esta tecnologia en vez de una aplicacion web..
saludos.
En este blog tienes varios posts sobre este tema, incluyendo este mismo en el que escribes el comentario. También te vendrá bien leer los comentarios, varios de ellos son de ingenieros de sistemas con experiencia.
Estimado Fernando, te cuento que hace varios años desarrollamos con un amigo un sistema de gestión de servicios de mecánica en visual basic .net basado en la arquitectura cliente/servidor. Cuando la empresa empezó a crecer a otras ciudades pensé en migrar a la arquitectura web, sin embargo siempre encontré trabas en el camino porque los procesos eran muy pesados y las herramientas en web eran muy distintas y el proyecto se estancó en cierta forma. Pero al leer tus artículos y en especial la comparación de ambas arquitecturas me di cuenta que no tengo necesidad de pasar todo a web, sino que ambas arquitecturas pueden co-existir y brindar a cada tipo de usuario (operadores, administrador y clientes) el mejor performance y tiempo de respuesta según las funciones que realizan.
Gracias por llevarnos a entender de forma práctica que el «usuario» es quien finalmente manda.
Soy un gran defensor de las arquitecturas «mixtas» (lo mejor de cada casa).
Me alegra que te haya resultado útil.
Buenas,
una pregunta …
si yo tengo un web hosting y una app Android que accede a este para recuperar datos, esto también estaría dentro de la arquitectura cliente/servidor?
Muchas Gracias de antemano!
Saludos.
La primera impresión es que no, no es cliente-servidor sino cliente-Web.
No habría ninguna duda si en lugar de acceder con una app utilizas el navegador. Entonces es cliente-web seguro.
Siendo un «cliente tipo app» resulta difícil clasificarlo. Si es una aplicación «pesada», estamos en cliente-servidor por el tipo de «cliente», que no es un cliente «ligero», un navegador.
Pero al ser acceso por internet podríamos clasificarlo como aplicación Web.
Como ves, el lenguaje no es preciso. Aunque quizás es innecesario darle tantas vueltas. Lo importante es que funcione.
Gracias Fernando, estoy totalmente de acuerdo contigo, lo importante es que funcione…el problema es que es para un proyecto final y claro…me piden taaaaantas cosas…
Gracias por la info.
Un saludo.
Muy interesante artículo.
Como desarrollador (.NET) me hace gracia ver por ejemplo en el Corte Inglés o tiendas parecidas cómo siguen usando aplicaciones tipo consola monocromo.
Trabajan a fuerza de tabulador y teclas de función y ¡van a toda leche! Siempre pienso que si les cambias eso añadiendo un ratón y mil ventanas de colores es seguro que te mandarán al carajo.
Como dices, no siempre lo nuevo es mejor.
(perdón por el offtopic)
Hello would you mind letting me know which web host you’re working with? I’ve loaded
your blog in 3 completely different internet browsers and I must say this blog loads a lot
quicker then most. Can you recommend a good hosting
provider at a reasonable price? Thank you, I appreciate it!
I’m using the WordPress infrastructure. It’s free and good. But it’s because my blog is a WordPress’ blog.
I use a hosting provider from Spain for my web pages. But it’s not a good choice is you don’t live in Spain.
1&1 is very popular.
Estimado Fernando, soy alumna de la Carrera Tecnologo en Informatica Biomedica y estoy realizando mi proyecto de titulo el tema es mejoramiento de tiempos de espera para atencion con especialistas y priorizacion en derivaciones esto se situa en un servicio de salud X como usted sabra mi proyecto involucra a muchos usuarios finales ademas de una plataforma para interconsultas, sistema informacion con modulos de ficha electronica agendamiento entre otros, el tema es que en mi profesion no se desarrolla el sistema sino que elaboramos la solucion por eso me cuesta un poco el tema y ahora que habia decidido optar por una aplicacion web para mi proyecto despues de leer su blog y los consiguientes comentarios quede en la duda de cual realmente escoger…necesito un consejo
gracias, saludos
Es difícil aconsejar sobre un proyecto sin tener una información detallada del mismo, pero sí hay algunas características que te pueden indicar qué solución elegir.
Antes de nada es importante saber que con frecuencia hay varias soluciones válidas posibles. No hay que pensar que solo una opción es válida. Simplemente alguna tiene unas ventajas, pero otra solución tendrá también sus ventajas. La decisión final no siempre es evidente ni única.
En tu caso, como en todos, una de las claves es el número de usuarios. Y siempre pensar en las dos partes de un proyecto: instalación y mantenimiento. Las soluciones con clientes Web son mucho más sencillas de instalar y mantener y si el número de usuarios es grande y las actualizaciones frecuentes suele ser la mejor opción. Por contra, los programas cliente-servidor suelen ser más potentes en cuanto a las posibilidades del usuario, a costa de un mayor tiempo de instalación y mantenimiento. Si el programa es sencillo, con pocas opciones, la solución Web es más adecuada. Si el número de usuarios no es muy grande y el software tiene muchas funciones o quieres que sea muy ágil en su manejo y con muchas ayudas al usuario, puede ser más adecuado un programa cliente-servidor.
En ambos casos con una base de datos en un servidor dentro de la red local, para garantizar un manejo rápido con todo tipo de documentos.
Espero haberte ayudado. Un saludo.
Hola Fernando,yo tengo una pregunta. Si en una arquitectura Cliente-Servidor, la Base de Datos está en un Servidor remoto, ¿como justificas entonces esa carga rapida de datos del cliente pesado??. Los datos no están viajando por una red local, sino por internet. Como evitarias tú esa supuesta ventaja que defendias en la tecnologia cliente/servidor??.Muchas Gracias.
En una arquitectura cliente-servidor los datos deben estar en un servidor local. El acceso remoto se limita a accesos desde fuera de la oficina.
En una instalación de este tipo, la mayor parte de los usuarios están conectados a través de la red local y solo algunos, o en algunos momentos, se conectan al servidor cuando están fuera, en cuyo caso tienen el problema de la velocidad de conexión.
Con un servidor en la «nube» SIEMPRE estás supeditado a tu velocidad de conexión a Internet. Si todos los usuarios están fuera de la oficina, si la movilidad es fundamental, es un precio que hay que pagar. Pero si la mayor parte de los usuarios están en la misma oficina, pon el servidor allí mismo y el acceso será mucho más rápido.
Luego está el tema de la interfaz de usuario, pero eso ya lo he comentado en el post.
Un saludo.
Hola Fernando te paso a visitar de nuevo y te agradezco tu respuesta pero todavia me queda una duda como ya te comente anteriormente termino mi tesis para defender mi titulo y en el proyecto que presentare las aplicaciones que los establecimientos de salud tenian ( RCE, Agendamiento) usaban arquitectura cliente/servidor por el hecho de que eran pocos usuarios pero lo que yo presento es una plataforma de interconsultas la que tendra aplicacion web por el hecho de que sera una aplicacion para toda la red asistencial que son 9 establecimientos, tu dijiste mas arriba que lo ideal era que se tuviera las dos arquitecturas en mi proyecto estaran las dos y yo se que estas pueden interoperar pero no entiendo como ??? por favor ayudame necesito entenderlo ademas es un tema que me interesa mucho ya que sera mi herramienta de trabajo en el futuro…desde ya agradecida, saludos
En la arquitectura cliente-servidor «clásica», hay un ordenador en la red local que actúa como servidor del resto. En este ordenador está instalada la base de datos a la que acceden todos los usuarios a través de la red. Los «clientes» instalan una aplicación Windows (aplicación de escritorio) y se conectan al servidor localmente. Es lo que se llama «clientes pesados» porque necesitan instalar un software específico.
Si los clientes utilizan simplemente un navegador, se llaman entonces clientes ligeros. Acceden al mismo servidor a través de la red local pero ADEMÁS pueden acceder desde el «exterior» a través de Internet.
Si conviven clientes pesados que acceden localmente y clientes ligeros que acceden localmente o desde el exterior, es una «arquitectura mixta», que es la más versátil y la que más me gusta.
Fíjate que el servidor es el mismo, los datos son los mismos, el Oracle que gestiona los datos es el mismo. Lo que cambia es la forma de acceder de los clientes.
Por último, si el servidor está fuera de la oficina, en un proveedor externo, se llama «en la nube». En este caso solo hay clientes ligeros y es una arquitectura web «pura».
Espero haberte resuelto tus dudas.
excelente blog, me gustaria proponer un tema nuevo creo que relacionado y es la de gpu computing.
Hola Fernando, creo que entre todos los planteamientos de arquitectura que se han hecho, y son muchos, no hay ninguno igual al que se nos presenta a nosotros, por lo que me animo a plantearlo:
Tenemos una serie de aplicaciones de escritorio que manejan una información GIS y otra serie de datos más o menos voluminosos. Esta aplicación se encuentra instalada en PC’s de una red local por lo que el acceso a la base de datos Postgis es muy rápido. Ahora se quiere que esas aplicaciones se ejecuten en “ordenadores remotos conectados en una VPN lenta (ADSL)”. Intentamos evitar tener que rediseñar esas aplicaciones como aplicaciones web (como aplicaciones cliente-servidor puras parece más complicado por lo lento que sería la carga de la información GIS inicial y su refresco en tiempo real, pues además la aplicación se define como un conjunto de módulos y cada uno maneja una serie de capas diferentes). Habíamos planteado lo siguiente:
• Modificar ligeramente las aplicaciones de escritorio de manera que tenga en cuenta, en algunos de los accesos a base de datos GIS, si la instalación es de “red local” o “remota”
• Implementar un SERVIDOR WEB para atender peticiones, mediante “servicios web”, sobre Base de Datos en servidor remoto.
• Con el arranque de la aplicación se determina, mediante web service, si necesita una actualización de versión
• Localmente se montaría una Réplica de la Base de Datos Postgis. Las operaciones pesadas, sobre todo a la hora de carga inicial de capas GIS, se harían desde la BD local.
• Todas las modificaciones que se hagan sobre B.D. por parte de los usuarios, se harán sobre la B.D. Remota, mediante web services
• Periódicamente, mediante un Proceso Paralelo al de ejecución de la aplicación de escritorio, se descargarían las capas con información en tiempo real. Sería necesario desarrollar un servicio que realizara esta operación.
• Con periodicidad diferente, una vez al día por ejemplo, se descargarían del servidor otra serie de capas más pesadas y cuya información es bastante estable.
¿Encuentras viable este planteamiento? Por mi parte pienso que el problema mayor es mantener la coherencia entre la BD del servidor y las instaladas en los clientes remotos.
A falta de un estudio detallado parece viable. Pero, y ya lo has comentado tú, la clave es la coherencia.
Los gestores de bases de datos «serios» como Oracle o SQL Server (y muchos otros) resuelven este problema con la gestión de las transacciones. Es un problema técnico complejo que está resuelto y los programadores no tienen que preocuparse de él.
Otra cosa es lo que planteas, que vosotros gestionéis esa «coherencia». Es complicado.
Haz un ejercicio importante. Seguramente ya lo has hecho: ponte en lo peor. Un usuario cambia un dato de un fichero o documento en una ubicación y otro usuario cambia otro dato del mismo fichero en otra. ¿Lo tienes resuelto? ¿Bloqueas el fichero/documento mientras alguien lo esté editando?
Hay varias situaciones complicadas que tratar. Tendrás que renunciar a algo: o a la velocidad, o al acceso concurrente… Y mantener informado a los usuarios que sufran un bloqueo, o que están viendo información desactualizada.
No parece fácil.
Un saludo.
Muchas gracias por tu respuesta. Tienes toda la razón en que no se puede migrar de una configuración a otra de forma inmediata.
Aunque creo que el problema del acceso concurrente se podría resolver en la mayoría de los casos agrupando las operaciones en el servidor. Por ejemplo, el cliente quiere insertar un registro “B” en base de datos que depende del estado de otra información “A” de esa base de datos: En vez de que el cliente compruebe previamente el estado de A y decida si insertar B, se definiría una operación básica que sea “insertar registro B en función de A”, asociada a un servicio web o a un procedimiento almacenado en B. de Datos.
En el ejemplo de acceso a ficheros que comentas se podría pensar en sólo permitir operaciones sobre servidor y que implicaran operaciones globales de lectura o escritura, sin más comprobación que la de sobreescritura en caso de que exista el fichero en destino.
Está claro que habrá que modificar la aplicación de escritorio actual, pero seguramente los cambios sean mucho menores que lo que implicaría “rediseñar” todo el interfaz de usuario para una nueva aplicación tipo web. A no ser que hubiera alguna otra solución.
Muchas gracias de nuevo y un saludo.
Buenas tardes Fernando, aun andas por aquí? Espero te encuentres excelente. Disculpa, un favor necesito de tu valiosa opinión. Hace algunos años desarrollé un sistema cliente/servidor de punto de venta, éste funciona en red local. Últimamente mis clientes se han visto en la necesidad de abrir mas sucursales, por lo que desean acceder a la información desde cualquier sucursal. He pensado en tres opciones: 1. Usar vpn 2. Tener una base de datos remota, en un hosting de pago, y acceder via webservices 3.Rediseñar todo mi sistema, pasándolo a web. cual crees que sea la mejor opción? o alguna otra sugerencia? gracias!
Hola Carlos. Aquí sigo. Espero que 30 años más.
Tu problema es muy corriente y admite varias soluciones. Esto es una ventaja, porque puedes elegir la que se adapte mejor, pero un inconveniente porque «tienes que elegir».
Cada una tiene sus ventajas e inconvenientes y puede ser más adecuada en función del gestor de base de datos que estés usando, de la velocidad de conexión, de la frecuencia con la que se conectan y de lo difícil que te resultaría reescribir el código en otra arquitectura.
A las opciones que planteas le puedes añadir al menos dos.
1.- Tener la base de datos en un servidor «master» y acceder desde las otras ubicaciones con la dirección IP de la base de datos.
2.- Trabajar off-line y sincronizar las bases de datos por la noche, por ejemplo. Esto solo si los cambios no son muy frecuentes.
Personalmente me gusta bastante la opción 1. Con Oracle, por ejemplo, puedes acceder a la base de datos «central» o «master» simplemente instalándola en un servidor con direccion IP fija y la configuración adecuada.
Puedes tener el servidor en local o en la nube. Me gusta más en local porque los usuarios de esa oficina trabajarán con más fluidez, sin retraso en el acceso.
En fin, hay muchas opciones y esta que te planteo tiene la ventaja de que no tienes que reprogramar código aunque necesitas una conexión rápida.
Pasarte a la nube y a entorno Web es muy radical. La dejaría como último recurso.
Un saludo.
Gracias por tu ayuda y rápida respuesta. Ok, en base a lo que comentas y a todos los comentarios anteriores, convertir la aplicación cliente/servidor a aplicación web queda descartado. Me gusta la sugerencia del punto 1: «Tener la base de datos en un servidor “master” y acceder desde las otras ubicaciones con la dirección IP de la base de datos.». Para esto contrataré un hosting en donde alojaré la base de datos, usaré la modalidad mixta, seguir usando la aplicación de escritorio de manera local que realice los procesos fuertes y diseñar una aplicación web básica para consulta de información. Lo que me causa inquietud es la comunicación entre la aplicación cliente/servidor con la base de datos, ya que lo ideal es que esté local, tienes alguna sugerencia sobre ello? gracias
No es fácil comentar los detalles y tampoco tengo práctica como para contártelo en pocas palabras.
Pero es una técnica sencilla y muy probada. No debes tener problemas para encontrar información.
En Oracle, por ejemplo, solo hay que cambiar la configuración de conexión en el cliente indicando que el servidor, en vez de estar en la red local, es accesible en una conexión IP.
Siento no poder ayudarte más porque, aunque conozco la técnica y la he usado, no lo hago con frecuencia y no tengo soltura.
Perfecto, con lo que me has escrito es mas que suficiente para iniciar el reto, te agradezco tu tiempo, y tus sugerencias, gracias, un saludo!
Fernando, que opinion tienes acerca de Terminal server? hoy leí algo al respecto, y se perfila como una opción más para el reto que te planteo del uso de una sola base de datos y que se tenga acceso desde varias sucursales con aplicación cliente- servidor
Uso terminal server a diario con muy buenos resultados, pero en red local. Sé que hay buenas experiencias usándolo también con ordenadores remotos pero depende de la velocidad de conexión.
Como hacer una prueba es muy sencillo y no tienes que cambiar código, sin duda deberías intentarlo y evaluarlo en tu caso concreto. Si te sirve, ya tienes resuelto el problema, sin apenas coste.
Hay otras opciones similares usando programas de acceso remoto como TeamViewer, pero algunos son bastante caros.
Bien, seguiré con las pruebas que tengas buen día! gracias!
Bien, seguiré con las pruebas, que tengas buen día, gracias!
Solo para puntualizar, un sistema cliente-servidor usualmente es una solución compilada, versus una solución interpretada en el caso de la aplicación web. Sobra decir que los tiempos de respuesta son abismales, aún incluso en clientes remotos accediendo a servidores remotos mediante sockets.
[…] se comenta en artículos como estos La Web esta muerta vida Intenet , Cliente-servidor vs Aplicaciones Web , Aplicaciones Web vs Aplciaciones de escritorio y muchos más qeu puedes […]
A propósito de tu articulo, te referí en : https://wordpress.com/post/mpoliver.wordpress.com/3808 , sobre esta problemática