Cómo prestación de servicios OSGi por cliente

Question

Estamos desarrollando una aplicación Web (llamémosle un banco de imágenes) para los que se han identificado las siguientes necesidades:

• La aplicación atiende a los clientes que se componen de un conjunto de usuarios.
• un nuevo cliente se pueden crear de forma dinámica y un cliente gestiona sus usuarios
• Los clientes tienen diferentes conjuntos de características que se pueden cambiar dinámicamente
• clientes pueden desarrollar sus propias características y hacer que se despliegan.
• La aplicación es homogénea y tiene una versión actual, pero el levantamiento de versión de los clientes aún se puede manejar de forma individual.
• La aplicación debe administrarse como un todo y los clientes comparten los recursos que deberían ser fáciles de escalar.

Pregunta: debemos construir esto en un marco de OSGi estándar o habría que ser mejor de utilizar uno de los marcos de aplicaciones emergentes (Virgo, Aries o próxima estándar OSGi)?

Más de fondo y algunas ideas iniciales:

Estamos construyendo una aplicación web que imaginar que pronto tendrá cientos de clientes (empresas) con cientos de usuarios cada uno (empleados), de lo contrario ¿por qué preocuparse;). Queremos que sea modular, por lo tanto, OSGi. En el futuro, los propios clientes podrían desarrollar y agregar componentes a su aplicación, por lo que necesitamos aislamiento del cliente. También es posible que deseemos que diferentes clientes obtengan diferentes conjuntos de características.

¿Cuál es la forma "correcta" de proporcionar diferentes implementaciones de servicios a diferentes clientes de una aplicación cuando diferentes clientes comparten los mismos paquetes?

Podríamos utilizar el enfoque de servidor de aplicaciones (hemos estudiado a Virgo) y cargar cada paquete una vez para cada cliente en su propia "aplicación". Sin embargo, no se siente como abrazar OSGi. No estamos organizando una multitud de aplicaciones, el 99% de los servicios compartirán la misma impl. para todos los clientes. También queremos administrar (configurar, monitorear, etc.) la aplicación como una sola.

Cada servicio se puede registrar (configurar correctamente) una vez para cada cliente junto con alguna propiedad de "ficha de cliente". ¿Es un poco desordenado y debería manejarse con un patrón extensible o quizás una ManagedServiceFactory? Además, antes de registrar un servicio para el cliente A, deberá adquirir la versión A de cada una de sus dependencias.

El cliente "actual" será conocido por cada solicitud y puede vincularse al hilo. Es un poco complicado tener que proporcionar un token de cliente cada vez que busca un servicio. Hace que sea difícil usar marcos de componentes como blueprint. Para evitar el problema, podríamos usar los ganchos de servicio para representar por proxy cada tipo de servicio registrado y permitir que el proxy se envíe a la instancia correcta de acuerdo con el cliente actual (thread).

Comenzar toda nuestra experiencia OSGi mediante la implementación de la solución provisional (¿hack?) De arriba realmente parece una indicación de que estamos en el camino equivocado. ¿Entonces, qué debemos hacer? ¿Volver a Virgo? Intente algo similar a lo que se describe arriba? ¿Algo completamente diferente?

ps. ¡Gracias por leer todo el camino hasta aquí!;)

Answer 1

Hay un par de aspectos a una solución:

En primer lugar, es necesario encontrar una manera de configurar los diferentes clientes que tiene. Crear una solución sobre ConfigurationAdmin tiene sentido aquí, porque entonces puede aprovechar el estándar OSGi existente tanto como sea posible. La razón por la que desea construir algo en la parte superior es que ConfigurationAdmin le permite configurar cada servicio individual, pero es posible que desee agregar una capa en la parte superior para que pueda configurar de manera más conveniente toda su aplicación (el conjunto de paquetes) de una sola vez. Dicha configuración se puede traducir a las configuraciones individuales de los servicios.

