Sotto OSGi, quali sono le principali differenze tra Componenti e Servizi? A quanto ho capito, tutti i servizi devono essere componenti, ma non tutti i componenti devono essere servizi.Qual è la differenza tra componenti e servizi OSGi
Quali sono i vantaggi dell'utilizzo di uno sull'altro con casi d'uso di esempio?
I "componenti" sono definiti in modo meno formale rispetto ai servizi.
Un servizio è qualsiasi oggetto registrato nel registro del servizio OSGi e può essere consultato utilizzando i relativi nomi di interfaccia. L'unico prerequisito è che un servizio dovrebbe implementare alcune interfacce ... qualsiasi interfaccia. Ad esempio, potrei registrare un oggetto eseguibile sotto l'interfaccia java.lang.Runnable e i client potrebbero cercarlo usando quel nome di interfaccia.
Un "componente" tende ad essere un oggetto il cui ciclo di vita è gestito, solitamente da un framework di componenti come Servizi dichiarativi (DS), Blueprint o iPOJO. Vedi this page sul Wiki della comunità OSGi per una discussione sui diversi framework di componenti disponibili.
Un componente può avere una delle seguenti caratteristiche, in combinazione o da soli:
In generale, l'utilizzo di un framework di componenti è il modo più semplice per lavorare con i servizi OSGi poiché il framework gestirà l'associazione ai servizi che si desidera utilizzare. Ad esempio, potresti dire che il tuo componente "dipende da" un particolare servizio, nel qual caso il componente verrà creato e attivato solo quando quel servizio sarà disponibile e sarà distrutto anche quando il servizio non sarà disponibile.
EDIT: vedere la risposta di Neil Bartlett, ho risposto in modo abbastanza specifico ai Servizi dichiarativi ma è più sottile di quanto ho affermato in modo errato qui.
In breve: i componenti sono consumatori di servizi non provider, i servizi sono un'estensione di componenti che registrano come fornitori di servizi.
Un componente ha un ciclo di vita (de/activate e modify), gestione delle dipendenze del servizio (un/bind).
Un servizio è un'estensione di un componente; tramite il registro di servizio, offre i suoi servizi ad altri pacchetti ecc. pubblicando interfacce e proprietà implementate.
Il caso d'uso per i servizi è ovvio, i casi tipici per l'utilizzo dei componenti richiedono la gestione del ciclo di vita, della configurazione o delle dipendenze del servizio, ma non richiedono/si desidera pubblicare il componente per l'utilizzo tra i pacchetti.
Non sono d'accordo sul fatto che "i componenti non sono fornitori".Un componente può essere un consumatore o un fornitore di un servizio, o entrambi o nessuno dei due. –
Ciao @Neil, AFAIK (e per favore correggimi qui) Pensavo che un Componente non registrato come Servizio non potesse essere associato a un altro Componente (anche nello stesso pacchetto - sicuramente sembra il caso di Felix DS) – earcam
Questo è vero se ti limiti alla definizione DS di un componente. In Blueprint e in altri framework, i componenti possono consumare o essere collegati ad altri componenti nello stesso bundle senza servizi di pubblicazione. Non penso che questo sia rilevante però: puoi avere componenti che sono servizi, componenti che NON sono servizi e servizi che non sono componenti .... –
potresti fornire un esempio di un componente che non è un servizio? – santiagozky
@santiagozky Certo. Si supponga di voler scrivere un componente server che si trova su socket e risponde alle richieste su TCP/IP. All'avvio del componente, apre il socket e crea i thread necessari per servire i client. Quando si ferma, chiude il thread (s) e presa. Un altro esempio: un componente che crea una GUI utilizzando Swing, SWT o JavaFX. Nessuno di questi componenti di esempio sono i servizi stessi, sebbene possano * utilizzare * servizi pubblicati da altri componenti. –
@neal, grazie. Lo capisco adesso. – santiagozky