Me gustaría saber qué se consideran las mejores prácticas o patrones para desacoplar el código de la aplicación del código de la infraestructura, específicamente con respecto a OSGi.Mejor práctica de acoplamiento suelto OSGi
Voy a utilizar el servicio example from the Felix SCR pages
El ejemplo es un comparador
package sample.service;
import java.util.Comparator;
public class SampleComparator implements Comparator
{
public int compare(Object o1, Object o2)
{
return o1.equals(o2) ? 0 : -1;
}
}
El código anterior no contiene cañerías marco, que está enfocado y conciso. Hacer que esté disponible para la aplicación, cuando se usa OSGi, implica registrarlo en un registro de servicio. Una forma, como se describe en las páginas de Felix vinculadas, es mediante el uso de Service Component Runtime.
// OSGI-INF/sample.xml
<?xml version="1.0" encoding="UTF-8"?>
<component name="sample.component" immediate="true">
<implementation class="sample.service.SampleComparator" />
<property name="service.description" value="Sample Comparator Service" />
<property name="service.vendor" value="Apache Software Foundation" />
<service>
<provide interface="java.util.Comparator" />
</service>
</component>
y
Service-Component: OSGI-INF/sample.xml
Todo agradable y encantador, mi implementación del servicio no tiene acoplamiento en absoluto a OSGi.
Ahora quiero utilizar el servicio ...
package sample.consumer;
import java.util.Comparator;
public class Consumer {
public void doCompare(Object o1, Object o2) {
Comparator c = ...;
}
}
El uso de la estrategia de búsqueda SCR tengo que añadir métodos marco de sólo:
protected void activate(ComponentContext context) {
Comparator c = (Comparator) context.locateService("sample.component");
}
uso de la estrategia de eventos SCR también tengo que añadir métodos marco de sólo:
protected void bindComparator(Comparator c) {
this.c = c;
}
protected void unbindComparator(Comparator c) {
this.c = null;
}
Ni son terriblemente onerosa, aunque creo que es probable que terminarías wi La cantidad justa de este tipo de código se duplica en las clases, lo que hace que sea más ruidoso filtrar.
Una posible solución que puedo ver sería utilizar una clase específica OSGi para mediar entre el consumidor, a través de medios más tradicionales, y el marco.
package sample.internal;
public class OsgiDependencyInjector {
private Consumer consumer;
protected void bindComparator(Comparator c) {
this.consumer.setComparator(c);
}
protected void unbindComparator(Comparator c) {
this.consumer.setComparator(null);
}
}
Aunque no estoy seguro de cómo lo arreglaría en la configuración de SCR.
Existe también org.apache.felix.scr.annotations, aunque eso significa que todo, sólo funcionará si usted está construyendo con el experto-SCR-plugin. No está tan mal realmente y, AFAICT, no imponen ninguna implicación en el tiempo de ejecución.
Así que, ahora que usted ha leído todo esto, ¿qué sugieres es la mejor manera de consumir OSGi servicios prestados sin 'contaminar' código de la aplicación con el código de la arquitectura?