Agregar una propiedad a los servicios que tienen implementaciones específicas del cliente tiene mucho sentido. Puede configurarlos usando ManagedServiceFactory, y la propiedad facilita la búsqueda del servicio para el cliente correcto utilizando un filtro. Incluso puede definir un escenario alternativo donde busque un servicio específico del cliente o uno genérico (porque no todos los servicios serán probablemente específicos del cliente). Dado que necesita agregar explícitamente dichos filtros a sus dependencias, le recomendaría tomar una solución de administración de dependencias existente y ampliarla para su caso de uso específico para que las dependencias agreguen automáticamente los filtros específicos del cliente adecuados sin tener que especificar eso a mano. Me doy cuenta de que podría tener que entrar en más detalles aquí, házmelo saber ...

La siguiente pregunta es cómo hacer un seguimiento del "contexto" del cliente dentro de su aplicación. Tradicionalmente, hay solo unas pocas opciones aquí, con un contexto local de subprocesos como el más utilizado. Sin embargo, enlazar hilos a clientes tiende a limitarte en términos de opciones de implementación, ya que en general probablemente signifique que debes prohibir a los desarrolladores crear subprocesos ellos mismos, y es difícil descargar ciertas tareas a grupos de subprocesos de trabajo. Se pone aún peor si alguna vez decide usar los Servicios remotos, ya que eso significa que perderá completamente el contexto.

lo tanto, para la transmisión de la identificación del cliente de un componente a otro, yo personalmente prefiero una solución donde:

1. Tan pronto como entra la petición (por ejemplo, en el servlet HTTP) determinar de alguna manera el cliente CARNÉ DE IDENTIDAD.
2. Transfiera explícitamente ese ID a la cadena de dependencias del servicio.
3. Solo use soluciones como el uso de localizaciones de subprocesos dentro de los límites de un paquete único, si, por ejemplo, está utilizando una biblioteca de terceros dentro de su paquete que necesita esto para realizar un seguimiento del cliente.

Answer 2

He estado pensando en este mismo tema (creo) desde hace un tiempo y me gustaría tener sus opiniones sobre la siguiente analogía.

Considere una serie de aplicaciones web donde proporciona control de acceso utilizando una infraestructura de inicio de sesión único (SSO). El usuario se autentica una vez con el servidor SSO y, cuando aparece una solicitud, la aplicación web de destino le pregunta al servidor SSO si el usuario está (todavía) autenticado y se determina a sí mismo si el usuario está autorizado. La información de autorización también puede ser proporcionada por el servidor SSO también.

Ahora piense en sus paquetes de aplicaciones como miniaplicaciones. Aunque no son aplicaciones web, ¿no tendría sentido tener algún tipo de paquete de SSO utilizando técnicas de SSO para realizar la autenticación y proporcionar información de autorización? Cada paquete de aplicaciones debería desarrollarse o configurarse para usar el paquete de SSO para validar la autenticación (token de SSO) y validar la autorización preguntando al paquete de SSO si el usuario tiene permiso para acceder a este paquete de aplicaciones.

El paquete de SSO mantiene algún tipo de repositorio de sesión y también proporciona propiedades de usuario, p. información para identificar el repositorio de datos (de algún tipo) de este usuario. De esta forma tampoco pasará a través de un "token de servicio al cliente" (significativo), sino más bien un SSO token críptico suministrado y administrado por el paquete de SSO.

Answer 3

Tenga en cuenta que Virgo es un contenedor OSGi basado en Equinox, por lo que si no desea utilizar alguna característica específica de Virgo, no es necesario. Sin embargo, obtendrá muchos benefits si usa Virgo, incluso para una aplicación OSGi básica. Sin embargo, suena como si quisiera soporte web, que viene de la caja con el servidor web de Virgo y le ahorrará la molestia de armarlo usted mismo.

Descripción completa: Yo dirijo el proyecto Virgo.