Project JXTA este un "open network computing platform" proiectat pentru peer2peer "computing", cu scopul de a dezvolta servicii si pentru a permite dezvoltarea aplicatiilor inovative bazate pe grupuri de peer.
JXTA ofera un set comun de 6 protocoale, si un "open source reference implementation" pentru dezvoltarea aplicatiilor peer2peer.
" JXTA technology is a set of open, generalized peer-to-peer (P2P) protocols,
defined as XML messages, that allow any connected device on the network
ranging from cell phones and wireless PDAs to PCs and servers to communicate
and collaborate in a P2P manner "
Protocoalele JXTA standardizeaza modul in care peer- ii
o Descopera unul pe altul
o Se organizeaza in grupuri de peer, neavand nevoie de un server centralizat
o Publica si descopera servicii
o Comunica si se monitorizeaza intre ele
Protocoale JXTA sunt independente de sisteme de operare, de limbajele de
programare sau protocoale de transport. Ele se pot implementa in Java, C, C++, Perl, etc., sau ele pot fi implementate peste diferite protocoale de transport, TCP/IP, HTTP, etc. Din acest motiv echipamente cu software complet diferit pot intreractiona intre ele. Folosind technologia JXTA se pot dezvolta aplicatii care ofera:
o Independenta de platforma.
o Mecanism dinamic de descoperire de peer-uri si servicii.
o Adresare uniforma a peer-urilor. ID-urile JXTA au 128 biti.
o Creare de grupuri de peer care ofera servicii.
2.3.1 Arhitectura JXTA
Arhitectura JXTA se poate imparti pe 3 nivele, dupa cum rezulta din desenul urmator:
. Nivelul platforma (JXTA Core)
Nivelul platforma incapsuleaza primitive minimale si esentiale comune pentru retele p2p, ca de exemplu transport (inclus firewall handling), creare de peer si grupuri de peer cu primitivele de securitate asociate.
. Nivelul servicii
Include servicii care nu sunt neaparat necesare pentru o retea p2p, dar totusi utile, ca de exemplu indexare, cautare, sistem de fisiere distribuit, etc.
. Nivelul aplicatii
Nivelul aplicatii include implementari ale aplicatiilor integrate,ca si aplicatii de mesagerie, sharing de documente si fisiere, sistem de email, etc.
2.3.2 Concepte JXTA
. Peers
Un peer JXTA este o entitate care implementeaza unu sau mai multe dintre protocoalele JXTA. Ei pot fi senzori, telefoane mobile, PDA-uri, PC-uri, servere, sau chiar supercomputere. Un peer poate rula pe mai multe echpamente, sau invers, pe un echipament pot rula mai multe peer- uri. Un peer este unic identificat de un peer ID.
Ei publica una sau mai multe interfete de retea, fiecare dintre ele este publicat ca si un "peer endpoint", care identifica unic interfata respectiva.
. Peer Groups
O multime de peer-uri care ofera un set comun de servicii. Fiecare peer group este identificat unic de un peer group ID. Cateva motivatii pentru crearea grupurilor sint:
o Crearea unui mediu protejat, o politica de securitate poate fi fortat.
o Partajarea retelei in divizii mai mici
o Creare unui mediu de monitorizare
Grupurile ofera un set de servicii.Aceste servicii pot fi servicii de baza (Core Services) , sau servicii aditionale (dezvoltate pentru a extinde functionalitatea unui grup). O lista a serviciilor de bhaza oferite de un grup:
o Discovery service - serviciu care se foloseste pentru cautare de resursel ca si peeri, grupuri, pipe-uri sau alte servicii.
o Membership service - folosit de membri pentru acceptarea sau respingerea unui peer care vrea sa se alature grupului
o Pipe Service - este responsabil de crearea de conexiuni pipe intre membrii grupului.
o Resolver Service - este folosit pentru schimb de mesaje intre membri
o Monitoring Service - permite unui peer sa monitorizeze pe ceilalti din grup.
. Advertisements
Peer-ii publica serviciile lor prin documente XML numite "advertisement". Acestea pot publica servicii, pipe-uri, grupuri. Au un timp de viata, care dupa ce se expira advertisementul este sters, dar poate fi republicat ininte ca acesta sa se expire.
. Messages
Peer-ii comunica intre ele folosind mesaje JXTA. Mesajul este unitatea de baza a comunicarii intre peeri. Mesajele pot fi documente XML continand informatii de rutare, de "digest", de "credential", sau pot avea format binar codificat, incapsulat in body-ul mesajului XML.
. Pipes
Peer-ii folosesc pipe-uri pentru trimisul mesajelor. Pipe-ul este un mechanism de transport asincron unidirectional, suporta transferul a orice obiect (cod binar, string-uri, obiecta Java). Un pipe are 2 capete, input pipe(capatul care primeste mesajele) si output pipe(capatul care trimite mesajele).Capetele pipe( "pipe endpoints" )sint legate dinamic la "peer endpoints" (care corespund unei interfete retea, de ex adr. IP + port TCP). Avem mai multe tipuri de pipe:
o Point-to-point pipe: Unidirectional, un input pipe este conectat la un output pipe.
o Propagate pipe: Unidirectional, un output pipe este conectat la mai multe input pipe.
. Modules
Modulele sunt abstractii pentru reprezentarea a orice "bucata de cod" implementat pentru a oferi un comportament nou lumii JXTA. Aceasta bucata de cod poate fi o clasa JAVA, un jar JAVA, un DLL, un set de mesaje XML sau un script. Module framework-ul poate reprezinta acest comportamnet intr-un mod independent de platforma, de exemplu un peer poate instantia o implementare JAVA ori C a aceluiasi comportament. Capacitatea de a descrie si a publica comportament intr-un mod independent de platforma este esential pentru a avea grupuri compuse din peer-uri heterogene.
Modulul ese compus din module class, module specification, module implementation.
. ID-uri
Identifica unic un peer, grup, pipe sau alte resurse.
2.3.3 Protocoalele JXTA
2.3.3.1 JXTA Core Protocols
. Peer Resolver Protocol (PRP)
Acest protocol permite propagarea a query request generice la unu sau mai multe handleri specifici pe grup care identifica raspunsuri potrivite. Query-urile pot fi trimise la un singur peer sau pe intregul grup. PRP foloseste serviciul Rendezvous ca sa trimita mesaje la mai multe peeruri si mesaje de tip unicast daca trimite doar la un singur peer. Resolver query message este folosit ca sa trimita un resolver query request pentru a apela la serviciile altor membri pe grup. Mesajul contine credential-ul senderului, un query ID unic, un service handler specific, si query-ul.Fiecare serviciu isi inregistreaza un handler in peer grup ca sa proceseze aceste request-uri si sa genereze raspunsuri. Resolver response message este folosit ca sa trimita un resolver query message. Acest mesaj contine credential-ul senderului, un query ID unic, un service handler specific, si raspunsul. Un peer poate primi raspunsuri in numar de 0, 1 sau mai multe pe un request.
Protocoale de nivel mai inalt, Peer Information Protocol(PIP) si Peer Discovery Protocol(PDP) functioneaza pe baza PRP.
. Endpoint Routin Protocol (ERP)
Defineste un set de mesaje request/query care se folosesc la gasirea rutei intre un peer si destinatia sa. Cand un peer vrea sa trimita un mesaj la o adresa endpoint specifica se uita in cache-ul local daca are informatia de rutare. Daca nu il are trimite un "route resolver query request" la relay-uri disponibile pentru a cere informatia de rutare. Cand relay-ul primeste mesajul, verifica daca stie ruta, daca da trimite informatia (o lista de hop-uri). Relay-uri sint peeruri care salveaza in cache-ul lor local informatia de rutare. Orice peer pe un grup poate deveni relay. Informatia de rutare contine peer ID- ul sursei, peer ID-ul destinatiei, TTL (Time To Live) , si o secventa ordonata de ID-uri a peer-urilor gateway. Aceasta secventa poate sa fie incompleta dar trebuie sa contina cel putin primul relay. Mesajul raspuns contine peer ID-ul destinatiei, peer ID-ul router peer-ului care stie ruta pana la destinatie, si secventa ordonata a relay-urilor.
2.3.3.2 Core transport bindings
. Endpoin Service
Acest serviciu este responsabil pentru rezolva comunicarea intre doua peeri folosing protocoalele de transport JXTA, JXTA TCP binding sau JXTA HTTP binding. Endpoint Service este folosit mai ales de alte aplicatii sau servicii care au legatura cu topolioia retelei, ca de exemplu Resolver Service sau Propagation Service.
. Endpoint Router Transport Protocol
Aceest protocol este responsabil pentru comunicarea intre peeri care nu au o legatura directa intre ele.
2.3.3.3 Protocoalele standard JXTA:
. Rendezvous Protocol (RDV)
Acest protocol este responsabil pentru propagarea mesajelor intr-un peer grup. Este un protocol simplu care permite:
o Un peer se conecteaza la serviciu (poate sa trimita si sa primeasca mesaje propagate)
o Controlul mesajelor propagate (TTL, etc)
. Peer Discovery Protocol (PDP)
Acest protocol este folosit pentru cautarea si publicarea resurselor. Defineste doua mesaje care contin toate elementele necesare pentru a performa tranzactii de cautare intre peer-i. Aceste mesaje sunt:
o Discovery Query Message. Specifica parametri ca numarul sau o pereche atribut-valoare al advertisement-urilor cautate.
o Discovery Response Message. Specifica un format pentru raspunsuri la discovery query-uri
. Peer Information Protocol (PIP)
Acest protocol defineste un set de mesaje pentru a obtine informatii depre un remote peer (de exemplu masurarea traficului, sau obtinerea altor informatii de statut). Se poate folosi, de exemplu de rerutarea traficului unui peer, pentru imbunatatirea performantelor.
Mesajul PIP ping este trimis la un peer ca sa verifice daca este conectat, acel peer raspunde cu un mesaj peerinfo.
. Pipe Binding Protocol(PBP)
Acest protocol este folosit de un peer pentru a lega un pipe advertisement la un pipe endpoint.Procesul de legare a unei pipe la un endpoint este definit de PBP. Un pipe poate fi vazut ca o coada de mesaje care suporta operatii de create, open/resolve (bind), close (unbind), delete, send, si receive. Defineste un set de mesaje folosite pentru a cauta endpoints si raspunsuri la cereri de legare la endpoint.
2.3.4 Comunicare in JXTA
2.3.4.1 Organizarea retelei JXTA
Reteaua JXTA este o retea ad-hoc, multi-hop si adaptiv, compus din peer-ii conectati. Conexiunile in retea pot fi temporare, rutarea mesajelor poate fi nedeterministic. Peer-ii se pot imparte in patru categorii:
o Minimal edge peer
Poate trimite si primi mesaje, dar nu foloseste cache si nu ruteaza mesaje. Peer-I cu resurse limitate (mobil, PDA) vor fi minimal edge peer.
o Full-featured edge peer
Poate trimite si primi mesaje, stocheaza in cache informatii. Raspunde la mesaje discovery request cu informatiile din cache, dar nu- i trimite mai departe. Majoritatea peer-urilor sint edge peer.
o Rendezvous peer
Un rendezvous peer are toate functionalitatile unei edge peer, dar pe langa astea poate trimite mai departe mesaje discovery request. Cand un peer se alatura unui grup, automatic cauta un rendezvous peer, daca nu gaseste el se seteza dinamic rendezvous. Fiecare rendezvous are o lista cu peer-ii care o folosesc ca rendezvous, si o lista cu celalalte rendezvous-uri cunoscute.
o Relay peer
Acest tip de peer mentine informatii de rutare si ruteaza mesaje la peer-i. Prima data verifica cache-ul local, daca nu gaseste informatia dorita trimite mesaje cerere pentru informatii de ruta.
Fiecare peer implementeaza serviciile necesare pentru a deveni relay sau rendezvous. Aceste servicii se pot implementa ca si pereche pe aceeasi peer.
Diagrama urmatoare ilustreaza un simplu scenariu de comunicare:
A este un edge peer separat de Internet de un firewall, care vrea sa comunice cu peer D. Initial A este conectat la B, care este rendezvous pentru A. A deschide o conexiune HTTP cu B, dar, deoarece B nu stie nimic despre D trimite mai departe mesajul la C, care stie de D , trimite informatia la D care intoarce informatia ceruta. Se creeaza o conexiune virtuala, in care B si C sint routere.
Daca si A si D sint membrii unei retele private, aproximativ aceeasi scenariu de comunicare este valabil.
A vrea sa trimita un mesaj la D. Sa presupunem ca A deja are informatia de rutare despre D, dar amandoua sint situate dupa un firewall. A deschide o conexiune HTTP la B, B deschide o conexiune TCP la C. C avertizeaza pe D ca este un mesaj care il asteapta, D deschide o conexiune HTTP la C. Un canal virtual de comunicare este creat intre A si D in care B si C sint routere.
2.3.4.2 Group Management
Majoritatea solutiilor peer2peer folosesc propriile lor protocoale specializate, ICQ pentru chat foloseste un protocol, Kazaa pentru file sharing alta. Pentru ca JXTA permite ca toate aplicatiile JXTA sa ruleze pe aceeasi retea JXTA si sa interactioneze, un model de partitionare trebuie sa fie introdus care sa impiedice ca diferite aplicatii sa se interfereze. Din acest motiv s-a introdus notiunea de peer group. Grupurile pot fi separate pe mai multe criterii:
o Aplicatia folosita de peeri
o Nivelul de securitate necesitata de peeri (peer-ul se autentifica sau nu)
Cand un peer se conecteaza la reteaua JXTA este membru al NetPeerGroup.Cand utilizatorul se conecteaza la un nou grup, devine un membru al acelui grup si isi creeaza un pipe pentru a a primi mesajele de pe acel grup.
2.3.4.3 Formatul mesajelor
Toate aspectele in JXTA folosesc XML pentru a structura date ca un advertisement, mesaj, protocol. Iata un exemplu de JXTA Peer Advertisement:
JXTA nu specifica un format pentru payload-ul mesajelor JXTA. Este lasat in seama dezvoltatorului daca foloseste XML sau format binar.
2.3.4.4 Securitate
Nevoia de diferite nivele de securitate si acces de resurse in reteaua "ad-hoc" JXTA a condus la modelul de securitate "role based", unde un peer actioneaza cu autoritatea garantata de un alt "trusted peer". Formatul mesajelor permit adaugarea de o gama larga de informatie metadata la mesaj, ca credential-i, digest, certificate, chei publice. Fiecare mesaj contine un credential. Un credential este un token care este folosit ca sa identifice trimitatorul si drepturile sale. Credentialul este validat de destinatie.
2.3.4.5 Evaluare JXTA
JXTA defineste un limbaj abstract pentru comunicare, ofera o gama larga de servicii, conectivitate pentru o gama larga de echipamente.
. Eficienta
JXTA a fost dezvoltat pentru comunicare peer2peer, consecvent pentru comunicare cu un intreg grup, nodul trimitator trebuie sa trimita doar o singura copie a mesajului. Ajunge o singura conexiune deschisa pentru a primi mesaje de la intregul grup. Asta inseamna ca aceasta soluti se scalaeaza bine fata de solutiile prezentate in capitoalele anterioare.
. Compatibilitate
JXTA rezolva problema traversarii firewall-urilor si NAT-urilor, in acelasi timp rezolva si problema managementului grupurilor.
. Controlul informatiei
JXTA a fost proiectat in asa fel ca toate peer-urile sa fie egale, deci n-avem nevoie de un server central care sa se ocupe de anumite aspecte al controlului informatiei.
