JXTA.it - il Blog

Salve a tutti,

con un pò di ritardo eccomi qui a comunicarvi che la nuova versione di JXTA, la 2.6, è finalmente pronta. Di seguito eccovi la traduzione di un articolo scritto da Jérôme Verstrynge, colui che ha guidato con estrema determinazione e diligenza l’intero processo di sviluppo per quest’ultima versione.

JXTA/JXSE 2.6 è pronto!

Dopo più di un anno di duro lavoro, JXSE 2.6, l’implementazione in Java dei protocolli JXTA, è finalmente pronta.

“Euh… Che? Di nuovo JXTA? Me lo ricordi? Ooooh sì, quel progetto P2P Open Source avviato da Sun Microsystems nel 2001!!! Mi ricordo… difficilissimo da far funzionare, in qualche modo bacato, scarsa documentazione. Non riuscivo a capire il comportamento che ci stava dietro. Avevo grandi speranze, l’ho provato, poi l’ho lasciato perdere! Beh, che novità?”

La versione 2.6 è stata un’occasione per cominciare a ridurre le enormi lacune tecniche accumulate nel codice. Abbiamo iniziato con la rimozione di tonnellate di codice morto e con il refactoring di tonnellate di altro codice in modo da renderlo più leggibile. C’è ancora molto da fare. Un bit sequenziale alla volta.

Non è tutto:

OSGi
Adesso è possibile avviare la rete JXTA come bundle OSGi. L’implementazione OSGi di Apache Felix è stata integrata in JXSE come dipendenza e può essere usata come framework OSGi standard
Per ridurre l’utilizzo di thread e altre risorse è stato implementato un singolo oggetto Task Manager per utilizzare un singolo gruppo di thread. Notevole è stato l’impatto sulle performance. 300 peergroup possono essere eseguiti senza rallentamenti su un MAC.

Gestore della Cache

Nuove implementazioni del gestore della cache basate su Apache Derby, H2 o Berkeley DB sono ora diaponibili. Queste possono rimpiazzare la attuale implementazione standard B-Tree File System. Niente più piccoli file nel tuo hard disk. Il recupero degli advertising e in generale molto più veloce.

Oggetti per la Configurazione
Oggetti per la configurazione facili da usare, basati sulla classe Java Properties, sono adesso disponibili per impostare il Gestore della rete (NetworkManager). Queste possono essere facilmente salvati e caricati da documenti XML.
Metodi per la connettività
un nuovo set di metodi di monitoraggio tra EDGE, RENDEZVOUS e RELAY è stato implementato. Adesso un peer può davvero sapere dove si trova nella rete.

Nuova implementazione TCP
Una nuova implementazione del livello TCP basata sul NIO Netty è stato implementato. L’intenzione è quella di non reinventare la ruota e delegare il delegabile a performanti librerie già esistenti.

Documentazione
Finalmente, una lunga attesa e relativamente completa documentazione di cosa accade dietro le quinte è stata resa disponibile nella guida del programmatore. Il codice resta una specie di labirinto, ma questa volta abbiamo una mappa per schivare il minotauro.

Maven
E ultimo, ma non per importanza, stiamo stiamo ultimando la migrazione del progetto a Maven. Gli Artefatti saranno postati in un repository opensource offerto da Sonatype. Presto, una integrazione continua non sarà più un sogno.

Tutto questo arriva dopo la risoluzione di una lunga serie di bug, tra i quali uno davvero brutto in agguato durante la creazione della connessione tra due peers NATtati. Semplicemente non avrebbe funzionato.

“Allora, che cosa viene dopo?” - Beh, non vediamo l’ora di finire la migrazione da Java.net di Kenai, un nuovo protocollo HTTP, più refactoring per il miglioramennto del codice, l’attuazione del NAT traversal per il TCP e l’esecuzione di più peer sulla stessa JVM. Quest’ultimo è l’ultimo anello mancante per un completo ambiente di sviluppo guidato dai test. Questo ci ha impedito di realizzare una serie completa di test JUnit. Tutte le questioni in sospeso sono adesso ben definite, basta affrontarle una alla volta.

JXTA / JXSE 2.5 è ancora parte di Glassfish. Sun ha ridotto la sua partecipazione al progetto a partire dalla fine del 2008, ma alcune persone sono rimaste molto attive partecipando al trasferimento del know-How. Noi non sappiamo  in che misura Oracle deciderà di partecipare. La possibilità di cedere tutto ad Apache è stata proposta.

