2012-06-11 18 views

risposta

14

Nel OSGi, la ServiceTracker è un modo programmatico per acquisire un riferimento a un servizio. Ad esempio, si scrive codice ServiceTracker che "tiene traccia" di un riferimento a un altro servizio e consente di utilizzarlo quando diventa disponibile.

Al contrario, Servizi dichiarativi (DS), consente di dichiarare le dipendenze che vengono iniettate nel componente. DS è, in quanto tale, una forma di iniezione di dipendenza. Il grafico delle dipendenze tra i servizi, insieme al loro ordine di avvio determinerà quando verrà avviato il servizio. La proprietà di cardinalità in una definizione di DS consente di dichiarare se la relazione è obbligatoria (1..1), multiplo con almeno uno (1..n), facoltativo (0..1) o più opzionale (0..n). Quando si dichiarano relazioni obbligatorie, il servizio non verrà avviato finché tutte le dipendenze non saranno soddisfatte. Quando si dichiara una relazione facoltativa, il servizio verrà avviato indipendentemente dallo stato della dipendenza, ma è necessario fare attenzione nel codice che il riferimento al servizio potrebbe essere nullo.

Da un punto di vista pratico, ServiceTracker è un codice molto generico per la scrittura e la manutenzione. Data la natura dinamica dei servizi OSGi, ci sono molti stati consentiti dalle specifiche OSGi che devono essere presi in considerazione. DS ti darà un modo pulito per dichiarare e mantenere le tue dipendenze. Le dipendenze ben definite ti aiuteranno a mantenere la coerenza del tuo ambiente di runtime.

+1

DS - Servizi dichiarativi – Robin

+0

@Robin Ho sempre mescolato quell'acronimo nella mia testa - corretto. – maasg

3

Un Tracker del servizio OSGi consente di registrare i listener per determinati servizi, in modo da poter reagire quando tale servizio diventa disponibile.

I Servizi di dichiarazione, d'altra parte, utilizzano implicitamente il tracker del servizio per ritardare l'esecuzione del codice di attivazione del bundle fino a quando le dipendenze del servizio non sono state risolte.

4

I Servizi di dichiarazione (DS) sono abbastanza semplici da utilizzare ed è possibile evitare parte del codice boilerplate associato all'utilizzo di ServiceTracker. Se si utilizza OSGI, utilizzando solo ServiceTracker, è necessario occuparsi di alcuni aspetti della natura dinamica dei servizi OSGI. I servizi possono andare e venire e il tuo componente deve occuparsene. Se usi DS, la maggior parte di questo lavoro è già stato fatto. Hai solo bisogno di definire riferimenti ad altri servizi e DS inserirà tali riferimenti quando saranno disponibili. DS attiverà il tuo componente quando i requisiti del componente saranno soddisfatti.

Se si utilizzano annotazioni SCR Apache Felix o le annotazioni fornite da bndlib, è anche possibile evitare di scrivere il xml richiesto dai Servizi dichiarativi. Recentemente il gruppo OSGI ha anche pubblicato le loro annotazioni. Penso che quelli forniti da bndlib e quelli da OSGI siano molto simili e sono quasi sicuro che lo strumento bnd possa processarli entrambi.

Ho usato annotazioni Apache SCR qualche tempo fa, ma ora preferisco usare bndlib perché include annotazioni per Metatype e alcune classi che rendono molto più semplice l'implementazione di un Servizio gestito. Il metatipo è una specifica correlata ai servizi gestiti. Fondamentalmente, fornisce metadati che possono essere utilizzati dalle implementazioni di Config Admin per fornire un'interfaccia più user-friendly per la configurazione di un componente.

Conosco altre due alternative: iPojo e Blueprint.

iPojo è piuttosto potente e ricco di funzionalità. Estrae la maggior parte degli elementi OSGI e include alcune funzioni interessanti come il supporto EventAdmin e il supporto di ConfigAdmin.

Ho usato un po 'di Blueprint, ma a causa dell'uso eccessivo di xml non mi piace più di tanto. Penso che potresti dire che Blueprint è come Spring per OSGI.

Problemi correlati