¿Cuál es la mejor manera de comenzar con OSGI?

Question

¿Qué hace que un módulo/servicio/bit de la funcionalidad de la aplicación sea un candidato particularmente bueno para un módulo OSGi?

Estoy interesado en usar OSGi en mis aplicaciones. Somos una tienda de Java y usamos Spring bastante, así que me estoy inclinando por usar Spring Dynamic Modules for OSGi(tm) Service Platforms. Estoy buscando una buena manera de incorporar un poco de OSGi en una aplicación como prueba. ¿Alguien ha usado esto o una tecnología OSGi similar? ¿Hay alguna trampa?

@Nicolas - Gracias, ya lo he visto. Es un buen tutorial, pero estoy buscando más ideas sobre cómo hacer mi primer paquete OSGi "real", a diferencia de un ejemplo de Hello World.

@david - ¡Gracias por el enlace! Idealmente, con una aplicación greenfield, diseñaría todo para que sea dinámico. Lo que estoy buscando ahora, sin embargo, es introducirlo en una pequeña parte de una aplicación existente. Asumiendo que puedo elegir cualquier parte de la aplicación, ¿cuáles son algunos factores a considerar que harían que esa pieza sea mejor o peor como un conejillo de indias OSGi?

Answer 1

Bueno, como no puede tener una parte OSGi y una parte no OSGi necesitará hacer toda su aplicación OSGi. En su forma más simple, crea un único paquete OSGi de toda su aplicación. Claramente, esta no es una mejor práctica, pero puede ser útil tener una idea de cómo desplegar un paquete en un contenedor OSGi (Equinox, Felix, Knoplerfish, etc.).

Para llevarlo al siguiente nivel, usted querrá comenzar a dividir su aplicación en componentes; los componentes normalmente deben tener un conjunto de responsabilidades que pueden aislarse del resto de su aplicación a través de un conjunto de interfaces y dependencias de clase. La identificación de estos elementos puramente a mano puede ir desde lo más sencillo para una aplicación bien cohesionada pero bien acoplada bien diseñada hasta una pesadilla para el código fuente interconectado con el que no está familiarizado.

Alguna ayuda puede provenir de herramientas como JDepend que pueden mostrarle el acoplamiento de paquetes Java contra otros paquetes/clases en su sistema. Un paquete con acoplamiento eferente bajo debería ser más fácil de extraer en un paquete OSGi que uno con acoplamiento eferente alto. Se puede obtener aún más información arquitectónica con herramientas profesionales como Structure 101.

Puramente en un nivel técnico, trabajando a diario con una aplicación que consta de 160 paquetes OSGi y usando Spring DM, puedo confirmar que la transición de Spring a Spring DM "normal" es en gran medida sin dolor. El espacio de nombres adicional y el hecho de que puede (y debe) aislar su configuración de Spring específica de OSGi en archivos separados hace que sea aún más fácil tener escenarios de implementación de OSGi y sin ellos.

OSGi es un modelo de componentes profunda y ancha, la documentación que recomiendo:

• OSGi R4 Specification: Obtener los archivos PDF del núcleo y la especificación Compendio, que son canónicos, con autoridad y muy legible. Tenga a mano un atajo en todo momento, los consultará.
• Lea sobre las mejores prácticas de OSGi, hay un gran conjunto de cosas que puede hacen sino un conjunto algo más pequeña de las cosas que debe hacer y hay algunas cosas que debe no hacer (DynamicImport: * para ejemplo).

Algunos enlaces:

• OSGi best practices and using Apache Felix
• Peter Kriens and BJ Hargrave in a Sun presentation on OSGi best practices
• un concepto clave OSGi son Servicios, saber por qué y cómo se suplantan el patrón Listener con el Whiteboard pattern
• The Spring DM Google Group es muy sensible y amigable en mi experiencia
  The Spring DM Google Group es no longer active y se ha mudado a Eclipse.org como el proyecto Gemini Blueprint que tiene un foro here.

Answer 2

