Arquitectura y Tecnología
Requisitos y Prioridades de Diseño
hipergate está diseñado desde el principio como una suite orientada a dar un servicio de alta calidad a los clientes más exigentes.
Ergonomía y Usabilidad
La primera prioridad del producto es que cada parte proporcione una buena experiencia de usuario.
Esto se consigue mediante:
• arquitectura de información homogénea a través de todos los módulos.
• modelo conceptual fácil de entender.
• fácil acceso a todas las funcionalidades.
• tiempos de respuesta rápidos para todas las operaciones.
• completitud en la gama de operaciones disponibles.
Alcance Funcional
La suite está pensada para cubrir el 80% de las necesidades más típicas de cada módulo funcional.
En este apartado se prefirió la expansión horizontal del producto por múltiples módulos antes que
fabricar unas pocas aplicaciones específicas de alta complejidad.
La filosofía del producto es que las empresas pequeños y medianas obtengan prácticamente todas las
funcionalidades necesarias para cada departamento y que las grandes dispongan de una base sólida
para desarrollar extensiones propietarias.
Estabilidad
La suite es un producto pensado para tener disponibilidad 24x7. Cada nuevo módulo es meticulosamente testeado en sucesivos walkthroughts de código, pruebas de caja negra y pruebas de stress en condiciones críticas.
Escalabilidad
Durante todo el ciclo de desarrollo no se quiso sacrificar en ningún momento el rendimiento por la transportabilidad o la ampliación funcional del producto. El código está optimizado para hacer uso de las funcionalidades específicas de cada base de datos y plataforma sobre los que puede ejecutarse.
Una parte de la lógica de proceso emplea procedimientos almacenados PL/SQL, PL/pgSQL o Transact-SQL reescritos manualmente para aprovechar al máximo las opciones más avanzadas de cada SGBDR.
El código Java dispone de 3 modos de ejecución: 100% Java Puro, Linux y Windows, y, según se configure explota las llamadas atómicas de cada sistema operativo para obtener el mejor rendimiento.
La aplicación está diseñada en 3 capas: servidor web, servidor de aplicación y servidor de base de datos. El diseño hace énfasis en la capacidad para crear granjas y repartir la carga entre múltiples servidores.
Para reducir el consumo de memoria y aumentar la capacidad de servicio de cada servidor web, la aplicación funciona sin sesiones ni estados mantenidos en el lado servidor.
La suite incorpora un sofisticado sistema propietario de cache distribuido con la misión de mantener información local en los servidores web y reducir la sobrecarga de los nodos de la base de datos.
Tolerancia a Fallos
La aplicación puede configurarse para funcionar en clustering tanto con los servidores web como con la base de datos.
Mantenibilidad
La estructura del código se está diseñda pensando en que resultase sencillo de mantener y de ampliar por programadores sin conocimientos profundos de los detalles del sistema. El modelo de objetos que aísla el modelo físico de la base de datos del modelo de la lógica de negocio proporciona un marco natural para hacer ampliaciones con una curva de aprendizaje suave. Muchas de las tareas rutinarias de codificación: generación de formularios, tablas de remonte, validación de datos, gestión de fechas, etc. ya están resueltas de forma estándar en componentes reutilizables.
Separación de datos entre clientes
hipergate comparte información de varios clientes en una misma base de datos para evitar una proliferación insostenible de bases de datos. No obstante, como requisito imprescindible para poder dar servicio SaaS, la información de cada cliente puede extraerse limpiamente en cualquier momento de la base de datos compartida para hacer una copia de respaldo exclusiva del cliente o para instalarse en una instancia de base de datos dedicada.
Economía
La aplicación puede funcionar basada 100% en Software Libre con el propósito de eliminar casi por completo los costes de licencias.
Otro factor, es el uso racional de la CPU y el disco que se consideran recursos escasos.
Tecnología Estándar
Sólo se emplean componentes y tecnologías de uso muy común en el mercado. Además se aboga por el uso exclusivo de plataformas con respaldo explícito para su continuidad de las grandes empresas del sector.
A pesar de su amplio alcance técnico y funcional, la suite está diseñada y codificada para ser muy simple parte por parte.
Lenguajes, Componentes y Plataformas Utilizados
Java y Tomcat: Todos los módulos de hipergate están escritos en 100% Java Puro. El software puede correr en cualquier versión de la máquina virtual desde la 1.5 en adelante.
S.O.: La máquina que aloja el servidor web puede ser Linux, BSD, Solaris, AIX o Windows.
SGBDR: hipergate puede ejecutarse sobre MySQL, PostgreSQL, Oracle o SQL Server.
Estructura Interna Multi-Capa
El código de hipergate está dividido en 5 capas:
 |
 |
