Aplicaţii multinivel în java/php

APLICAŢII MULTINIVEL ÎN JAVA/PHP

APLICAŢII MULTINIVEL ÎN JAVA/PHP

Cerbulescu Cătălin

[e-mail]

Obiectul aplicaţiei prezentate în cele ce urmează îl constituie achiziţia unor imagini satelit disponibile pe Internet la diverse url-uri, la intervale regulate de timp, prezentarea lor animată în browser folosind scripturi care se execută pe un server de tip ASP, PHP, JSP. Arhitectura aplicaţiei este definită pe 3 nivele: 1, achiziţia de imagini, folosind tehnologie Java, 2, un server web (PHP sau JSP) care interpretează scripturile şi 3, browser-ul.

Scopurile propuse pentru aplicaţie sunt: viteză mare de încărcare atât pentru încărcarea aplicaţiei în browser cât şi pentru rularea ei, separarea clară a celor 3 nivele astfel încât acestea să ruleze independent, prezentare care să poată semnaliza eventualele erori.

Parametrii de intrare ai aplicaţiei sunt transmişi nivelului 1 – achiziţie:

1. 
   prin valori implicite;
   
2. 
   printr-un fişier XML, în cazul în care aplicaţia porneşte fără supraveghere (la pornirea computerului);
   
3. 
   direct de către administratorul, prin interfaţa grafică a aplicaţiei.
   

Comunicarea între nivelele 1 şi 2 ale aplicaţiei, respectiv achiziţie – web server se face prin fişiere format XML.

Excepţiile aruncate de Java şi datorate erorilor de achiziţie sau manevrărilor de fişiere sunt tratate astfel încât aplicaţia să aibă capacitatea de a se auto-întreţine.

Aplicaţia rulează de circa 12 luni, în formă nemodificată, la adresa: http://193.231.39.113/munti/vremea/.
Prezentul document este structurat astfel: Modelul arhitectural de aplicaţii pe 2 nivele, pagina 1, Modelul arhitectural de aplicaţii pe 3 nivele, pagina 2, Modelul arhitectural de aplicaţii N-tier, pagina 3, Descrierea aplicaţiei. Prezentarea generală., pagina 4, Descrierea aplicaţiei. Nivel Achiziţie., pagina 6, Descrierea aplicaţiei. Nivel Server., pagina 7, Descrierea aplicaţiei. Nivel Client., pagina 7, Abordarea JSP a nivelului server, pagina 7, Posibilităţi de extindere., pagina 8, Bibliografie., pagina 8.

Modelul arhitectural de aplicaţii pe 2 nivele

Modelul aplicaţiilor Client / Server

Aplicaţiile client-server reprezintă o metodă arhitecturală care are ca scop furnizarea de informaţii, stocate pe un server, către un utilizator – client. Client/Server (C/S) este noţiunea generală prin care se face referire la acele sisteme care:

1. 
   au ca bază fizică o reţea de calculatoare şi
   
2. 
   clientul iniţiază contactul cu un program server, aflat în mod normal pe o altă maşină pentru accesarea unor funcţii specifice. Clientul se află în situaţia de solicitant al serviciilor furnizate de server.
   

Deşi termenul de C/S a fost asociat frecvent cu situaţia unui PC conectat la un server de baze de date, el face referire la modelarea logică a unei aplicaţii, în faza de proiectare astfel încât să se realizeze o diviziune clară a task-urilor în nivele, layere sau tier client / server aplica?ie stufoas? la server -->. Într-o aplicaţie tipică C/S, prezentarea datelor se face de către aplicaţia client, printr-un GUI în timp ce aplicaţia server asigură accesul la date.

Pe scală largă, arhitectura C/S este modelul cel mai răspândit şi utilizat în aplicaţii în ultimii 20 de ani. Astăzi, din ce în ce mai mult este evident faptul că ea este depăşită. Aceasta datorită necesităţii manevrării unor cantităţi din ce în ce mai mare de date dar şi a schimbărilor destul de frecvente a algoritmilor de tratare a datelor, fapt ce duce la schimbări la nivel de Server şi / sau Client.

Principial, aceasta este dilema cunoscută sub numele de ”fat client” – ”thin client” şi constă în stabilirea locului (client sau server) care execută cea mai mare parte a prelucrărilor. Pentru prelucrări executate preponderent pe server (fat server - thin client) avem:

