java - ¿OSGi puede ayudar a reducir la complejidad?
design complexity-theory (6)
Vi muchas presentaciones sobre OSGi y creo que suena prometedor para imponer una mejor modularización. Aparentemente, "hotdeployment" y "ejecutar diferentes versiones de x en paralelo" también son puntos de venta importantes.
Me pregunto si lo que OSGi promete resolver es incluso un problema ... Me recordó los primeros días de OO cuando demandas similares eran de limpieza:
Cuando OO era nuevo, el gran argumento era la reutilización. Se afirmó ampliamente que al usar OO, uno solo tendría que "escribir una vez" y luego podría "usar en todas partes".
En la práctica, solo vi esto funcionando para algunos ejemplos de niveles bastante bajos. Creo que la razón para esto es que escribir código reutilizable es difícil. No técnicamente, pero desde el punto de vista del diseño de la interfaz. Tienes que anticipar cómo los futuros clientes querrán usar tus clases y tomar las decisiones correctas por adelantado. Esto es difícil por definición y, por lo tanto, el posible beneficio de reutilización a menudo no se cumple.
Con OSGi , tengo la sospecha de que una vez más podríamos caer en promesas, soluciones potenciales para problemas que realmente no tenemos. O si los tenemos, no los tenemos en una cantidad y severidad lo suficientemente grandes como para comprar OSGi en busca de ayuda. El "despliegue rápido", por ejemplo, de un subconjunto de módulos es definitivamente una gran idea, pero ¿con qué frecuencia realmente funciona? ¿Con qué frecuencia no porque resultó que la modularización fue incorrecta para un problema en particular? ¿Qué hay de las entidades modelo que se comparten entre múltiples módulos? ¿Todos estos módulos tienen que cambiarse al mismo tiempo? ¿O aplana sus objetos a primitivos y usa solo aquellos en comunicación entre módulos, para poder mantener los contratos de interfaz?
El problema más difícil al aplicar OSGi es, supongo, que la modularización sea "correcta" . Al igual que con las interfaces de sus clases directamente en OO, con OSGi, el problema sigue siendo el mismo, en una escala mayor esta vez, el paquete o incluso el nivel de servicio.
Como habrás adivinado, actualmente estoy tratando de evaluar OSGi para su uso en un proyecto. El principal problema que tenemos es el aumento de la complejidad a medida que crece la base de código y me gustaría dividir el sistema en módulos más pequeños que tienen interacciones cada vez menos definidas.
- Dado que ningún marco puede ayudar a decidir qué modularizar, ¿OSGi le ha pagado alguna vez?
- ¿Te ha hecho la vida más fácil cuando trabajas en equipo?
- ¿Ha ayudado a reducir el conteo de errores?
- ¿Alguna vez has implementado "componentes calientes" con éxito?
- ¿OSGi ayuda a reducir la complejidad a lo largo del tiempo?
- OSGi cumplió sus promesas?
- ¿Cumplió con tus expectativas?
¡Gracias!
Estoy usando OSGI desde hace más de 8 años, y cada vez que buceo en un proyecto que no es de OSGI me da la sensación de que se está excediendo sin cinturón de seguridad. OSGI hace que la instalación y la implementación del proyecto sean más difíciles, y le obliga a pensar en la modularización por adelantado, pero le ofrece la facilidad de aplicar las reglas en tiempo de ejecución. Tome maven apache camel como ejemplo. Cuando crea un nuevo proyecto maven y agrega apache camel como una dependencia, las aplicaciones parecen tener todas sus dependencias, y solo notará las ClassNotFoundExceptions en el tiempo de ejecución, lo cual es malo. Cuando se ejecuta en un contenedor OSGI y carga los módulos apache camel, los módulos con dependencias no satisfechas no se inician, y usted sabe por adelantado cuál es el problema.
También utilizo el despliegue en caliente todo el tiempo y actualizo partes de mi aplicación sobre la marcha sin la necesidad de reiniciar.
He trabajado con OSGi durante algunos años (aunque en el contexto de un proyecto de eclipse, no en un proyecto web). Está claro que el marco no te libera de pensar cómo modularizar. Pero te permite definir las reglas.
Si utiliza paquetes y define (en un documento de diseño? Verbal?) Que ciertos paquetes pueden no tener acceso a clases en otros paquetes, sin una aplicación de esta restricción, se romperá. Si contratas nuevos desarrolladores, no conocen las reglas. Ellos romperán las reglas. Con OSGi puedes definir las reglas en código. Para nosotros, esto fue una gran victoria, ya que nos ha ayudado a mantener la arquitectura de nuestro sistema.
OSGi no reduce la complejidad. Pero definitivamente ayuda a manejarlo.
No, OSGI te hará gris temprano.
OSGi NO paga. El hecho es que OSGi no es fácil de usar y al final del día o del año, dependiendo de cuánto tiempo tarde en hacer que las cosas funcionen, no agrega valor:
- Su aplicación no será más modular en general, por el contrario, termina siendo más expuesta y no aislada de otras aplicaciones, ya que es un recurso compartido en lugar de compartir nada.
- El control de versiones se empuja más abajo en la pila, luchas con las dependencias transitivas maven solo para volver a hacer eso en tiempo de ejecución en OSGI.
- La mayoría de las bibliotecas están diseñadas para funcionar como bibliotecas en el cargador de clases de la aplicación, no como paquetes con su propio cargador de clases.
- Tal vez sea apropiado para las arquitecturas de plugins donde los desarrolladores de terceros necesitan ser sandbox o tal vez solo sea EJB2.0 de nuevo.
Agregué las siguientes diapositivas y haré un seguimiento con un código de ejemplo para demostrar cómo trabajar con éxito con OSGi si se lo impiden. http://www.slideshare.net/ielian/tdd-on-osgi
OSGi vale la pena porque impone la modularización en el tiempo de ejecución, algo que antes no tenía, lo que a menudo causa que el diseño en papel y la implementación se separen. Esto puede ser una gran ganancia durante el desarrollo.
Definitivamente ayuda a que sea más fácil trabajar en equipo, si permite que los equipos se centren en un único módulo (posiblemente un conjunto de paquetes) y si obtiene la modularización correcta. Se podría argumentar que uno puede hacer lo mismo con una herramienta de compilación como Ant + Ivy o Maven y dependencias, la granularidad de las dependencias que utiliza OSGi es en mi opinión muy superior, sin causar el típico "arrastre en todo, más el fregadero de la cocina" que las dependencias de nivel JAR causan.
El código modular con menos dependencias tiende a conducir a un código más limpio y menos, lo que a su vez genera menos errores que son más fáciles de probar y resolver. También promueve el diseño de componentes lo más simple y sencillo posible, al tiempo que tiene la opción de conectar implementaciones más complicadas o agregar aspectos como el almacenamiento en caché como componentes separados.
La implementación en caliente, incluso si no la usa en tiempo de ejecución, es una muy buena prueba para validar si ha modularizado su aplicación correctamente. Si no puede comenzar sus paquetes en orden aleatorio, debe investigar por qué. Además, puede hacer que su ciclo de desarrollo sea mucho más rápido si puede actualizar un paquete arbitrario.
Siempre que pueda gestionar sus módulos y dependencias, los grandes proyectos se mantendrán manejables y se podrán desarrollar fácilmente (lo que le evitará la "reescritura completa" discutible).
La desventaja de OSGi? Es un marco de muy bajo nivel, y si bien resuelve bastante bien los problemas para los que está destinado, hay cosas que aún necesita resolver por su cuenta. Especialmente si proviene de un entorno Java EE, donde obtiene seguridad de hilos libre y algunos otros conceptos que pueden ser muy útiles si los necesita, debe encontrar soluciones para estos en OSGi usted mismo.
Un error común es no usar abstracciones sobre OSGi para facilitar esto al desarrollador promedio. Nunca jamás les permita meterse con ServiceListeners o ServiceTrackers manualmente. Considere cuidadosamente qué paquetes están o no permitidos: ¿Está dispuesto a otorgarles a los desarrolladores acceso al BundleContext o les oculta todo esto mediante el uso de algún tipo de modelo declarativo?
Usé OSGI en un proyecto (lo admito, no mucho). Proporciona buenas promesas, pero como dijo @Arne, aún necesita pensar por su cuenta sobre cómo modularizar.
OSGI ayudó a nuestro proyecto porque hizo la arquitectura más estable. Romper la modularización es más "difícil", por lo que las decisiones que tomamos sobre cómo modularizar se mantuvieron vigentes durante más tiempo.
Para decirlo de otra manera: sin OSGI, y bajo presión de tiempo para entregar, a veces usted o los miembros de su equipo realizan compromisos, accesos directos y otros hackeos, y se pierde la intención original de la arquitectura.
Así que OSGI no redujo la complejidad per se, pero lo protegió de crecer innecesariamente con el tiempo. Creo que eso es algo bueno :)
No he utilizado la función de implementación en caliente, así que no puedo comentar sobre eso.
Para responder a su último punto, cumplió con mis expectativas, pero requirió una curva de aprendizaje y cierta adaptación, y la recompensa es solo a largo plazo.
(Como nota al margen, su pregunta me recuerda un poco el adagio de que "maven es la peor parte de los sistemas de compilación")