Cosa c'è di nuovo in OSGi 4.2?

Question

OSGi 4.2 ha just been released che aggiorna la specifica 4.1 con alcuni nuovi RFC. Quindi, cosa c'è di particolarmente nuovo con OSGi 4.2, che i framework supportano già 4.2 (o sono vicini) e perché dovresti indirizzare i nuovi sviluppi su un framework 4.2 anziché su un 4.1?

Answer 1

Nella maggior parte dei casi, un rilascio punto di OSGi (come 4.1- > 4.2) in realtà non cambia molto il comportamento esistente, quindi è sicuro dire che se si dispone di un'app che dipende da 4.1, verrà eseguito su 4.2 senza problemi. La novità è che alcuni articoli sono stati standardizzati e dovrebbero consentire una migliore interoperabilità tra diversi motori OSGi (come Equinox, Felix e Knopflerfish).

Infatti, sebbene OSGi 4.2 sia stato rilasciato ufficialmente solo il 16 settembre 2009, le bozze iniziali sono state rese disponibili per altre, quindi le versioni precedenti dei prodotti (come Equinox 3.5, Felix 1.8) hanno già un supporto ragionevole per lo standard. Come i prodotti 802.11n, sono conformi alle bozze precedenti, ma l'aspettativa è che saranno certificati come pienamente conformi alla versione 4.2 in un futuro non troppo lontano.

Quindi, cosa c'è di nuovo in 4.2?

• Servizio Ganci
• Framework Avvio

E, nel compendio

• servizi remoti
• Bundle Tracker
• Blueprint Servizio

Servizio Ganci

Il Servizio Hook API consente di salire su eventi che si verificano a livello di servizio. Ad esempio, è possibile connettersi quando viene richiesto un servizio, quando un servizio ha un evento consegnato e così via. È inoltre possibile che gli eventi non vengano recapitati (ad esempio, nascondendo eventi che non si è autorizzati a vedere) ma non è possibile modificare alcun evento (poiché ciò potrebbe complicare le classi consegnate). I ganci di servizio fanno parte delle specifiche principali, quindi tutte le versioni di OSGi dovranno essere conformi.

quadro lancio

Anche se è possibile avviare un'istanza di programmazione OSGi da un'applicazione Java esistente, il modo in cui si esegue questa operazione è stato dipendente su cui runtime OSGi si sta utilizzando. In particolare, gli elementi di configurazione (come la posizione in cui archiviare i dati transitori, quale dovrebbe essere la politica di delega di avvio del pacchetto e così via) sono stati tutti definiti in modo specifico del motore. Questo consolida le proprietà che vengono impostate nel framework da qualsiasi utilità di avvio.

Servizi remoti

servizi telematici API permette servizi OGSi di comunicare tra VM (possibilmente su macchine diverse). L'esatto meccanismo di comunicazione (RMI, WebServices, ecc.) È aperto ai provider, quindi è diverso dalle altre tecnologie distribuite (come Corba) che specificano specificamente un formato in wire. Chiaramente, i servizi distribuiti hanno una semantica diversa da quelli locali (errori di comunicazione, problemi di serializzazione) ed è lasciato ai singoli servizi per essere distribuibili se necessario.

Tracker Bundle

Come il ServiceTracker prima che al punto 4.1, il BundleTracker può essere utilizzato per mantenere un occhio su cui fasci vanno e vengono nel sistema. Questo può essere utilizzato dalle GUI dinamiche per mostrare lo stato evolutivo del motore OSGi senza alcuna conoscenza specifica della piattaforma.

Eliocopisteria servizio

Il progetto è simile a Spring quanto fornisce un meccanismo di iniezione di dipendenza per la configurazione fasci. Per alcuni aspetti, è simile ai servizi dichiarativi; ma il servizio blueprint fa le cose in un modo diverso. Inoltre, a differenza dei servizi dichiarativi (che possono gestire solo i servizi presenti), il servizio blueprint può creare in anticipo un segnaposto proxy per un servizio che verrà reso disponibile in un momento successivo. Le chiamate al proxy del servizio verranno quindi bloccate fino a quando il servizio non potrà essere riempito (anziché restituire "null" come faranno i servizi dichiarativi). Se sei a tuo agio o familiare con Spring IOC e simili iniezioni di dipendenze, il servizio Blueprint sarà immediatamente comprensibile.

Answer 2

This article dettagli gli RFC di interesse. Per citare,

Prima di tutto si deve notare che questa non è una release minore come il numero di versione può suggerire. Release 4.2 è in realtà molto più significativo rispetto alla versione R4.1 dello scorso anno. A alcuni punti direi addirittura che è più importante della versione R4, perché con quell'unico utilizzo diventa molto più semplice, soprattutto per nessuno degli esperti di OSGi .

Answer 3

Le prime modifiche sono state highlighted here.

In particolare, la RFC 119 - Distributed funzione OSGi è interessante:

Questa soluzione definisce un livello minimo di caratteristiche/funzioni per l'elaborazione OSGi distribuito, inclusi il rilevamento dei servizi e l'accesso da e per gli ambienti esterni.

Questo combinato con EventAdmin (introdotto nel 41), consentirà di più facile implementazioni di servizi distribuiti basati su OSGi (attualmente implementate with ECF)

Answer 4

I servizi dichiarativi restituiscono effettivamente null quando non è disponibile un bind di riferimento? Su Equinox, anche se imposto la modalità su dinamico, il mio componente non viene mai instanciato se non può essere "cablato". Preferirei che fosse impostato su "null" come dici tu, in modo che potessi avere riferimenti opzionali e utilizzare la scoperta dinamica ...

Inoltre, mi manca la possibilità di trovare facilmente le proprietà del componente quando un servizio è vincolato (devo andare nel contesto Bundle, ottenere riferimenti di servizio, iterare e confrontare - non pratico). Forse mi manca qualcosa però.