• 
  o încărcare excesivă a serverului, acesta tratând mai puţini clienţi în unitatea de timp;
  
• 
  serverul execută, pe lângă stocarea datelor şi prelucrarea acestora;
  
• 
  o eliberare de sarcini pentru client;
  
• 
  trafic de date crescut în reţea (clientul dă comenzi, el nu execută nici o prelucrare);
  
• 
  în cazul unei aplicaţii Internet, codul pentru client are dimensiuni mici şi se încarcă foarte rapid;
  
• 
  schimbările de algoritmi se pot face doar pe Server, cu costuri reduse;
  
• 
  aplicaţiile client pot fi proiectate astfel încât să fie platform-independent.
  

Pentru prelucrări executate preponderent pe client (fat client - thin server) avem:

• 
  o încărcare excesivă a clientului;
  
• 
  serverul execută, pe lângă stocarea datelor, prelucrări minime ale acestora;
  
• 
  o eliberare de sarcini pentru server, acesta putând trata mai mulţi clienţi în unitatea de timp;
  
• 
  trafic de date redus în reţea (clientul execută operaţiile cu datele, serverul doar asigură respectivele date);
  
• 
  în cazul unei aplicaţii Internet, codul pentru client este de dimensiune mare se încarcă foarte greu;
  
• 
  schimbările de algoritmi se fac pe client, cu costuri mari, deoarece
  
• 
  aplicaţiile client nu pot fi proiectate astfel încât să fie platform-independent.
  

Aşa cum s-a arătat mai sus, limbajul de programare folosit este un alt impediment major care trebuie depăşit atunci când se proiectează aplicaţii de tip C/S. Aceasta deoarece aplicaţia client, scrisă de obicei într-un mediu vizual, trebuie să ruleze pe platforme diverse, independent de acestea. Se ajunge la situaţia în care, o aplicaţie scrisă pentru o companie este ne-utilizabilă pentru o altă.

Câteva dintre elementele importante avute în vedere la proiectarea unei aplicaţii C/S sunt:

• 
  cu cât clientului îi este mai uşor să folosească aplicaţia, cu atât mai complicată este arhitectura întregului sistem C/S;
  
• 
  serverul trebuie să fie capabil să trateze un număr foarte mare de cereri, astfel încât diminuarea performanţelor sistemului să se datoreze nu aplicaţiei în sine ci reţelei de calculatoare pe care aceasta se bazează;
  
• 
  utilizarea unei arhitecturi RMI poate fi avută în vedere la rezolvarea problemei ”fat-client”. Deja această abordare ar depăşi graniţa unei aplicaţii C/S aducându-ne în domeniul ”distributed programming” şi al arhitecturii pe 3 sau mai multe nivele.
  

Formă principială a unei arhitecturi pe 3 nivele

Modelul arhitectural de aplicaţii pe 3 nivele

Dezavantajele şi limitările aplicaţiilor de tip Client / Server, expuse mai sus, au dus la dezvoltarea unui nou concept de arhitectură a aplicaţiilor: nivelul pe 3 sau mai multe nivele.

În principiu, o aplicaţie pe mai multe nivele lasă clientul în situaţia de ”thin client”, astfel încât acest nivel, cel mai dependent de platformă, este uşor de implementat, de exemplu printr-un web browser, scris pentru o anume platformă.

Nivelul Client al aplicaţiei este responsabil de prezentarea datelor, captarea evenimentelor de la utilizator şi controlul interfeţei cu utilizatorul. Eventualii algoritmi prezenţi aici au fost mutaţi în mare parte pe următorul nivel: cel al serverului aplicaţiei. Un mod de implementare a acestui nivel constă în utilizarea appleturilor sau scripturilor client. Programatorul poate alege una dintre abordări funcţie de specificul aplicaţiei şi de avantajele / dezavantajele fiecărei abordări. Nivelul client, prezent şi în arhitectura Client / Server, a fost redus la situaţia unui ”thin-client”.

Nivelul Server Aplicaţie, nou adăugat la arhitectură, nu este prezent într-o formă explicită în modelul C/S. Acest nivel este cheia sistemului. Obiectele care implementează algoritmi sunt stocate aici. Nivelul protejează datele de a fi accesate direct de către clienţi. De asemenea, conţine componente care pot fi accesate de clienţi, la nivelul Client. După cum se observă în diagrama de mai sus CORBA, ca tehnologie de integrare a aplicaţiilor tinde să fie tot mai folosită la acest nivel.