“Ci sono dei libri?” - per coloro che non vogliono passare dalle Guide del programmatore, le specifiche dei protocolli JXTA, usare Google e cercare di eseguire gli obsoleti esempi trovati in rete, ho rivisto la prima edizione di “Practical JXTA”.

Questo libro è un’introduzione a JXTA, JXSE e al P2P per ingegneri del software. Esso contiene un nuovo capitolo riguardante i problemi legati al NAT traversal.

Il progetto sta subendo una migrazione da javadev verso kenai. Potete trovare la nuova home del progetto JXTA all’indirizzo http://jxta.kenai.com/ mentre il binding in java lo trovate qui.

Vi ricordo inoltre che Jérôme ha ultimato la revisione del sul libro “Practical JXTA“, acquistabile sulla apposita pagina ospitata da lulu.com.

Comunicazioni, Core JXTA Jérôme Verstrynge, JXSE 2.6, JXTA 2.6, Practical JXTA, rilascio

Jérôme Verstrynge ha comunicato, con un messaggio nelle mailling lists del progetto jxta e uno sul forum, la propria intenzione di organizzare la prossima release del framework, JXTA 2.6.

Oltre che come autore del libro Practical JXTA, Jérôme è noto a tutti gli assidui frequentatori del forum della comunità come uno dei membri più attivi e disponibili.

Nel suo messaggio apprendiamo anche la sua idea delle fasi preliminari al rilascio.

Cara comunità JXTA,

Molti di voi mi conoscono già perchè ho pubblicato il libro ‘Practical JXTA’ l’anno scorso e perchè ho risposto a molti post sul forum.  Come molti di voi, vorrei vedere JXSE 2.6 rilasciata non appena possibile. Quindi, ho avvisato la “direzione” del mio interesse nell’acquisire la leadership per organizzare questa release spendendo un paio d’ore del mio tempo libero qua e là.

Il piano di rilascio che sto proponendo è il seguente:

MILESTONE I - REGISTRAZIONE DELLE MIGLIORIE E DELLE RICHIESTE DI MIGLIORAMENTO

Data: 9 maggio 2009
Questa milestone segna la scadenza per la sottomissione, da parte dei membri della comunità, per la sottomissione di migliorie e richieste di miglioramento per la release 2.6. Dopo questa data, ogni nuova richiesta sarà assegnata per le release successive alla 2.6. Nel frattempo i membri della community sono fortemente invitati a controllare la lista delle issues attuali: https://jxta-jxse.dev.java.net/issues/query.cgi e a sottomettere i bugs e le issues che hanno incontrato e che non sono ancora stati registrati.

MILESTONE II - PRIMO RILASCIO BETA

Data: Quando i fix per tutte le issues P1 e P2 sono stati postati.

L’obbiettivo di questa seconda milestone è produrre una prima beta release di JXSE 2.6 da far valutare ai membri della comunità una volta che i fix sono stati apportati nel trunk per tutte le P1 e P2 aperte. Nel frattempo, i fix per altre issues possono essere postate prima che giunga la milestone II. LA comunità avrà almeo due mesi per la valutazione di questa release.

MILESTONE III - SECONDO RILASCIO BETA

Data: Quando i fix sarano stati postati per tutti i P1, P2 e P3 seguenti la prima beta release

L’obbiettivo di questa terza milestone è produrre una seconda beta release di JXSE 2.6 da far valutare  ai membri della comunità una volta che tutte le fix per le P1, P2 e P3 sono state apportate al trunk. Nuove issues dalla prima beta release possono essere scoperte e sottoposte per la risoluzione prima della seconda release. La comunità avrà almeno due mesi per la valutazione di questa release.

MILESTONE IV - RILASCIO FINALE 2.6

Data: Quando i fix saranno stati postati per tutti i P1, P2 e P3 successive alla seconda beta release

L’obbiettivo di questa quarta milestone è produrre la release finale JXSE 2.6. Poi, tutte le issues restanti che non saranno risolte dalla release 2.6 saranno reindirizzate e future release di JXTA.

AVVERTENZE GENERALI