Me gusta mucho el Apache Felix tutorials. Sin embargo, creo que, en general, aprovechar OSGi en su aplicación no es una de esas decisiones de "usemos este marco porque es exagerado". Es más una cuestión de diseño, pero luego todo lo que OSGi te brinda en términos de diseño, también puedes tenerlo con Java.

En cuanto al tiempo de ejecución, no puede simplemente agregar una aplicación existente y habilitarla OSGi. Necesita ser diseño para ser dinámico. Spring DM hace que sea fácil esconder eso de usted, pero todavía está allí y debe ser consciente de ello.

Answer 3

¿Su aplicación existente es monolítica o está escalonada en capas o procesos separados?

Si tiene niveles, puede convertir el nivel medio/aplicación para ejecutar en un contenedor OSGi.

En la experiencia de mi equipo, hemos encontrado que tratar de hacer cosas web en OSGi es doloroso. Otros puntos dolorosos son Hibernate y Jakarta Commons Logging.

Encuentro que las especificaciones de OSGi son bastante legibles y recomiendo imprimir el diagrama de flujo que muestra el algoritmo para la carga de clases. Te garantizaré que tendrás momentos de "¿por qué recibo un NoClassDefFoundError?": El diagrama de flujo te dirá por qué.

Answer 4

Hay un par de consideraciones a tener en cuenta si está comenzando con OSGi.

Como se mencionó en otras partes de este hilo, conocer la carga de clases es realmente importante. En mi experiencia, todo el mundo tarde o temprano tiene problemas con eso.

Otra cosa importante para recordar es: ¡nunca guardar referencias! Eche un vistazo al patrón de la pizarra en la que se basa el concepto de servicios de OSGi (consulte el enlace en una de las otras respuestas).

En mi experiencia, no debe intentar convertir una aplicación monolítica en una basada en OSGi. Esto generalmente conduce a un desastre grave e inmanejable. Empezar de nuevo.

Descargue una de las implementaciones de oSGi autónomas disponibles de forma gratuita. Encontré Knopflerfish bastante bueno y estable (lo uso en muchos proyectos). También viene con un montón de código fuente. Puede encontrarlo aquí: http://www.knopflerfish.org

Otro buen tutorial se puede encontrar aquí. https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial

Peter Kriens de la Alianza OSGi dio una buena entrevista: http://www.infoq.com/interviews/osgi-peter-kriens. Su página de inicio y blog (que siempre es una buena lectura se pueden encontrar aquí: http://www.aqute.biz

Answer 5

Pruebe http://neilbartlett.name/blog/osgibook/. El libro tiene ejemplos prácticos con las mejores prácticas de OSGi.

Answer 6

Al aprender una nueva tecnología, las herramientas ricas le permiten trabajar sin grandes dolores de cabeza. En este punto la comunidad en ops4j.org proporciona un amplio conjunto de herramientas llamado "PAX", que incluye:

• Pax Runner: Ejecutar y cambiar entre Felix, Equinox, Knopflerfish y consejería fácil
• Pax Construir: construir, organizar & proyectos de construcción OSGi con Maven fácilmente
• Pax Drone: Pruebe sus paquetes OSGi con Junit mientras que ser independiente de marco (utiliza PaxRunner)

entonces hay muchas implementaciones de servicios compendio de OSGi:

• Pax registro (tala),
• Pax Web (servicio HTTP),
• Pax Web Extender (soporte de guerra),
• Pax Coin (configuración),
• Pax Shell (implementación de shell, parte de la próxima versión de osgi)
• y mucho más.

.. y hay una muy útil, independend marco comunitario, - pero eso es ahora AVISO ;-)

Answer 7

Esta respuesta llega casi 3 años después de que se hizo la pregunta, pero la link acabo de encontrar es realmente bueno, especialmente para los principiantes que usan maven. Una explicación paso a paso.

Answer 8

Trate http://njbartlett.name/files/osgibook_preview_20091217.pdf

O

http://www.manning.com/hall/

El segundo no es un libro que he leído a mí mismo, pero he oído cosas buenas sobre él.

La primera fue muy útil para mí. Él te lleva a través de la arquitectura inicialmente y luego es manos en OSGi.