Nivelul Stocare Date, responsabil cu stocarea datelor. Se pot folosi diverse tipuri de sisteme de la bazele de date relaţionale la cele ne-relaţionale.

Graniţele dintre nivele sunt logice, nu fizice, ele putând rula pe aceeaşi maşină. Condiţia este ca sistemul să fie bine structurat iar graniţele fiecărui nivel bine definite şi reprezentate practic de interfeţele obiectelor componente. Acestea sunt impuse de managerul sistemului funcţie de condiţiile specifice fiecărei aplicaţii.

Avantajele folosirii arhitecturilor pe 3 nivele:

1. 
   separare clară a celor 3 nivele. Prin această separare mai mulţi clienţi au acces la o mare varietate de aplicaţii server. Principalele avantaje pentru aplicaţiile client sunt: dezvoltare rapidă prin re-utilizarea componentelor de algoritmi şi o fază de testare mai scurtă deoarece componentele server au fost deja testate;
   
2. 
   redefinirea strategiei de stocare a datelor nu afectează clientul, acesta accesând datele printr-o interfaţă bine proiectată care încapsulează toate detaliile de stocare;
   
3. 
   obiectele care manevrează algoritmi de prelucrare a datelor trebuie să fie cât mai aproape fizic de mediul de stocare a datelor, ideal, pe aceeaşi maşină. În acest fel este redusă încărcarea reţelei deoarece aceasta este zona de trafic intens;
   
4. 
   în contrast cu modelul C/S în care doar datele erau accesibile publicului, acum publicul are acces la servicii;
   
5. 
   serverele fiind sisteme mai sigure, protecţia şi securitatea datelor sunt mai simplu de obţinut şi întreţinut. Totuşi, fiind vorba practic de aplicaţii distribuite, protecţia datelor şi controlul accesului sunt elemente importante. Într-o formă simplă, nivel 0 de securitate, acestea sunt: autentificarea, autorizarea şi criptarea;
   
6. 
   relativ la upgrade-ul sistemului, este mai uşor să schimbi o componentă soft pe server decât de a furniza numeroşilor clienţi versiuni noi ale programului.
   

Arhitectură pentru aplicaţii Web pe 3 nivele utilizând XML

XML-ul oferă o soluţie robustă pentru aplicaţiile pe 3 nivele, aşa cum se observă din diagrama de mai sus. Datele, stocate într-o formă oarecare sunt convertite la format XML, preluate de serverul Web, prelucrate de acesta (de ex printr-un query) şi transmise clientului sub formă de ”data island”, documente XML în pagini HTML. Avantajul soluţiei este evident atunci când pentru client se foloseşte un browser care are capacitatea de a manevra XML, de exemplu prin scripturi client. După cum se observă, la graniţa dintre nivele datele circulă doar în format XML.

Modelul arhitectural de aplicaţii N-tier

Aplicaţiile distribuite N-Tier se referă la folosirea oricărui număr de combinaţii între nivele Hardware şi/sau nivele Software cu scopul de a furniza o colecţie modularizată de servicii de informaţii. Pot exista astfel nivele de: client, interfaţă, agent, tranzacţie, servere de date etc. De asemenea, aceste nivele operează ca unităţi logice, pe aceeaşi maşină sau pe un număr oarecare de maşini, acest lucru ducând la o flexibilitate şi scalabilitate crescute ale sistemului.

O astfel de abordare a unei aplicaţii permite:

• 
  o tot mai mare parte a aplicaţiei este eliminată din partea clientului, ducând astfel la situaţia unui ”thin client”;
  
• 
  depărtarea clientului de date şi prelucrarea lor;
  
• 
  nivelul client are ca sarcină doar manevrarea interfeţei grafice cu utilizatorul;
  

• 
  integrarea diverselor colecţii de resurse într-un sistem unic.
  

Aplicaţiile distribuite N-Tier pot fi create folosind o largă varietate de limbaje de programare, sisteme de operare şi platforme.

Scopul unei asemenea arhitecturi este acela de a permite fiecărui nivel al aplicaţiei să fie dezvoltat, dirijat, instalat, extins, absolut independent de celelalte nivele.

