Embedded OSGi o paquete de aplicación

Question

Acabo de pasar los últimos dos días leyendo todas las cosas OSGi que puedo tener en mis manos y finalmente creo que tengo mi cabeza alrededor.

Ahora estoy tratando de integrarlo con una aplicación existente por muchas razones, como complementos de terceros, actualizaciones automáticas, sin mencionar que SOA simplemente me hace feliz.

ahora tengo una decisión que estoy luchando para hacer, que es tiempo

1. Toda mi aplicación debe convertirse en un paquete OSGi instalado por defecto en el recipiente; o
2. Mi aplicación debería iniciar un contenedor OSGi incrustado e interactuar con él para todos los servicios conectados.

Preferiría 1, ya que esto me permite actualizar la aplicación fácilmente y la arquitectura sería coherente. Por supuesto, espero tener que refactorizar la aplicación en muchos paquetes más pequeños. Sin embargo, 2 hace las cosas mucho más fáciles a corto plazo, pero se volverán incómodas en el futuro.

Answer 1

¿Has mirado el servidor de aplicaciones Spring? ¿Esto no te permite administrar esto?

Answer 2

para la opción 1) realmente no desea que toda su aplicación en un paquete - perdería todos los beneficios de OSGi - pero realmente eso depende del tamaño de su aplicación.

Realmente depende de dónde desea ejecutar la aplicación y qué tarea desea que realice. También es probable que desee tener algún tipo de comunicación remota para acceder a los servicios expuestos.

en la opción 1) necesita habilitar algún tipo de paquete http/servlet (existe un puente) en la opción 2) su aplicación puede ejecutarse dentro de un servidor de aplicaciones para que no tenga que preocuparse por eso .

La primera pregunta que quiere hacerse es sobre el entorno operativo. ¿Quién va a ejecutar la aplicación? ¿Necesitan/quieren ser entrenados en OSGi? ¿Están más cómodos con la pila J2EE?

Creo que la mejor opción para usted es mantener sus opciones abiertas, no hay diferencias reales entre 1) y 2) pero lo que está mirando al marco OSGi, ya sea su código o el código de la estructura. Su aplicación en sí misma, es decir, los paquetes que constituyen su aplicación serán exactamente iguales.

Mi consejo es que no se preocupe demasiado por el tiempo de ejecución de OSGi, pero comience con el desarrollo OSGi, nada le impide desarrollar el "estilo OSGi" y funcionar en un entorno JRE estándar.

Answer 3

Creo que quiere ir con la opción 1, y hacer que su aplicación consista en un conjunto de paquetes dentro de un contenedor OSGi (en su mayoría listo para usar).

1. Mejorará la modularidad de su propio código. Incluso puede encontrar que algunas partes de este pueden proporcionar servicios de uso fuera de la aplicación original.
2. Es mucho más fácil utilizar otros paquetes desde el interior de OSGi, que desde la aplicación host. Debido a que la aplicación de host no puede ver las clases de paquetes (y los paquetes solo pueden ver lo que expone explícitamente desde el host), debe configurar un classpath bastante intrincado o recurrir a la reflexión para llamar paquetes desde fuera del contenedor.

Así que yo diría que incluso en el corto plazo, la opción 1 es probablemente más fácil.

Además, estoy de acuerdo con la afirmación de Patrick que la mayor parte de su código no tiene por qué preocuparse si se ejecuta en OSGi o en una JVM llanura. Especialmente cuando se usan los Servicios Declarativos y tal, la necesidad de usar interfaces y mecanismos OSGi de su código se reduce enormemente: solo agrega unos pocos archivos de descriptores al META-INF del jarrón.

Answer 4

preferiría ir con la opción 2, Intrínsecamente su aplicación no es un paquete, sino una aplicación. Si desea agregar el valor OSGi, engendre el contenedor OSGi desde su aplicación. De esta manera, en el futuro si decides alejarte de OSGi, puedes hacerlo de una manera sencilla.

Answer 5

sin duda recomendaría 1 - la aplicación debe convertirse en un paquete (s) de OSGi, y no sólo debido a una fácil actualización. Si la mitad de su código está en el marco OSGi y la mitad está afuera, tendrá que construir un puente para la comunicación entre las dos mitades; también podría tener problemas con la visibilidad de las clases.

también hay muchos beneficios de 1, y no es tan difícil de lograr. Lo que recomendaría es lo siguiente:

• Separe la aplicación en tantos módulos como le parezca lógico.

No está obligado a tener muchos módulos: OSGi puede manejar fácilmente dos paquetes de 10 MB cada uno, así como 100 paquetes más pequeños. La separación debe ser el resultado de la funcionalidad en sí misma: un buen punto de partida es el diagrama de arquitectura UML que probablemente hizo antes incluso de comenzar a implementar el material. Los lugares donde las diferentes partes funcionales se comunican entre sí son exactamente los lugares donde debería pensar en definir interfaces en lugar de clases, y estas interfaces se convertirán en sus servicios OSGi y las implementaciones se convertirán en paquetes, y la próxima vez tendrá para actualizar una parte descubrirá que es mucho más fácil predecir el efecto en las otras partes de la aplicación porque la separó claramente y la declaró en el manifiesto de los paquetes.

• Separe las bibliotecas de fuentes externas/abiertas que utilice en paquetes separados. Lo más probable es que sean las partes que tendrán que actualizarse más a menudo y en una línea de tiempo diferente a su propio código. ¡Aquí también es más importante definir dependencias claras de paquetes, versiones de paquetes y evitar depender de las partes de implementación en lugar de solo en las interfaces!

• pensar en qué partes de la aplicación que desea exponer a los plugins. Luego haga que los servicios OSGi salgan de estas partes, es decir, publique las interfaces en el registro OSGi. No necesita implementar nada específico: puede publicar cualquier objeto Java. Los complementos luego usarán el regimiento para la búsqueda.

• Lo mismo ocurre con los complementos: piense en lo que desea obtener de los complementos y defina las interfaces respectivas que los complementos pueden implementar y publicar y su aplicación puede buscar en el registro.

• Y como último consejo - ver lo que haces ya están disponibles en el marco de OSGi que ha elegido. Hay muchas interfaces OSGi estándar definidas por la especificación OSGi: para la configuración, el registro, el almacenamiento persistente, las conexiones remotas, el administrador del usuario, el evento y mucho más. Como son estándar, puede usarlos sin depender de ninguna implementación OSGi específica.Y desinstala lo que no necesitas.