Asteptând în fata navigatorului după o pagină rătăcită undeva în imensitatea Web-ului, v-ati dorit vreodată să angajati pe cineva care să aducă paginile HTML în locul vostru, fără să vă încurce? Nu? Nici măcar în fata unei pagini plină de appleturi miracu loase care afisează un mesaj din clasa: Asteptati un moment…? Tot nu? Să o luăm atunci altfel: să presupunem că sunteti un programator. Nu e o presupunere prea restrictivă, cu totii suntem programatori într-o anumită măsură (fuzzy, nu-i asa)? Nu ati sim tit niciodată că pierdeti prea mult timp concentrându-vă asupra interfetei utilizator, pierzând din vedere esentialul?
Dacă răspunsul la măcar una dintre întrebări este da, acest articol vă interesează în mod direct. Pentru că Marimba a făcut un mare pas înainte în rezolvarea acestor probleme, iar articolul este despre noile tehnologii introduse de Marimba.
De la lansarea oficială de către Sun a limbajului Java a trecut mai mult de un an dar, cel putin în ceea ce mă priveste, încă n-am uitat promisiunile pe care le făcea James Gostling în „Java Language Environment - A White Paper“. Multe dintre ele erau deja, sau au devenit, realitate în timpul care s-a scurs de atunci. Toate, mai putin una: în lista avantajelor pe care Java le oferă se specifica faptul că „aplicatiile [Java] sunt adaptabile la medii de lucru evolutive pentru că se pot aduce sau actual iza dinamic modulele de cod de oriunde din retea“. Gostling face mai apoi următoarea precizare: „codul executabil poate fi încărcat de oriunde, ceea ce permite actualizarea transparentă a aplicatiilor. Vor rezulta de aici servicii on-line care se îmbun ătătesc permanent; …“. La vremea respectivă, cred că această parte din descrierea limbajului m-a atras cel mai tare. Din păcate, această parte este si singura care nu a fost complet implementată în JDK. De fapt, Gostling făcea aceste ultime remarci în cadrul unei discutii despre HotJava, mult asteptatul navigator si editor HTML de la Sun. Dar HotJava, aflat încă în stare prebeta (2) după un an si jumătate de la anuntul initial, pare să nu se grăbească foarte tare să „lovească“ piata. Sau poate că sun t eu prea nerăbdător.
James Gostling este, fără îndoială, părintele spiritual al limbajului Java. Dar Java nu este doar un limbaj, el este în acelasi timp un mediu complex de executie, încărcare si validare a aplicatiilor. Iar pentru a crea un mediu este nevoie de o întreagă echipă. Această echipă este cea care a implementat masina virtuală, clasele, HotJava, etc. Dar, ce se întâmplă când membrilor echipei li se pare că ar putea face ceva mai mult dacă ar schimba mediul? Vă pot spune: pleacă si îsi crează propriile companii în care încearcă să-si dezvolte ideile. Nu este o cale usoară, ba mai este si plină de riscuri, dar dacă noua companie reuseste să se impună, avem de a face, mai întotdeauna, cu un salt tehnologic important.
Este exact ceea ce s-a întâmplat cu Marimba. În februarie 1996, patru membri importanti ai echipei Java s-au desprins de Sun, creând o nouă companie numită Marimba. Cei patru membrii sunt: Kim Polese (CEO), Arthur van Hoff (CTO), Jonathan Payne (Senio r Engineer), si Sami Shaio (Senior Engineer). Compania a fost făcută publică în mai si în august a devenit prima beneficiară a fondului de 100 milioane de dolari destinat dezvoltării limbajului Java de către firma „Kleiner, Perkins, Caufield and Byers“. În fine, în 7 octombrie 1996 Marimba lansează primele produse, în beta, Castanet si Bongo. Si, asa cum era de asteptat, noile produse contineau în ele germenii unei revolutii: livrarea si actualizarea asincronă, transparentă a informatiilor din Internet la domiciliul clientului. Vi se pare putin?
Appleturile Java par să ofere o alternativă de distributie a aplicatiilor. Din păcate, limitările de viteză ale retelei actuale duc la o cvasi-imposibilitate de a distribui aplicatii cu adevărat utile. Tocmai aici este cheia noilor tehnologii lansate d e Marimba: retinând trăsăturile esentiale ale appleturilor precum rularea fără o instalare anterioară sau actualizarea transparentă, aplicatiile Castanet (numite canale Castanet) încearcă să elimine o serie dintre neajunsurile appleturilor. Iată câteva dintre solutiile propuse: canalele Castanet, spre deosebire de appleturile Java, nu sunt constrânse să lucreze într-o pagină de browser, putând afisa o interfată utilizator sofisticată; canalele îsi pot salva starea pe discul utilizatorului, având în ac elasi timp si posibilitatea de a-si comunica starea înapoi către dezvoltatorii canalului; canalele sunt oglindite pe discul utilizatorului si se pot rula la viteza aplicatiilor conventionale, chiar si atunci când sistemul este deconectat de la retea. Act ualizările canalelor se execută asincron, indiferent dacă rulează canalul sau nu, si pot fi integrate imediat cum sosesc într-un canal care deja rulează.
Creatorii tehnologiei Castanet au lucrat în permanentă având în minte Internetul, asa cum este el în faza actuală. Canalele Castanet continuă să ruleze si să fie actualizate chiar si într-o retea lentă sau nesigură, cu căderi dese. Tehnologiile de distri butie a canalelor sunt foarte scalabile, crescând usor de la sute la milioane de copii, si sunt prevăzute să lucreze fără probleme chiar si în conditiile existentei zidurilor de protectie care separă retelele private de zona publică a Internetului.
Cheia tehnologiei Castanet este însă actualizarea diferentială a canalelor, adică transmiterea prin Internet doar a acelor informatii, apartinând canalelor, care s-au modificat de la ultima actualizare. Această tehnologie, descrisă mai pe larg într-o ca setă separată, a fost patentată de Marimba ca fiind un pas tehnologic complet nou.
Desi tehnologia Castanet nu depinde de limbaj în nici un fel, ea este implementată la ora actuală doar pentru aplicatii scrise în Java. Această stare de fapt se datorează faptului că Java este, la ora actuală, singurul limbaj cu adevărat portabil si prot ejat.
Sistemul Castanet se bazează pe trei componente principale: transmitătorul (transmitter), receptorul (tuner) si canalele (channels). Sună cunoscut? Este exact modelul de transmitere a informatiilor adoptat de radio sau televiziune (broadcasting). De fapt , diferenta este doar de suprafată si se estompează treptat, odată cu introducerea tehnologiilor digitale în prelucrarea sunetului si imaginii. Transmitătorul este o aplicatie, scrisă la ora actuală în Java, care rulează pe server si care transmite inf ormatiile către clienti. Clientii se numesc în acest caz receptoare si sunt aplicatii, scrise tot în Java, care rulează pe sistemele care vor să receptioneze informatia transmisă de servere/transmitătoare. În fine, canalele sunt programe împreună cu date le aferente care sunt memorate pe sistemele server pentru a fi mai apoi oglindite în mod transparent pe discurile sistemelor client. Pentru dezvoltatorii canalului, este suficient să întretină la zi copia de pe server. Mai departe, transmitătoarele si re ceptoarele lucrează împreună pentru a păstra copia canalului oglindită pe sistemul client identică cu cea memorată pe server (vezi figura "Cum functionează tehnologia Castanet").
Un canal Marimba este în realitate o colectie de fisiere care reprezintă programele si datele aferente unei aplicatii. Canalul este adus si memorat în mod transparent pe discul client de către receptor. Un canal poate fi executat în orice moment, execu tia sa făcându-se de pe discul client. În plus, dacă canalul este în executie si sosesc actualizări ale datelor sau codului, receptorul semnalează imediat aparitia acestor modificări. Canalul poate alege să ia sau nu în considerare modificările apărute imediat. Comunicatia dintre canal si transmitător este cu adevărat bidirectională, canalul primind actualizări de la transmitător dar putând în acelasi timp să transmită propriile reactii înapoi către dezvoltatorii canalului sau către alti utilizatori ai aceluiasi canal.
Actualizarea diferentială a canalelor Castanet duce la o micsorare semnificativă a traficului necesar. Această afirmatie se bazează în principal pe faptul că la distribuirea unei noi versiuni de aplicatie doar putine fisiere se modifică. Restul, colecti i de imagini, prototipuri, clase standardizate, rămâne nemodificat si nu necesită retransmitere. Gândindu-ne în special la Java, să remarcăm că aplicatiile si appleturile Java sunt constituite dintr-o colectie de fisiere de tip .CLASS de dimensiuni mic i. Actualizările duc de obicei doar la retransmiterea a câtorva astfel de fisiere .CLASS. În ceea ce priveste datele, există două posibilităti: dacă aplicatia este doar de uz local, există sansa ca fisierele de date să nu se modifice niciodată (eventual doar fisierul README sau BUGS). Dacă însă aplicatia oferă interactivitate cu reteaua (grupuri de stiri sau de dialog, distributie de oferte, etc.) atunci traficul în zona de date creste foarte mult, actualizarea canalului transformându-se, într-o mare m ăsură, în actualizarea informatiilor memorate pe calculatorul clientului si transmiterea răspunsului acestuia către alti utilizatori sau către distribuitori.
Canalele pot fi obtinute folosind o aplicatie receptor. Cu ajutorul acesteia, utilizatorul poate contacta diverse transmitătoare din retea (folosind adresa sau numele acestora) si poate obtine lista canalelor disponibile pe acele transmitătoare. Utiliz atorii se pot abona la oricare dintre canalele din listă printr-un simplu dublu-clic în fereastra receptorului sau urmând o hiperlegătură dintr-o pagină Web. În cel de-al doilea caz, browser-ul trebuie configurat în asa fel încât receptorul să fie utili zat de către navigator ca o aplicatie ajutătoare care tratează tipul MIME Ma rimba. O dată cu abonarea, utilizatorul obtine si o primă copie a fisierelor apartinând canalului, ceea ce poate lua timp mult, în functie de mărimea canalului. Vestea bună este că acesta va fi probabil singura dată când utilizatorul trebuie să astepte. În continuare, aceste fisiere vor fi actualizate în mod transparent de către receptor ori de câte ori va fi nevoie. În mod normal, receptorul este cel care initiază actualizarea la un interval bine precizat, dependent de canal, dar există si posibilitat ea ca utilizatorul să apeleze explicit actualizarea la fel ca si posibilitatea ca un canal să apeleze el însusi actualizarea. Intervalul de actualizare este specificat de dezvoltator si depinde de destinatia canalului. În cazul unor aplicatii independen te, actualizarea se va face probabil o dată pe săptămână, pentru a primi eventuale îmbunătătiri ale aplicatiei. Pe de altă parte, un canal de noutăti sau de dialog va fi actualizat la un interval de câteva minute sau ore.
Aceste actualizări sunt făcute, după cum spuneam, în mod asincron. Receptorul stă în permanentă pornit si execută actualizările indiferent dacă canalul rulează sau nu. Există si posibilitatea de a configura receptorul pentru o legătură nepermanentă cu reteaua, în asa fel încât conexiunea să fie făcută automat, la ore fixate, pentru a obtine actualizările. O astfel de facilitate este extrem de utilă celor care accesează reteaua printr-o linie dial-up, de exemplu.
În fine, copia canalului care se află pe discul utilizator poate fi lansată în orice moment, indiferent dacă conexiunea cu reteaua este activă sau nu. În cazul în care legătura este întreruptă si un canal vrea să transmită informatii înapoi către trans mitător, aceste informatii sunt memorate temporar de către receptor pentru a fi transmise la prima conectare.
Fiecare receptor are un număr unic de identificare, în asa fel încât transmitătorul să poate stii exact cu cine discută. Transmitătoarele, spre deosebire de cele radio si TV, nu initiază niciodată legătura cu un receptor. Dimpotrivă, receptoarele sunt ce le care conectează periodic transmitătoarele, cerând actualizări sau transmitând date de răspuns. Dezvoltatorii de canale Castanet pot implementa optional o componentă a canalului care rulează pe server (numită plug-in) si care va trata cererile corespu nzătoare canalului. În acest fel, canalul poate trimite un răspuns modelat după profilul receptorului care a initiat cererea. De exemplu, unele receptoare pot declara explicit că vor aplicatia într-o anumită localizare iar canalul poate memora aceast ă informatie pe server si să tină cont de ea la următoarele transmisii. În cazul în care canalul trimite date înapoi către transmitător, această componentă care rulează pe server este responsabilă cu prelucrarea datelor sosite. Tot componenta de pe server a canalului este responsabilă si cu eventualele protectii, ea putând hotărî care facilităti să fie disponibile si care nu în versiunea de canal primită de un anumit receptor, în functie de informatii comerciale sau de altă natură memorate pe server.
În ceea ce priveste receptoarele, acestea sunt construite pentru a lucra în mod tranzactional, pentru a evita posibilitatea ca fisierele unui canal să fie doar partial actualizate. În cazul în care canalul actualizat rulează deja, acesta este atentiona t de sosirea noilor fisiere. Canalul poate să instaleze imediat noile fisiere dacă stie că acestea reprezintă doar date, să ceară repornirea canalului pentru a tine cont de noile dezvoltări în partea de program, sau să ignore actualizările. În ultimul caz, receptorul va actualiza canalul numai după oprirea acestuia de către utilizator.
Spuneam mai înainte că tehnologia Castanet este scalabilă. Această scalabilitate se bazează pe existenta unor componente auxiliare precum repetoarele sau serverele de proximitate. Un repetor (repeater) este o combinatie între transmitător si receptor. Id eea de bază este aceea de a descongestiona traficul de pe transmitătoare. În clipa în care acestea sunt prea încărcate, ele pot delega activitatea relativă la o parte dintre receptoarele abonate către unul sau mai multe repetoare. Aceste repetoare se act ualizează singure de la transmitător după care trimit canalul actualizat către toate receptoarele pe care le deservesc. Actualizarea se face o singură dată de pe transmitător, în continuare receptoarele terminale primind informatia care a fost memorată de către repetor. Din punctul de vedere al receptorului, existenta unui repetor este transparentă, el transmitând în continuare cererile către transmitătorul original. Această strategie face ca transmitătorul să poată deservi un receptor chiar si dacă repetorul destinat acestuia este temporar întrerupt.
În cazul în care receptoarele stau în spatele unui zid de foc al unei retele private, problemele sunt cele legate de securitate – doar calculatoarele din interiorul zidului putând initia conexiuni –, si de performantă – străpungerea zidului fiind mult mai lentă decât o conexiune normală. În ceea ce priveste securitatea, nici o problemă: transmitătorul nu initiază niciodată o conexiune, receptorul fiind cel responsabil de aceasta. Pentru mentinerea performantei, Marimba a proiectat o aplicatie numită serverul de proximitate Castanet (Castanet proxy server). Această aplicatie stă chiar pe zidul de foc al retelei, primind toate apelurile de la receptoarele din interiorul zidului si retransmitându-le spre exterior. În acelasi timp, serverul de proximit ate păstrează si o copie a fisierelor sosite pentru a le putea oferi si unor viitori solicitanti din interiorul zidului. În cazul în care receptoarele din interiorul zidului au statut diferit relativ la acelasi canal, serverul de proximitate este cel care negociază cu transmitătorul informatia care trebuie transmisă fiecărui receptor în parte, aducând doar fisierele care diferă (vezi figura „O arhitectură Marimba completă“).
Orice applet Java poate fi transformat într-un canal chiar si fără recompilare. Singura diferentă este că parametrii appletului nu sunt memorati în fisierul HTML, ci într-un fisier text separat al canalului. Desigur, pentru a folosi cu adevărat facil itătile tehnologiei Castanet, appleturile trebuie extinse cu apeluri la clasele specifice Castanet care vin împreună cu receptorul.
Una dintre marile deosebiri dintre functionarea unui applet si cea a unui canal este aceea că appletul nu poate accesa nicicum discul utilizatorului în timp ce fiecare canal Castanet are un director special, distribuit de receptor, în care poate să scri e si să citească, să creeze directoare, etc. În acest fel, se măreste viteza de lucru si se permite functionarea canalelor si atunci când conexiunea de retea este întreruptă. Toate celelalte protectii sunt identice, de exemplu unui canal fiindu-i inte rzis accesul la un alt calculator decât cel pe care rulează transmitătorul si propriul director de pe calculatorul pe care rulează receptorul.
Marimba a publicat documentatia si sursele pentru clasele de interfată dintre canal si receptor sau transmitător precum si un număr de exemple care vin împreună cu transmitătorul. Documentatia contine separat si o sectiune despre dezvoltarea de compo nente ale canalului care rulează pe server.
Canalele Castanet pot fi, pe lîngă canale de tip applet si canale de tip aplicatie Java, canale de pagini HTML pe care vin doar pagini care se pot vizualiza cu un navigator, folosind receptorul Marimba pe post de server de proximitate (pentru a le putea vedea si off-line) si canale de tip prezentare Bongo. Bongo este un produs separat al firmei Marimba, care permite proiectarea rapidă de interfete utilizator si conectarea controalelor acestora prin scripturi Java. Prezentările Bongo pot contine un num ăr impresionant de controale si pot fi apelate si din interiorul appleturilor Java. Prezentările în sine nu sunt appleturi ci fisiere text care trebuie interpretate.
Receptorul Marimba vine cu o serie de trimiteri către transmitătoare deja instalate, printre care cel oficial de la Marimba (trans. marimba.com) si un transmitător gratuit pe care dezvoltatorii îsi pot testa si face publice canalele (trans.havefun.com) . Canalele existente sunt în general pachete de documentatii, grupuri de discutie, chat-uri, jocuri, canale de distribuire zilnică a informatiilor precum horoscopul, etc. Posibilitătile tehnologiei sunt cu mult mai mari, dar firmele importante cuplează mai lent la tehnologii noi. Totusi, pe trans.corel.com puteti obtine un beta de Corel Office for Java. Pentru o listă mai lungă de canale puteti apela la: http://www.gamelan.com/pages/Gamelan.related.channel.html
După o perioadă de stagiu beta, Castanet a fost livrat pe piată la sfârsitul lunii ianuarie. Versiunea finală foloseste JDK 1.0.2, dar surse interne de la Marimba spun că există deja o variantă internă functională care lucrează cu JDK 1.1.
În ceea ce priveste politica de preturi, un transmitător care deserveste până la 100 de receptoare unice/oră costă în jur de 1000$ în timp ce receptorul este gratuit si se poate obtine de la ftp://ftp.marimba.com/pub/release/ împreună cu o versiune limi tată a transmitătorului si a lui Bongo. Se pot cumpăra si transmitere de până la 700 de receptoare unice/oră (5.000$), 1500 de receptoare unice/oră (10.000$) sau nelimitate (25.000$). Bongo este disponibil pentru 495$.
Firme de primă mărime din lumea calculatoarelor precum Netscape, IBM, Apple sau Corel si-au anuntat deja suportul pentru noua tehnologie. Netscape a anuntat că tehnologia Castanet va sta la baza viitorului său desktop, iar Apple si IBM au anuntat că vor include receptorul Marimba în viitoarele versiuni ale sistemelor lor de operare. În fine, Corel foloseste tehnologia Marimba pentru distribuirea noului său Office pentru Java (aflat în beta deocamdată).
Microsoft a anuntat si el că va lua în curând o decizie în privinta includerii receptorului Marimba în noua versiune de Internet Explorer 4.0 care va lua locul shell-ului Windows 95/NT 4.0. De la Sun, nici o veste. Încă…
Dl. Eugen Rotariu lector universitar la Universitatea „Petru Maior“ din Târgu Mures. Poate fi contactat prin e-mail la
Actualizarea diferentială a unui canal este o tehnologie prin care traficul necesar actualizării unui canal Marimba este redus la transferul acelor fisiere care au fost modificate. Actualizarea diferentială se face printr-un mecanism de polling si nu prin unul de broadcast. Cu alte cuvinte, în loc ca transmitătorul si repetoarele să transmită continuu actualizări către receptoare (ca în cazul transmisiilor radio sau TV), receptoarele si repetoarele cer ele însele să fie actualizate atunci când est e nevoie. Mecanismele de broadcasting nu functionează foarte bine atunci când lucrează cu masini care sunt conectate la retea intermitent sau care stau în spatele zidurilor de foc ale retelelor private. În plus, mecanismul de polling permite calculato arelor portabile să initieze actualizările doar în momentul în care sunt conectate la retea.
Actualizarea diferentială este un protocol patentat de către Marimba, care lucrează în felul următor: Când un receptor cere unui transmitător o actualizare, el transmite o structură de date numită index. Un index este o structură arborescentă ale cărei n oduri corespund fisierelor din care este compus canalul. Fiecare nod care reprezintă un fisier contine o amprentă a fisierului corespunzător. Amprenta este creată rulând un algoritm MD5 peste continutul fisierului. Indiferent de lungimea fisierului, al goritmul MD5 produce o amprentă de 128 de biti. Această amprentă este un identificator foarte sigur al continutului fisierului; sansa ca diferite fisiere sau versiuni ale aceluiasi fisier să aibă amprentă identică este de ordinul lui 264. Nodurile din in dex care reprezintă directoare au o amprentă cumulativă pentru fisierele si directoarele subordonate.
Transmitătorul mentine un index paralel pentru canalele sale. Atunci când soseste o cerere de actualizare, transmitătorul compară indexul receptorului cu propriul său index si returnează fisierele ale căror noduri index nu sunt identice – cu alte cuvint e, fisierele care au fost actualizate pe transmitător de la ultima actualizare cerută de respectivul receptor. Amprentele cumulative ale directoarelor măresc foarte mult viteza de comparare; dacă amprentele pentru un director sunt identice, nu este nevoie să fie examinate amprentele subordonate. Dacă nu s-a schimbat nimic pe canalul respectiv, amprentele de pe cel mai înalt nivel se vor potrivi, comparatia terminându-se practic instantaneu.
Desi un transmitător are nevoie de indexul receptorului pentru un anumit canal pentru a-l compara cu indexul lui propriu, în fapt, receptoarele trimit foarte rar indecsi completi. În loc de acest lucru, fiecare transmitător păstrează o copie a indecsilo r primiti de la receptoare, indexată după amprentele de pe primul nivel. Într-o operatie normală, un receptor trimite unui transmitător doar amprenta de pe primul nivel a canalului. Transmitătorul scanează amprentele memorate anterior si, dacă găseste o potrivire, compară indexul corespunzător amprentei cu propriul său index. Totusi, dacă transmitătorul abia a pornit după o cădere, s-ar putea ca acel index să nu fie încă memorat. În acest caz, transmitătorul îi cere receptorului să-I trimită indexul c omplet si îl memorează în tabelele interne. În acest mod, în cazul unei operatii obisnuite, protocolul dintre receptor si transmitător lucrează la viteza unui protocol care păstrează întreaga stare a fiecărui client. Dacă este necesar, protocolul devine temporar un protocol fără păstrarea stării, pentru a se asigura faptul că pierderea accidentală a stării transmitătorului nu afectează functionarea receptoarelor.
Pentru a mări si mai mult viteza de actualizare a canalelor, întreaga conversatie dintre receptor si transmitător, inclusiv transmiterea fisierelor se face într-o singură conexiune TCP. Comparati acest mod de lucru cu transmisia normală a appleturilor, c are necesită deschiderea unei conexiuni TCP pentru fiecare fisier.
În comparatie cu transferul appleturilor, actualizarea diferentială minimizează traficul din retea. Să presupunem, de exemplu, că la fiecare oră se schimbă un fisier într-un canal si într-un applet. Actualizarea canalului necesită transmiterea unui singu r fisier în fiecare oră. Actualizarea appletului însă, necesită transmiterea fiecărui fisier folosit de utilizator, indiferent dacă fisierul a fost modificat sau nu.
(Această casetă reprezintă o adaptare a descrierii protocolului Castanet din Castanet White Paper. Marimba si-a rezervat drepturile asupra acestui protocol.)