Java, ca limbaj şi maşină virtuală, este un nou tip de client în sistemele pe 2 sau mai multe nivele. Deoarece noul client poate rula pe orice computer şi sistem de operare, software-ul începe să fie scris nu pentru aplicaţii pe 2 sau 3 nivele ci pentru N nivele.

Descrierea aplicaţiei. Prezentarea generală.

Ideea care a stat la baza aplicaţiei a fost obţinerea unor imagini furnizate de diverse site-uri şi găsirea unei modalităţi de vizualizare a evoluţiei în timp a acestora. Fiind vorba de imagini satelit referitoare la formaţiuni noroase şi fronturi atmosferice era evident că numai o imagine la un moment dat nu era foarte relevantă. Mult mai importantă şi cu relevanţă mai mare era să putem vedea evoluţia imaginilor printr-un număr de 4-10 imagini luate la intervale constante de 3-12 ore. Putem astfel, având oarecare cunoştinţe de meteorologie, să anticipăm vremea cu destul de multă precizie.

Aplicaţia rulează în formă neschimbată de circa 12 luni la adresa http://193.231.39.113/munti/vremea/. Alternative la astfel de serviciu nu existau practic la data inaugurării, într-o pagină web putând doar include url-uri ale imaginilor satelit luate la un moment dat.

Aplicaţia se prezintă sub forma a 3 nivele distincte, aşa cum este descris şi în diagrama de mai jos:

Nivel 1, achiziţia de imagini de la url-uri diverse la intervale regulate de timp;

Nivel 2, un server web care furnizează pagini în format HTML. Este instalat pe aceeaşi maşină ca şi nivelul 1 dar rulează independent de el;

Arhitectura aplicaţiei cu nivelele aferente: Achiziţie – Server - Client

Nivel 3, clientul, un browser oarecare, aplicaţia fiind proiectată să ruleze atât pe Internet Explorer, diverse versiuni cât şi pe Netscape, versiuni mai mari de 4.

Nivelul de achiziţie a imaginilor a fost adăugat la o aplicaţie iniţială client server tipică: un server Apache / PHP / MySql şi un browser – client oarecare. După o perioadă a apărut nevoia de a aduce facilităţi noi de natura urmăririi evoluţiei unor imagini de la diverse url-uri.

Nivelul Achiziţie s-a adăugat independent de celelalte, respectivul nivel stocând imaginile preluate de pe Internet la adrese fizice. Pe nivelul Server s-a adăugat încă un folder (/vremea) care nu afecta funcţionarea restului aplicaţiei. Index-ul folderului este cel care asigură încărcarea imaginilor prin url şi inserarea unor secvenţe de script client care generau o animaţie simplă. Nivelul client a fost, evident, nemodificat.

Diagrama unei aplicaţii de achiziţie de imagini / expunerea acestor imagini de către un Web Server în nivelul Client, printr-o animaţie simplă

Caracteristicile aplicaţiei sunt:

• 
  delimitare fermă a celor 3 nivele, deşi ele rulează pe aceeaşi maşină;
  
• 
  capacitate de a rula şi / sau trata erori fără intervenţie exterioară;
  
• 
  efort minim de întreţinere şi / sau upgrade;
  
• 
  schimbarea surselor de achiziţie se poate face uşor, doar la nivelul Achiziţie, prin adăugarea / modificarea valorilor unor elemente dintr-un fişier XML. Celelalte nivele nu au nici o legătură cu sursa datelor astfel încât schimbarea acestora nu le afectează;
  
• 
  aplicaţia este independentă de platformă ca efect a utilizării unor servere independente de platformă (Apache, PHP, Tomcat) şi Java pentru achiziţie;
  
• 
  poate fi lansată prin simpla pornire a computerului, fără să fie nevoie de prezenţa unei persoane autorizate.
  

O diagramă detaliată a aplicaţiei este prezentată mai sus. Din diagramă se observă că sarcina administratorului aplicaţiei (şi nu a proiectantului !) este eventual de a modifica parametrii acesteia. Parametrii aplicaţiei, daţi curent printr-un fişier XML, sunt de fapt parametrii nivelului Achiziţie: elemente XML cu url-urile resurselor, locaţia folderului de lucru (calea fizică unde se vor descărca imaginile preluate), numărul slide-uri necesare animaţiei şi intervalul orar măsurat în ore sau, pentru teste, în minute. Diferenţierea se face tot printr-un element XML. Toţi parametrii descrişi mai sus pot fi preluaţi prin GUI-ul aplicaţiei sau implicit.






