Arhitectura Client.docx

  • Uploaded by: Adrian Secrieru
  • 0
  • 0
  • November 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Arhitectura Client.docx as PDF for free.

More details

  • Words: 2,003
  • Pages: 5
1.1.1

Arhitectura Client – Server

Tehnologiile de dezvoltare a aplicaţiilor, client-server, ne indică faptul că avem de a face cu două entităţi distincte care comunică între ele, una îndeplinind cererile celeilalte. Cele două entităţi trebuie să poată lucra separat, fie pe calculatoare distincte, fie ca două procese independente în cazul în care este disponibil un sistem de operare multiproces. Unul dintre procese, procesul server, rulează în permanenţă în gol, aşteptând să primească sarcini de executat. Un server poate în general deservi mai multe procese client fie direct, fie prin intermediul unor procese fie create câte unul pentru fiecare client în parte. Procesul server trebuie să poată să fie găsit întotdeauna la aceeaşi adresă de către clienţi (adică pe acelaşi calculator, la aceeaşi căsuţă postală), pentru ca aceştia să îi poată comunica cererile. Procesele clienţi însă, pot lansa cererile de oriunde din reţea. Desigur, între clienţi şi server trebuie să existe un limbaj comun în aşa fel încât cererile adresate serverului să poată fi uşor întelese şi rezolvate de către acesta. De multe ori, rezolvarea cererilor înseamnă returnarea unui set de date către client, selectat după dorinţele acestuia. Diferenţa nu este prea mare deocamdată, fată de arhitectura clasică de reţea, Novell de exemplu. Serverul de fişiere Novell acceptă cererile de date venite de la staţii şi le prelucrează. Să luăm exemplul unui program xBase lucrând cu fişiere memorate în reţea, şi care doreşte să prelucreze datele dintr-un fisier DBF aflat pe un server. Să presupunem că programul nu vrea să prelucreze toate întregistrările din fisierul DBF, ci doar acelea care îndeplinesc o anumită condiţie: au un câmp logic pe valoarea adevărat sau au o dată de înregistrare nu mai veche de o lună, etc. Care este soluţia clasică? Aceea de a deschide fişierul de pe server şi de a-i cere acestuia să transmită rând pe rând toate înregistrările aflate în fisier. Pe măsură ce aceste înregistrări sosesc la client, acestea sunt verificate dacă îndeplinesc condiţia dată şi, în caz de succes, sunt prelucrate. Dezavantajul unei astfel de abordări este acela că toate înregistrările, indiferent dacă îndeplinesc sau nu conditia dorită, sunt transferate către client. O idee mai bună ar fi aceea că împreună cu cererea, să-i fie comunicată serverului şi condiţia care trebuie îndeplinită de către înregistrări pentru a putea fi prelucrate. În acest caz, serverul ar putea transmite spre client doar acele înregistrări care îndeplinesc condiţia. În acest fel, traficul pe reţea este mult mai mic. În plus, clienţii (în număr mare de obicei) nu trebuie să conţină în interior algoritmi sofisticaţi de selectare a înregistrărilor care îndeplinesc o anumită condiţie. Aceşti algoritmi sunt memoraţi o singură dată, în interiorul serverului. Mai mult decât atât, datele originale sunt mereu protejate de server şi memorate în orice format consideră serverul că este mai eficient. Clienţii trebuie să cunoască doar formatul în care sosesc datele pe reţea, un format în general mult mai simplu. Acestea sunt ideile care stau la baza unei arhitecturi client-server. Clienţii comunică într-un limbaj standard cererile lor către server, iar acesta le execută indiferent dacă este vorba de cereri de selectare de date sau de actualizare a acestora. Într-un mod asemănător lucrează FoxPro atunci când lansează o cerere SQL-SELECT către un server SQL. Rezultatul cererii este memorat într-o tabelă temporară în memorie si

poate fi prelucrat în acelaşi mod ca şi o tabelă normală. Datele din memorie sunt o copie a acelora de pe server, modificarea lor duce doar opţional şi la modificarea originalelor. Limbajul SQL în sine este un limbaj standard, des utilizat pentru comunicaţia dintre un server de baze de date şi clienţii acestuia. Aplicaţia demonstrativă foloseşte o arhitectură de tip client-server pentru a selecta date dintr-un fişier de date. Comunicaţia între aplicaţii se face folosind protocolul TCP/IP. Atât serverul cât si clientul pot fi compilate sub Unix sau sub Windows. Sub Windows, este folosită implementarea de socluri TCP/IP standard, WINSOCK.DLL. Această implementare este foarte apropiată de implementarea standard BSD la nivelul interfeţei de programare. Cele mai multe apeluri de reţea sunt identice. Serverul foloseşte un anumit port TCP/IP la care îl pot căuta clienţii. Adresa Internet a calculatorului pe care rulează serverul trebuie dată ca parametru pe linia de comandă a clientului. Fişierele de date sunt păstrate în format DBF pe calculatorul pe care rulează serverul. Rutinele de lucru cu fişiere DBF sunt scrise de mine, dar spaţiul din revistă împiedică publicarea surselor lor. Funcţiile se pot compila pe DOS/Windows/Macintosh/Unix. Cunoaşterea modului de memorare a datelor este un privilegiu al aplicaţiei server. Aplicaţia client comunică serverului cererile sale printr-un soclu cu conexiune, sub formă de mesaje. Mesajele sunt de lungime variabilă, primii doi octeţi ai acestora păstrând lungimea mesajului sub formă binară.

