¿Qué tan grandes deben ser los paquetes OSGi?

7

O más completamente "¿Cuáles son las ventajas y desventajas y las preguntas que deben plantearse al tratar de decidir la estructura del paquete de una aplicación OSGi?"

Nuestros paquetes OSGi existentes han tendido a ser bastante completos: básicamente un paquete API y un paquete de implementación, pero con mucha funcionalidad. Eso tiene ventajas en términos de complejidad de proyecto y construcción, pero tal vez no nos brinde toda la reutilización y flexibilidad que deseamos.

Así que en un proyecto reciente, hicimos intencionalmente paquetes bastante delgados. Hicimos un recorrido a través de esta mañana y nos preguntamos si habríamos ido demasiado lejos. En este servicio bastante pequeño teníamos 7 paquetes, varios de los cuales solo tenían 1 clase de dominio. La pregunta que se planteó fue "Esto es casi como si estuviéramos conduciendo hacia un paquete por paquete. Pero tenemos clases y paquetes ya en el idioma, ¿estamos yendo demasiado lejos con la granularidad de nuestro paquete?"

Para concretarlo, este es un servicio web que realiza un cálculo de los resultados agregados de otras consultas web (específicamente, consultamos un conjunto de bases de datos astronómicas para objetos en un área determinada y luego filtramos los resultados según nuestra propios criterios y luego estimamos la probabilidad de una observación adecuada basada en los resultados filtrados). Terminamos con 7 paquetes, lo que parece mucho para lo que es esencialmente "un servlet que realiza un cálculo".

¿Es tan buena granularidad buena (mucha flexibilidad en tiempo de ejecución) o mala (demasiado complicada)? ¿Cómo podemos desarrollar nuestra intuición sobre la granularidad "correcta" de nuestros paquetes OSGi?

    
pregunta Larry OBrien 09.01.2012 - 22:52

3 respuestas

3

Ya que no ha habido ninguna respuesta hasta ahora, déjame darte una idea de cómo suelo abordar este asunto. Para mí, los paquetes OSGi corresponden aproximadamente a componentes en la arquitectura del software y el factor más importante para convertir o no algo en su propio paquete es el valor de poder intercambiarlo.

Siempre que pueda imaginar que una versión futura de su producto puede querer confiar en un componente diferente que realiza las mismas tareas (es decir, la misma interfaz), pero lo hace de una manera diferente, convirtiéndolo en un paquete OSGi ciertamente no es No es la peor manera.

Otro punto (aunque obvio) es cuando escribes un software que otros pueden extender al agregar sus propios paquetes.

Como todo esto suena bastante abstracto, hagámoslo más concreto en función de su ejemplo:

  • usted agrega los resultados de las consultas web. No me importaría agrupar agregadores para cada base de datos. Lo más probable es que tenga que agregar otra base de datos de alguna manera en el futuro y debería poder delegar fácilmente esa tarea a otros, dándoles un paquete existente para otra base de datos y pedirles que agreguen una nueva en Monkey-see Monkey -hacer.

  • filtra los resultados. Los filtros son una de las cosas que tienden a cambiar con bastante frecuencia y, por lo tanto, son un ajuste natural para el empaquetado, por lo que puede intercambiarlos fácilmente.

En cuanto a los cálculos, no conozco lo suficiente, pero en general no creo que los 7 paquetes sean demasiado para lo que estás describiendo.

Sin embargo, hay una cosa que tener en cuenta: el esfuerzo de crear tantos paquetes solo paga cuando se tiene un producto en el que se está trabajando continuamente. Si en las siguientes semanas / meses / años agregará nuevos paquetes en todo el lugar, tener una granularidad fina facilitará el ajuste de las nuevas funcionalidades y la sustitución de las antiguas.

Si, por otro lado, tendrá que reescribir casi todo de todos modos, ya que su producto solo recibe actualizaciones importantes que parecen productos nuevos, entonces no gana mucho de todos modos.

    
respondido por el Frank 11.01.2012 - 07:18
1

Manténgalo lo más simple posible hasta que necesite la complejidad. Es decir: no diseñe los paquetes hasta que haya un valor claro en tenerlos. Lo más simple posible, pero no más simple.

Es poco probable que usted prediga exactamente dónde se dividirán sus paquetes en el futuro y dónde querrá extenderse ahora. Al empaquetar en exceso, está creando un dolor de cabeza de mantenimiento para el futuro, una vez que tenga un requisito para el intercambio de paquetes.

    
respondido por el jasonk 30.01.2012 - 09:58
1

Uno de los mayores beneficios de OSGi es que crea dependencias realmente sueltas entre sus componentes o servicios. Esto le permite realizar una implementación en caliente en entornos de producción. Si ve esto como una razón clave para usar OSGi, entonces tiene sentido agrupar paquetes que crea que deberán cambiar juntos. Si se puede cambiar independientemente del resto de la aplicación, probablemente debería colocarlo en su propio paquete. La sobrecarga de crear un nuevo paquete es razonablemente baja, por lo que no debería preocuparse demasiado por complicar demasiado su sistema con varios paquetes.

    
respondido por el Oleksi 17.02.2012 - 23:11

Lea otras preguntas en las etiquetas