< configuratie >



http://www.euronews.net/images/weather/europe_satellite_latest.jpg

http://www.euronews.net/images/weather/europe_fronts_tod.jpg

http://image.weather.com/images/sat/europesat_277x187.jpg

http://maps.weather.com/images/sat/europesat_720x486.jpg

http://www.usatoday.com/weather/satpic/photos/europe.jpg

http://localhost/poze/europe_satellite_latest.jpg

http://localhost/poze/europe_fronts_tod.jpg

http://localhost/poze/europesat_277x187.jpg



c:\wwwroot\munti\vremea\

6

6

no



Formatul fişierului XML de intrare este următorul:

Transferul parametrilor între Achiziţie şi Web Server se face prin 2 fişiere XML. Primul cuprinzând parametrii: numele asociate url-urilor (de fapt, numele fişierelor, fără cale), numărul de slide-uri, locaţia de descărcare, intervalul orar se creează la lansarea aplicaţiei, al doilea, cuprinzând timpul ultimei actualizări, se creează de către nivelul Achiziţie după fiecare actualizare reuşită de imagini.

Exemple de fişiere:

Tab-urile Adrese Web şi Parametrii.

europe_fronts_tod europe_satellite_latest europesat_277x187 6 6

Sat Jul 13 22:02:54 EEST 2002

Descrierea aplicaţiei. Nivel Achiziţie.

Realizat integral în tehnologie Java, nivelul Achiziţie este primul pas din seria de upgrade-uri ale site-ului.

GUI-ul aplicaţiei este structurat simplu, pe Tab-uri. Primele două Tab-uri, Adrese Web şi Parametrii permit modificarea parametrilor de start ai aplicaţiei, descrişi anterior. Parametrii primesc automat valori implicite iar modificarea lor se poate face intuitiv. Din motive care vor fi explicate ulterior, la lansarea automată a aplicaţie, s-au utilizat doar 3 url-uri de imagini. Administratorul poate opta pentru mai multe sau mai puţine, folosind butoanele: Activează URL respectiv dezactivează URL. Fişierul XML de intrare conţine o listă de URL-uri. La încărcarea GUI-ului, toate url-urile sunt încărcate în JCombobox-urile tab-ului cu diferenţa că primul url este implicit selectat în primul JCombobox, al doilea url este implicit selectat în al doilea JCombobox etc. Activarea / dezactivarea unui nou url produce activarea / dezactivarea următorului JCombobox, în ordinea firească.

Tab-ul Mesaje

În tab-ul Parametrii se comunică ceilalţi parametrii de start ai aplicaţiei: numărul de slide-uri, locaţia de descărcare, intervalul orar.

Mesajele din partea aplicaţiei sunt depuse în tab-ul Mesaje şi cuprind timpul lansării aplicaţiei, mesaje referitoare la rezultatul ultimei încercări de a descărca imagini şi timpul scurs de la lansare.

Deoarece se dorea achiziţia de imagini de la mai mult de 1 url, s-a adoptat soluţia utilizării Thread-urilor. Fiecare încărcare de url este lansată ca fir separat de execuţie. Toate firele de execuţie au aceeaşi prioritate fiind lansate la acelaşi moment de timp, momentul încheierii lor putând fi diferit. Această abordare m-a făcut să limitez adresele implicite la 3 pentru a nu bloca maşina server în momentul lansării thread-urilor dar şi pentru a evita încărcarea în browser a unui număr de imagini mai mare de 3 thread-uri x 6 slide-uri.

Fiecare fir de execuţie se poate încheia atunci când:

• 
  transferul de date a reuşit (caz în care se face şi actualizare a fişierelor);
  
• 
  după un număr de 6 încercări, transferul de date nu a reuşit (nu se face actualizare a fişierelor).
  

În ambele situaţii aplicaţia continuă să ruleze, în tab-ul Mesaje adăugându-se un mesaj corespunzător.

Deoarece operaţiile cu fişiere XML sunt simple, aplicaţia Java are clase proprii care expun prin interfaţă operaţiile comune de creare, deschidere fişiere şi extragere, adăugare tag-uri.