• La release proposta è dare priorità alla qualità rispetto alla velocità di consegna.
• La velocità alla quale le milestone giungeranno e la release 2.6 diventerà disponibile dipende dal contributo di tutti.
• Tra le milestone I e III, issues nuove e esistenti avranno la priorità e saranno tipizzate in accordo alla loro natura dai partecipanti al processo di rilascio.
• Se, dalla Milestone III, alcuni miglioramenti P3, P4 o P5 o issues legate alle caratteristiche rimangono irrisolti, questi saranno reindirizzati alla futura release di JXSE.
• Tutte le discussioni relative alla release 2.6 si terranno sulla mailing list dev.
• Gli annunci generali saranno fatti nella mailing list announcement, la mailing list user e sul forum.

Contributi di tutti i tipi e a tutti i livelli sono benvenuti e necessari. Se vuoi partecipare, invia una email alla mailing list dev o a me descrivendo come vuoi contribuire. Non esitare a fare domande se secessario.

Saluti,

Jérôme Verstrynge
(alias adamman71@dev.java.net)

Se volete esprimervi sulla bontà o sui possibili miglioramenti che si possono apportare al piano di rilascio potete scrivere alla mailing list come indicato da Jérôme.

L’originale in inglese:

Dear JXTA Community,

Many of you already know me because I have published the ‘Practical JXTA’ book last year and because I have answered many posts on the forum.  Like most of you, I would like to see JXSE 2.6 come out whenever possible. Therefore, I have notified the board that I am interested in taking the leadership to organize this release by giving a couple of hours of my free time here and there.

The release plan I am proposing is the following:

MILESTONE I - REGISTRATION OF ENHANCEMENTS & IMPROVEMENT REQUESTS

Date: May 9nd, 2009

This milestone sets the deadline for members of the community to submit enhancement and improvement requests for release 2.6. After this date, any such new request will be targetted for after release 2.6. In the mean time, members of the community are also strongly invited to check the current issue list: https://jxta-jxse.dev.java.net/issues/query.cgi and to submit bugs and issues they have encountered and which have not been registered yet.

MILESTONE II - FIRST BETA RELEASE

Date: When fixes will have been posted for all open P1 and P2

The objective of this second milestone is to produce a first beta release of JXSE 2.6 for review by members of the community once fixes will have been posted in the trunk for all open P1 and P2. In the mean time, fixes for other issues can also be posted before milestone II is reached. The JXTA community will be given at least two months to review this release.

MILESTONE III - SECOND BETA RELEASE

Date: When fixes will have been posted for all open P1, P2 and P3 following the first beta release

The objective of this third milestone is to produce a second beta release of JXSE 2.6 for review by members of the community once fixes will have been posted in the trunk for all open P1, P2 & P3’s. New issues from the first beta release may be discovered and submitted for resolution before the second beta release. The JXTA community will be given at least two months to review this release.

MILESTONE IV - FINAL 2.6 RELEASE

Date: When fixes will have been posted for all open P1, P2 and P3 following the second beta release

The objective of this fourth milestone is to produce the final JXSE 2.6 release. By then, all remaining issues which will not be resolved by release 2.6 will have been retargeted to a future release of JXTA.

GENERAL REMARKS

- The proposed release is giving priority to quality over speed of delivery.
- The speed at which milestones will be reached and release 2.6 will become available depends on the contribution of everyone.
- Between Milestone I and III, new and existing issues will be prioritized and typed according to their nature by those participating to the release process.
- If, by Milestone III, some P3, P4 or P5 enhancements or feature issues remain unsolved, these will be retargeted for a future release of JXSE.
- All discussions about release 2.6 will happen on the dev mailing list.
- General announcements will be made on the announcement mailing list, the user mailing list and on the forum.

All types and level of contributions are welcome and needed. If you want to participe, send an email to the dev mailing list or to me describing how you want to contribute. Do not hesitate to ask questions if necessary.

Cheers,

Jérôme Verstrynge
(alias adamman71@dev.java.net)

Core JXTA 2.6, Jérôme Verstrynge, JXSE, release

Nell’agosto di questo anno sono state realizzate da Mike Cumings, un membro della comunità JXTA, delle API che mirano a sostituirne altre da sempre poco amate e poco utilizzate dai programmatori, cioè CMS e CODAT. Anche se queste API sono già disponibili nelle versioni SVN di JXTA (nel ramo TRUNK), non saranno disponibili ufficialmente prima del rilascio della prossima versione.

Riportiamo una traduzione delle parole che lo stesso Mike Cumings ha usato per presentare il proprio lavoro alla comunità sul forum:

Di recente ho avuto la possibilità di sviluppare e aggiungere un nuovo servizio alle API JXSE, il ContentService. In parole povere, il ContentService è una interfaccia di servizio che può essere usata da un utente finale per trasferire dati arbitrari (Content) da un peer ad un altro. Queste nuove API hanno lo scopo di rimpiazzare, eventualmente, sia le esistenti (e inutilizzate) Codat API sia il progetto CMS.

Quindi, come funziona?

Il Content è condiviso da un peer che poi fornisce accesso ad un advertisement per questa condivisione. Un peer remoto diventa consapevole di questo advertisement (tipicamente, ma non necessariamente, tramite il DiscoveryService) e può usare l’advertisement per iniziare una sessione e ottenere i dati remoti.

In aggiunta alle funzionalità di base, le API del ContentService sono state costruite in modo da essere estensibili tramite plug-in e per supportare un numero qualsiasi di implementazioni di ContentProvider concorrentemente, ognuna delle quali ha la possibilità di accettare o ignorare le richieste in ingresso, basate sulle API. E’ il ContentProvider che effettua attualmente la condivisione ed il trasferimento del Content. Questo permette a specifiche classi di dati di essere intelligentemente condivise da una implementazione di ServiceProviders che hanno una conoscenza profonda di quella classe di dati. Il commit iniziale include due implementazioni molto rudimentali, una che è una ordinaria implementazione simile a TFTP e un’altra che sfrutta i JXTASockets. Queste implementazioni saranno sostituite tra non molto con qualcosa di più robusto, scalabile, e possibilmente standardizzato tra le varie implementazioni JXTA.

Nella eventualità che questa implementazione, come estensione, non fosse desiderata, è possibile sostituire direttamente il ContentService. In alternativa, tutti i fornitori possono essere aggiunti/rimossi/acceduti in modo programmatico dopo che il ContentService è stato inizializzato e avviato, permettendo la rimozione programmatica di implementazioni di provider aggiunti dinamicamente (ad esempio tramite il meccanismo jar SPI).

Aggiornamenti asincroni relativi allo stato del trasferimento e/o della condivisione, sono esposti in modo programmatico tramite eventi. Questo include sia gli eventi lato-server relativi alle condivisioni attive sia gli eventi relativi all’avanzamento dei trasferimenti lato-client.

I benefici percepiti di questo lavoro sono i segenti:

Questo lavoro può essere usato per futuri miglioramenti al meccanismo del loader del core di JXTA, permettendo alle implementazioni dei moduli di essere ottenute tramite protocolli di trasporto nativi per JXTA in aggiunta all’attualmente supportato protocollo HTTP.

Fornisce inoltre un metodo leggero, standard e semplice per spostare dati da un peer ad un altro con una minima gestione programmatica, riducendo le barriere per gli sviluppatori JXTA meno esperti.

I javadocs e gli esempi-tutorial che mostrano l’utilizzo delle API non sono al momento disponibili sui server JXTA. Riportiamo due snippets riportati in mailing list dallo stesso autore, anche se nel corso dello sviluppo le API potrebbero essere mutate a tal punto d non renderle più valide, le riportiamo per completezza:

//Example server code snippet:

ContentService service = new ContentServiceImpl();
service.init(netPeerGroup, ContentService.MODULE_CLASS_ID, null);
service.startApp(new String[0]);
ContentID contentID = IDFactory.newContentID(netPeerGroup.getPeerGroupID(),
                                                                 false);
FileDocument fileDoc = new FileDocument(file, MimeMediaType.AOS);
Content content = new Content(contentID, null, fileDoc);
List<ContentShare> shares = service.shareContent(content);
DiscoveryService discoService = netPeerGroup.getDiscoveryService();
for (ContentShare share : shares) {
    ContentShareAdvertisement adv = share.getContentShareAdvertisement();
    discoService.publish(adv);
}

//Example client transfer initiation code snippet:

ContentService service = new ContentServiceImpl();
service.init(netPeerGroup, ContentService.MODULE_CLASS_ID, null);
service.startApp(new String[0]);
ContentTransfer transfer = service.retrieveContent(contentID);
if (transfer != null) {
    transfer.startTransfer(new File("content"));
}

Da come possiamo vedere, in entrambi gli estratti il codice mantiene una certa semplicità.

Più avanti torneremo ad occuparci di questo nuovo strumento a disposizione, magari presentando un esempio di utilizzo.

Core JXTA API, CMS, Codat, ContentService, JXSE, Mike Cumings