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 –