|
- Realizar el máximo de validaciones y procesamiento en cliente para reducir el tráfico entre el navegador y el servidor web.
- Separar la capa de presentación de la persistencia de objetos.
- Proporcionar un API para todos los objetos de la aplicación.
- Utilizar el máximo de código compilado y optimizado para el núcleo de librerías del sistema.
- Externalizar la lógica de negocio en scripts de servidor que no requieran ser recompilados para ejecutarse.
- Reducir el número de llamadas a la base de datos en aquellas operaciones que puedan ejecutarse de forma atómica dentro del gestor de base de datos.
Servidor sin estados
hipergate no utiliza sesisones ni estados mantenidos en el servidor.
Esto es una medida destinada a reducir el consumo de memoria y aumentar la escalabilidad en el servidor web.
Toda la información de sesión se mantiene mediante cookies almacenadas en el cliente.
Caches distribuidos
El sistema utiliza un cache distribuido que permite almacenar información de la base de datos de forma local en los servidores web. Esto reduce el tráfico de red y aligera la carga sobre la base de datos.
Un controlador de cache se encarga de mantener la coherencia de los datos en instalación con múltiples servidores web funcionando de forma concurrente contra la misma base de datos.
Separación de datos por clientes y departamentos
Muchas aplicaciones que funcionan en modalidad SaaS lo hacen replicando automáticamente un modelo de datos para cada una de las instancias cliente. La ventaja de este enfoque es que permite separar fácil y limpiamente los datos de cada cliente El inconveniente es que se genera una proliferación de bases de datos clónicas prácticamente imposibles de mantener a partir de cierto volumen de instancias.
En hipergate se ha seguido una aproximación híbrida al problema de la separación de datos: una única base de datos puede contener información de múltiples entidades cliente sin solapamientos, incluso, yendo un paso más lejos, la división de datos y permisos de acceso puede llegar a nivel departamental, consiguiendo que las personas de un departamento tengan acceso a un conjunto de datos y aplicaciones diferente de los de otro departamento.
Sin embargo, para mantener el requisito indispensable de la separación de datos por cliente, las utilidades de administración disponen de subrutinas para cortar y separar la información de un cliente en una base de datos aislada de uso exclusivo, incluso aunque dicha información se encontrase previamente almacenada en una base de datos compartida.
Dominios: Conceptualmente, el Dominio de hipergate es la unidad de mayor nivel de división de datos. Típicamente representa una entidad cliente completa, aunque otro uso común es usarlo como contenedor de usuarios individuales no adscritos a ninguna entidad (por ejemplo, profesionales independientes que contratan una cuenta de uso personal).
Áreas de Trabajo: Cada Dominio puede contener una o más Áreas de Trabajo. Las áreas de trabajo forman los compartimentos estancos de información. Las áreas de trabajo suelen representar departamentos funcionales en las entidades cliente. En un momento dado cada usuario sólo ve la información de aquella área de trabajo a la que está conectado con un rol determinado. Por ejemplo, un vendedor podría ser usuario del área de trabajo del departamento de ventas, y, al mismo tiempo invitado del área de trabajo del departamento de soporte técnico. Este vendedor podría crear nuevas fichas de clientes o generar oportunidades comerciales en el área de trabajo de ventas, pero su nivel de privilegio en el área de trabajo de soporte sólo le permitiría ver las incidencias abiertas pendientes de resolución, sin posibilidad de modificarlas.
Modelo de Seguridad
hipergate implementa un modelo de seguridad a nivel de sesión basado en roles. El modelo maneja los siguientes conceptos:
| Aplicación |
El producto funciona como un conjunto de aplicaciones interoperables. Se pueden añadir o quitar aplicaciones sin afectar al funcionamiento del resto del sistema. En un momento dado, cada usuario tiene disponible un subconjunto de todas las aplicaciones y ejerce un rol en cada una de ellas en función de los grupos de permisos a los que pertenezca. |
| Usuario |
Se permite crear un número ilimitado de usuarios cada uno con su propio conjunto de roles y clave de acceso. |
| Rol |
Se dispone de cuatro roles predefinidos más un quinto definible por entidad cliente: administrador, superusuario, usuario, invitado y variable. Estos roles marcan lo que el usuario puede hacer en cada aplicación. Así, un usuario podría tener rol de Administrador en el módulo del Directorio de Personal y Rol de Invitado en el módulo de ventas. Esto le permitiría crear nuevas fichas de empleados, pero no crear nuevos clientes. |
| Cuenta |
Una cuenta es lo mismo que un contrato de uso con un cliente final. Existen 3 tipos de cuenta predefinidas: la cuenta corporativa, la cuenta profesional y la cuenta de sistema. Las cuentas corporativas permiten un número arbitrario de usuarios y están asociadas a su propio dominio. Las cuentas profesionales representan usuarios individuales que no pueden hacer uso de las funcionalidades de trabajo en equipo de la aplicación. Las cuentas del sistema se usan por los operadores del ISP que proporcionan el servicio como un medio de administrar todos los dominios contratados con clientes. |
| Dominio |
Un dominio representa un conjunto de usuarios que se administran de forma independiente. Cada dominio tiene uno o más administradores. |
| Área de Trabajo |
Cada dominio contiene una o varias áreas de trabajo. El área de trabajo es una entidad que sirve para establecer la visibilidad de conjuntos de datos en la aplicación. Por ejemplo, supongamos que la entidad cliente es una empresa con dos delegaciones, una en Madrid y otra en Barcelona. Se desea que la creación y gestión de usuario esté centralizada en Barcelona y que los usuarios de cada sede vean sólo la agenda y el directorio de su localidad. En este caso se crearía un dominio para la empresa y un área de trabajo para cada delegación. |
| Grupo |
Cada usuario pertenece a uno a más grupos. Es posible definir un número arbitrario de grupos. Los grupos en si mismos no otorgan roles a los usuarios. Es preciso asignar un rol al grupo dentro de una aplicación y área de trabajo para que los usuario adquieran el rol deseado. |
Diagrama ilustrativo del modelo de seguridad