Serverul analizează cererea şi comunică înapoi datele solicitate.

În implementarea actuală, serverul nu poate deservi decât un singur client. Motivul acestei limitări este acela că faptul nu este important deocamdată iar spaţiul în revistă limitat. O implementare care deserveşte mai mulţi clienţi este mai complicată în Windows, unde nu putem apela rutine de tip fork pentru crearea de aplicaţii. Fenomenul client/server a constituit suportul unei adevărate mutaţii în arhitectura sistemelor informaţionale, mutaţie vizibilă în prima parte a anilor '90. Prin combinarea ergonomiei de lucru specifice suprafeţelor grafice de lucru, cu un control centralizat şi unitar al datelor, s-au cristalizat o serie de avantaje: flexibilitate, scalabilitate, portabilitate, deschidere către diferite platforme de lucru etc. Într-o tentativă de definiţie ambiguă, client-server este un model de lucru în care mai multe programe autonome comunică prin schimb de mesaje. Sistemele client/server sunt sisteme informatice distribuite. Un client este un calculator care, prin intermediul unui mesaj, formulează o cerere de informaţii/servicii, cerere adresată unui alt calculator denumit server. Serverul, tot prin intermediul unui mesaj, furnizează informaţiile/serviciile clientului, întreaga operaţiune derulându-se de o manieră transparentă pentru utilizator. În general, clienţii sunt calculatoare personale (PC-uri) utilizate pentru activităţi de gestionare a datelor. Un post client se caracterizează prin faptul că: - prezintă o interfaţă utilizator care e de obicei grafică (GUI); - "formulează" interogări (cereri, consultări) sau comenzi pe care le "înaintează" serverului;

- transmite interogările/comenzile respective serverului prin intermediul unei tehnologii de comunicaţie; - analizează datele din rezultatele interogărilor/comenzilor primite de la server, iar un server prin faptul că: - furnizează un serviciu clientului; - răspunde la interogările/comenzile clientului; - ascunde detaliile sistemului client/server, făcând transparent dialogul dintre client şi server. Orice sistem distribuit este alcătuit din minimum trei componente principale: - interfaţa cu utilizatorul (sistem de operare/mediu grafic) - aplicaţia (prelucrările sau procesele) - sistemul de gestiune a bazelor de date. Toate organizaţiile din ziua de azi guvernamentale, economice şi majoritatea întreprinderilor mari şi mici recunosc rolul central pe care aplicaţiile software îl au în cadrul lor, aplicaţiile având rolul reducerii costurilor şi imbunătăţirii serviciilor faţă de competiţie. Această dezvoltare şi necesitatea utilizării pe o arie mare a unor date de interes comun a dus la apariţia, utilizarea şi proiectarea modelului Client/Server, care oferă date distribuite, portabilitate între platforme şi un acces standardizat la resurse. Termenul de Client/Server provine de la metoda tradiţională de accesare a unui computer central numit server de către computere aflate la distanţă sau clienţi într-o infrastructură de reţea. Serverele utilizează baze de date relaţionale în stocarea şi întreţinerea datelor între care există referinţe. Aceste referinţe sunt menţinute printr-o tehnologie denumită integritate referenţială (referential integrity) care oferă mecanisme care acţionează asupra datelor (trigger) şi proceduri de stocare (stored procedure). Acest model este o combinaţie a trei tehnologii: sistemul relaţional de management al bazelor de date (DBMS), reţeaua şi interfaţa client (bazată pe GUI/PC). Fiecare element contribuie în funcţionarea platformei având rolul său, dar independent în execuţia funcţiilor sale. Foarte multă lume consideră clientul şi serverul ca fiind două entităţi hardware, dar de fapt sunt entităţi software. Trebuie înteles că modelul Client/Server implică o entitate software (clientul) care efectuează cereri, acestea fiind îndeplinite de o altă entitate software (serverul). Clientul este cel ce transmite o cerere server-ului, acesta o interpretează şi apoi o efectuează. Pentru a putea îndeplini cererea serverul poate referi o sursă de informaţie (baze de date), să efectueze procesări asupra datelor, să controleze periferice sau să efectueze cereri adiţionale altor servere. În foarte multe arhitecturi, un client poate face cereri la multiple servere şi un server şi un server poate deservi mai mulţi clienţi.