Toate excepţiile importanta aruncate de aplicaţie, referitoare la: încărcarea datelor de la url-uri, actualizarea listei de fişiere au fost prinse şi tratate corespunzător astfel încât clientul să nu fie afectat de informaţii eronate ci cel mult de informaţii neactualizate.

Acest nivel este nivelul cheie al întregii aplicaţii. Dacă acesta îşi încetează activitatea, restul nivelelor vor afişa date dar acestea vor fi eronate. Pornirea automată se face prin executarea unui .bat şi a jar-ului aferent aplicaţiei Java, cu parametrul /start pentru linia de comandă.

Descrierea aplicaţiei. Nivel Server.

Combinaţia utilizată pentru nivelul server trebuie să permită rularea unor scripturi server. S-a utilizat combinaţia Apache / PHP / pagini PHP pentru că, aşa cum am arătat, aplicaţia s-a dezvoltat pe un asemenea suport client / server. Alternativa Apache / Tomcat / pagini JSP este la fel de bună, probabil cu o viteză de răspuns mai mică pe platforme Windows.

Operaţia de bază a scripturilor server este aceea de a prelua din fişierul XML numele fizice ale fişierelor descărcate de către nivelul Achiziţie şi de a le transforma în url-uri locale. Astfel, de exemplu, ultimul url descărcat: http://www.euronews.net/images/weather/europe_fronts_tod.jpg se transformă în imagini/downloaded/ europe_fronts_tod0.jpg. Url-ul descărcat la faza anterioară de achiziţie va fi în imagini/downloaded/ europe_fronts_tod1.jpg şi aşa mai departe.

Acelaşi nivel va genera pagina în format HTML care va fi încărcată în browser şi va cuprinde scripturile client utilizate la animaţie.

Descrierea aplicaţiei. Nivel Client.

Nivel Client este un browser oarecare, aplicaţia fiind proiectată să ruleze atât pe Internet Explorer, diverse versiuni cât şi pe Netscape, versiuni mai mari de 4. Sub Explorer informaţiile suplimentare (timpul la care au fost preluate imaginile) sunt mai uşor de urmărit.

În browser se preîncarcă toate imaginile necesare, astfel încât practic, după încărcarea paginii, comunicaţia cu web serverul încetează.

Prin interfaţa grafică, scrisă în JavaScript, clientul poate porni sau opri animaţia, afişa pe rând fiecare slide cu butoane de Forward şi Rewind sau se poate bloca o imagine ne-importantă pentru user. Se poate, de asemenea, accesa doar un anumit set de imagini din cele disponibile, corespunzător unui anumit moment al achiziţiei.

Abordarea JSP a nivelului server.

