Arquitectura de aplicación de gestión

[chan]

Tengo que diseñar un nuevo sistema de información, y la cosa es que tras muchos años de hacer desarrollos con arquitecturas web y desktop, me estoy planteando seriamente hacer una arquitectura híbrida ... a ver qué opináis.

La idea es tener la base de datos alojada en un host, mientras que la aplicación se ejecuta en cliente. Tengo dos opciones para exponer los datos:


1. Mediante acceso directo, abriendo el puerto de la base de datos y usando autenticación. Toda la responsabilidad de l acceso a los datos recaería sobre la app desktop.
2. Exponiendo un servicio web con autenticación que sea el que me provea de una fachada para el acceso a datos. Con un formato de intercambio en JSon, por ejemplo.


Evidentemente la opción 2 me parece algo mejor que la primera, además de este modo mataría 2 pájaros de un tiro: tendría una fachada de acceso a datos preparada para cualquier tipo de cliente, desktop, web o dispositivo móvil. Creo que tiene algo más de curro, pero me da la sensación que a nivel de seguridad también es algo mejor que la 1 opción.

¿Qué os parecen estas alternativas de solución?, ¿habéis hecho algo así obteniendo buenos resultados?

[bnl]

Habria que conocer el escenario completo: caracterisiticas de la aplicacion, numero de usuarios, ¿se necesita un cliente pesado? ¿se usaria en una intranet?  tipo de usuarios (de una organizacion o abierto a cualquiera)

¿la aplicacion se actualizara? En tal caso tendras que distribuir el cliente entre los usuarios. Si es una app web eso te lo ahorras

En principio yo dejaria en el servidor el acceso a datos y la logica de negocio.

[chan]

Es una aplicación que probablemente siga la filosofía de uso de licencia "per seat" o "per user" o algún híbrido entre los dos. Al ser un producto, me interesa poder lanzar versiones con mejoras y nuevas funcionalidades, que tendrían un nuevo licenciamiento o un upgrade.

Por eso me interesa bastante que la lógica de la aplicación se quede en el cliente.

Tampoco quiero limitar la visibilidad de los datos dentro de una empresa, es decir, no quiero que por el hecho de tener instalado un cliente en la oficina A en Sevilla, la persona de la oficina B de Cuenca no pueda ver la información actualizada. Los datos deben estar centralizados (ya sea con actualización en tiempo real o con posteos de sincronización, que por cierto nunca me han gustado mucho)

[XÑA]

Yo trabajo con un sistema hibrido. Tengo bases de datos SQL Server en hoteles que replican, algunas BBDD en una dirección y otras en ambas direcciones. Esto creo que ya no lo hace nadie, pero en mi caso necesito que cada hotel sea independiente, no podemos permitirnos que se 'rompan' las coms ( y eso todavía pasa!). Si está bien montado es muy óptimo, porqué te permite que cada servidor de cada hotel dé servicio a los clientes de ese hotel, y te aseguro que la velocidad es importante!! Pero bueno, el sistema se creó hace 10 años, y quizás ahora, si hubiera una buena inversión, lo cambiaría a centralizado, principalmente por el problema que me supone el mantenimiento de tantos SQL Server!!!  :-\

Tengo un problema cuando cambio la versión de la aplicación, que tengo que subirla a todos los hoteles. Eso es pesado, aunque también tengo un problema cuando cambio las funciones en .Net de SQL Server, que tengo que parar a todo el mundo durante el tiempo del despliegue.

Yo, lo que más valoro, es que sea fácil de mantener. Eso para mi es lo primordial, mucho más que la velocidad, porqué la velocidad aumenta cada año sin tener que hacer tu nada!!

[chan]

Interesante...

En mi caso yo no sería responsable del mantenimiento, es decir, el modelo de negocio está orientado a venta de productos. Los clientes comprarán la version 1.0 y opcionalmente podrán upgradear a la 2.0 con un precio más económico que los nuevos clientes. Pensad en un photoshop con daros en la nube y control de licencias remoto... esa sería la filosofía.