Relaţia între client şi server este una de comandă/control, clientul iniţiază cererea şi serverul este cel ce o îndeplineşte transmiţând rezultatul clientului, aplicaţia fiind procesată prin divizarea ei între cele două entităţi iar transferul de date este bidirecţional. Un server nu iniţializează niciodată un dialog cu clienţii. Clientul poate funcţiona pe un server hardware şi să efectueze cereri de la un server care rulează pe un alt server hardware sau pe un PC saz clientul şi serverul pot funcţiona pe acelaşi computer. Spre deosebire de un sistem file/server în care datele sunt aduse de pe file server pentru a fi procesate pe o masină locală în acest sistem comenzile sunt transmise asupra bazelor de date localizate pe server, rezultatul fiind transmis înapoi clientului pentru a fi vizualizat. Arhitectura afectează toate aspectele software, ea trebuie să ia în considerare complexitatea aplicaţiei, nivelul de integrare şi interfaţare cerut, numărul utilizatorilor, răspundirea lor geografică natura reţelelor şi toate tipurile de tranzacţii necesare înainte de a decide tipul arhitecturii. De asemenea alegerea arhitecturii afectează timpul de dezvoltare, flexibilitatea precum şi întreţinerea aplicaţiei. La majoritatea aplicaţiilor end user se urmăreşte: prezentare, procesare şi date. Arhitecturile Client/Server definesc cum aceste trei componente sunt împărţite între entităţile software şi distribuite în reţea, există o varietate de moduri cum pot fi divizate şi implementate, utilizarea unor astfel de arhitecturi putând aduce multe beneficii în viitor companiei permiţând adaptarea la diferite standarde şi tehnologii. Câteva din caracteristicile acestei arhitecturi sunt: Centralizarea informaţiei - într-un astfel de mediu , datele sunt stocate pe un server central şi există un singur punct de control care administrează cererile aplicaţiilor şi platformelor. Aceste servere de baze de date utilizează un sistem de management al bazelor de date (DBMS) pentru a defini, stoca şi manipula date .Serverul este generic, programatorii neavând nevoie să cunoască un limbaj anume pentru a accesa date. Utilizând tehnicile de identificare o organizaţie poate creea magazii de date de la diferite servere distribuite în diferite zone geografice. Această tehnică maximizează performanţele fără a compromite modelul centralizat şi reduce probabilitatea existenţei de date redundante în aplicaţii. Serverul procesor central - preluând acest avantaj , organizaţiile pot reduce procesarea redundantă prin utilizarea procedurilor trigger şi de stocare. Server-ul este orientat în procese standard ca: menţinerea unor reguli, validări, şi referinţe de integritate, iar prin intermediul funcţiilor de stocare pe un server comun datele pot fi manipulate corect din punct de vedere logic şi viabile pentru o varietate de limbaje şi unelte ale lor. Performanţe - serverul este un computer dedicat să proceseze un set limitat de cereri de la clienţi. Singura sa funcţie este să proceseze cererile asupra bazelor sale de date. SQL oferă facilităţi eficient de utilizare a traficului în reţea deoarece doar subseturi ale datelor sunt transmise în reţea , în plus serverele şi DBMS sunt desemnate să gestioneze baze de date masive fără o degradare simţitoare a performanţelor.

Securitate - serverele ce lucrează pe platforme ca UNIX , Windows NT sau OS/2 pot oferi o mai mare securitate pentru managementul bazelor de date în comparaţie cu file server-ele standard. Mecanismele de duplexing, mirroring şi copiere permise administratorilor asigură evitarea dezastrelor, de asemenea aceste baze de date permit definirea de useri şi parole care permit evitarea accesului unor persoane neautorizate. Referitor la costurile unor astfel de arhitecturi, server-ele sunt cele ce necesită procesoare rapide, memorie, hard disc-uri mari şi un sistem de operare, clienţi care le accesează. Licenţierea, instalarea şi întreţinerea unor sisteme ca Oracle, Sybase sau Informix necesită sute de mii de dolari iar dezvoltarea unor aplicaţii necesită memorie, maşini noi şi noi sisteme de operare. Din acest motiv în prezent multe organizaţii care au utilizat mainframe- uri sau acomodat foarte uşor acestui mediu client/server care oferă o excelentă infrastructură pentru a asigura informaţie organizaţiei asigurând integritate, viteză şi securitate.

Related Documents

Arhitectura
June 2020 17
Arhitectura#
May 2020 45
Arhitectura Vernaculara01
October 2019 24
Arhitectura Client.docx
November 2019 28
Arhitectura Vernaculara
October 2019 23

More Documents from "Cuteanu"

1mru.docx
November 2019 7
1cultura.docx
November 2019 7
Arhitectura Client.docx
November 2019 28
123.docx
June 2020 26