Soluţia JSP a nivelului server Web (index.jsp, disponibilă la http://193.231.39.113:8080/vremea/) a fost implementată în vederea omogenizării aplicaţiei. S-a dorit trecerea în timp, pe acest nivel, de la setul: Apache/Php/MySql/TomCat la TomCat. Rezultatul grefării paginii JSP pe ansamblul nivelului server Apache/Php/MySql nu este foarte bun deoarece au rezultat probleme destul de mari legate de configurarea serverului TomCat. Dificultăţile se datorează faptului că index.jsp trebuia să se afle în acelaşi folder cu index.php pentru că ambele accesează, la rândul lor, imagini arhivă din imagini\downloaded\arhiva şi fişierul vremea.xml. Nu s-a reuşit, prin configurarea contextelor din TomCat, o bună structurare a folderelor, de genul variantă PHP într-un folder, varianta JSP, cu index.jsp, Meta-inf şi Web-inf într-un alt folder, nici măcar descendent din primul.

Pagina JSP foloseşte o componentă bean, dezvoltată pentru tratarea unui fişier .XML simplu. Acesta este varianta funcţiei PHP scrisă pentru a prelua date din acelaşi fişier .XML.

În concluzie, s-au constat următoarele aspecte:

• 
  dacă nivelul server rulează doar TomCat-ul, pagina JSP se comportă foarte bine deşi se încărca oarecum mai încet decât varianta PHP;
  
• 
  dacă nivelul server rulează Apache/Php/MySql/TomCat, pe platformă W98, TomCat-ul poate raporta erori care semnifică faptul că nu poate servi anumite fişiere JPG din folderul imagini/downloaded. Imaginile sunt totuşi încărcate în browser şi pagina JSP funcţionează corect la nivel de user. Pe platformă W2000, erorile de mai sus nu apar.
  

Alternative.

În faza de proiectare a aplicaţiei m-am confruntat cu următoarele dileme legate de animaţie:

• 
  imaginile descărcate puteau fi afişate, printr-o programare mai comodă şi un GUI mai atrăgător, folosind un applet. Aceasta ducea însă la trafic crescut în reţea datorită încărcării suplimentare, pe lângă imagini, a claselor;
  
• 
  imaginile descărcate ar fi putut fi transformate, la nivelul Achiziţie sau Server în Gif-uri animate. Soluţie interesantă dar care elimina complet posibilitatea controlului animaţiei.
  

O altă alternativă la proiectare a fost aceea de a utiliza componente distribuite, transferând nivelul Achiziţie pe o altă maşină. Am considerat că soluţia nu este necesară deoarece maşina pe care rula aplicaţia nu era atât de solicitată. Pe de o parte, există un număr mediu de 2-3 conectări / zi, clienţi relativ constanţi iar pe de altă parte, transferul datelor de pe o maşină pe alta ar fi însemnat complicaţii legate de transfer de date în reţea: ftp, share pe anumite foldere sau alte soluţii.

Ideal ar fi fost ca utilizatorul să-şi poată alege sursa imaginilor prin utilizarea în browser a unei forme şi a unor scripturi server. Opţiunea este uşor realizabilă dpdv. al programării, ea fiind oarecum integrată în prezenta abordare. Dificultăţile apar însă dintr-o altă direcţie şi anume: odată cu selectarea unei surse trebuie să fie disponibile un număr de imagini anterioare provenite de la acea sursă, în caz contrar animarea imaginilor nu are sens. Rezolvarea acestor probleme s-ar putea face:

1. 
   configurând aplicaţia să descarce în permanenţă imagini de la un set de url-uri, set din care utilizatorul îşi poate selecta imaginile sursă pentru animaţie sau
   
2. 
   construind un profil personal al utilizatorului.
   

La circa 3 luni de la instalare, unul dintre site-urile care furnizau imagini satelit preluate de aplicaţia descrisă mai sus, a introdus un applet care realizează acelaşi tip de animaţie, folosind doar imagini satelit ale formaţiunilor noroase.

Aşa cum am arătat, aplicaţia descrisă mai sus poate afişa în browser imagini animate provenind din orice sursă.

Posibilităţi de extindere.

Experienţa în utilizarea aplicaţiei a arătat că unele dintre site-urile a căror imagini sunt exploatate nu fac upgrad-uri ale imaginilor la intervale regulate de timp. Astfel, pentru imagini luate la 6 ore, există frecvent situaţia în care 2 imagini consecutive sunt identice. Pe de altă parte, la intervale de 12 ore, imaginile consecutive vor fi diferite dar se pierde un upgrade de imagine. Există astfel soluţia ca aplicaţia descrisă să facă download-uri la fiecare 6 ore şi apoi să analizeze conţinutul downloadat. Dacă este diferit de ultima imagine captată, este păstrată şi lista de imagini actualizată. Dacă este identică, fişierul descărcat este şters şi lista ne-actualizată.

Ca şi posibilităţi de extindere este evident faptul că aplicaţia se poate modifica, la nivelele achiziţie şi script server astfel încât să poată prelua text, în aceleaşi condiţii, din surse Internet. Mediul de transmitere între nivele este XML. Dificultăţile care ar putea să apară la această abordare constau în faptul că textul preluat trebuie să fie prelucrat şi / sau interpretat, fapt care implică doar un efort de analiză – parsare a resursei obţinute.

O aplicaţie de tip Client/Server care realizează o parte din cele propuse mai sus rulează la: http://193.231.39.113:8080/stareavremii/. Comunicarea de date între nivele se face prin intermediul unor fişiere XML.

Bibliografie.

1. 
   Bruce Eckel, Thinking in Java, 2nd Edition, Release 11, To be published by Prentice-Hall mid-June, 2000
   
2. 
   Creating a Three-Tier Web Site, MSDN Library, january 2000
   
3. 
   N-Tier Development Model, MSDN Library, january 2000
   
4. 
   The N-Tier Revolution, www.n-tier.com
   

- -