Am postat acest mesaj în urma unei discuţii pe care am avut-o cu un coleg, referitoare la aplicaţiile distribuite (client-server sau n-tier) în legătură cu necesitatea existenţei conceptului de tranzacţii şi în lumea obiectuală (nu doar în cea relaţională): vreau să ştiu cam care sunt opiniile voastre în această direcţie, dar mai întâi iată o introducere ca să vă încălzească :).
Notă: Iniţial am postat mesajul pe RONUA dar m-am gândit că se aplică destul de bine şi aici... sorry pt. cross-site posting. Aştept comentariile însă oriunde, şi sper să le găsească şi cei ce le vor căuta ulterior. Google după titlul articolului (e identic) :)
Aplicaţiile distribuite au apărut deoarece, în unele cazuri (tot mai multe, în zilele noastre):
- datele trebuie stocate pe un server central
- interfaţa cu utilizatorul trebuie să fie disponibilă de pe alte dispozitive (printr-o reţea, fie ea locală sau Internet-ul).
De obicei aceste aplicaţii au mai multe layere dintre care le menţionez pe cele importante pt. discuţia noastră:
- data layer - de obicei o bază de date relaţională
- business layer - domeniu de obiecte (clase) şi business logic pentru acestea, cu suport suplimentar pt. data access (încărcarea din data layer, şi salvarea modificărilor înapoi în data layer)
- user interface layer - partea care afişează datele din obiectele de business pentru utilizator şi permite modificarea lor şi execuţia logicii de business la comanda utilizatorului.
Desigur, uneori există separat data access layer şi/sau un data caching layer, între data layer şi business layer, iar alteori există un nivel separat, de asemenea, între business layer şi user interface, sub formă de user services layer - dar aşa cum am spus, momentan ignorăm aceste aspecte.
Data layer-ul este de cele mai multe ori bazat pe un SGBD relaţional, precum SQL Server (sau Oracle). Restul layer-elor sunt de cele mai multe ori bazate pe un engine obiectual, precum .NET Framework.
De aceea, de cele mai multe ori, este nevoie de o transformare (mapare) a datelor relaţionale din tabelele din baza de date către clasele din domeniul obiectual (şi înapoi), lucru pe care îl pot face bine sistemele ORM (Object-Relational Mapping) disponibile azi. Deşi uneori greu de configurat, să spunem că acceptăm această situaţie, fără să ne gândim că ar trebui (în loc de asta) să folosim baze de date obiectuale (probabil din motive de performanţă?)
Totuşi, în plus, între cele două lumi - relaţional şi obiectual - există şi alte discrepanţe (care sunt naturale dacă stăm să ne gândim) şi de asemenea acceptate:
- SGBD relaţional = entităţi, relaţii, integritate, persistenţă, query-uri, tranzacţii, replicare;
- domeniu obiectual = valori, referinţe, moştenire, instanţe în memorie, serializare în stream-uri, accesare directă a proprietăţilor şi metodelor, non-tranzacţionalitate a operaţiilor efectuate.
O parte din aceste diferenţe încearcă să fie rezolvate de noile tehnologii la care Microsoft şi alţii lucrează, precum ADO .NET vNext (LINQ, Entity Data Model). Nu sunt sigur însă că aceste versiuni vor rezolva problema.
În lumea de azi distribuţia acestor layere se poate face diferit, după cum urmează (considerăm tehnic doar soluţiile bazate pe servere şi clienţi Windows, dar conceptele se aplică şi în alte direcţii):
- Thin clients: server = Data + BLL; client = UI
- aplicaţiile Web, stocate pe un server Web, şi generând interfaţa într-un limbaj intermediar (DHTML), trimis şi interpretat de un browser pe client; autentificarea utilizatorilor poate fi Windows dar şi custom
- aplicaţiile Windows disponibile prin Terminal Services (în care interfaţa se generează pe server şi e transmisă clientului la nivel de pixel/sunet fără un limbaj intermediar, clientul având doar o aplicaţie Remote Desktop (care vine în Windows XP); problema aici este faptul că autentificarea utilizatorilor trebuie să fie Windows, deci nu e o soluţie pt. proiecte pt. clienţi anonimi pe Internet, ci doar în intranet
- Rich clients: server = Data + opţional o parte din BLL (validări, logică pe server); client = BLL + UI
- aplicaţiile Windows care rulează pe client, folosind pt. BLL procesorul clientului dar accesând online un server de date (din internet sau intranet), prin servicii intermediare; autentificarea poate fi Windows dar şi custom, însă trebuie implementat un serviciu intermediar de transmitere a datelor între server data layer şi client business layer, precum .NET Remoting sau XML Web Services (modul recomandat azi)
- Un alt fel de clienţi: server = Data (+ replication publication); client = Data (+ replication subscription) + BLL + UI
- aplicaţii Windows stand-alone, care rulează pe o bază de date instalată local, pe un SGBD instalat local (poate fi o versiune "Express", de exemplu SQL Server 2005 Express); baza de date însă e configurată să se sincronizeze automat, prin replicare de tip Merge (care în SQL Server 2005 poate fi Web-based prin https) cu baza de date de pe server; aici nu prea există exemple de proiecte actuale - care chiar au fost finalizate şi sunt disponibile, sau nu ştiu eu exemple (le aştept de la voi, dacă aveţi cunoştinţă de aşa ceva): momentan nu cred că face lumea aşa probabil din motive de performanţă la nivelul replicării.
Pariul pe care l-aş face eu, este că în câţiva ani (să spunem 5-10) acest model care nu are acum nici măcar un nume bine definit (eu l-aş numi Data Replication clients, dar ar fi mai bun un nume din aceeaşi gamă cu "thin" şi "rich" - poate îi daţi voi un alt nume) va deveni un model f. utilizat (doar aşteptăm ca hardware-ul şi conexiunile Web să permită procese de data replication cât mai rapide şi programatorii să îşi revină din lumea ORM - object transactions etc, la vechile obiceiuri - fără să revină şi la vechile probleme de când aplicaţiile nu erau distribuite :)).
De ce? Păi iată avantajele: aplicaţiile client nu vor mai şti că sunt de tip distribuit; ele pot lucra cu datele stocate local, nu mai e nevoie de caching la nivel de BLL client (cache de obiecte), nici suport pt. tranzacţii pe business objects (care, apropo, nu sunt implementate decât în f. puţine framework-uri, precum CSLA .NET şi nu sunt, se pare, native în lumea obiectuală): aplicaţiile pot utiliza direct SGBD-ul şi suportul lui pt. tranzacţii pt. a executa operaţiile din UI tranzacţional, ca şi cum ar fi aplicaţii clasice (non-distribuite), şi pt. că baza de date e pe hard diskul local, va merge repede. BLL-ul va exista pt. logică nu pentru caching de obiecte (şi poate fi chiar mutat în SQL Server, fie în proceduri stocate T-SQL sau proceduri stocate .NET). Iar interfaţa va fi de cele mai multe ori sincronă, BD-ul mergând repede (ştim cu toţii câte dificultăţi avem când introducem multi-threading în aplicaţiile noastre, pt. a creşte responsivitatea UI-ului). Iar de sincronizarea clienţilor cu serverul de date (să zicem că acesta ar fi un SQL Server 2005 Enterprise, dacă pe clienţi avem SQL Server Express) se va ocupa mecanismul de replicare de tip merge, prin Web. Iar noii clienţi înregistraţi îşi vor înregistra subscripţia de replicare pe server, după care vor lucra doar local cu baza de date.
Desigur modelul se aplică doar atunci când datele necesar de afişat în UI sunt bune chiar dacă sunt puţin out-dated. Dar asta nu e oare identic când avem un cache de business objects la nivel de BLL? Aşadar aceasta nu va fi un argument prea bun împotriva acestui model...
Voi ce ziceţi? Credeţi că pariul făcut e bun sau nu?
Şi încă o întrebare: voi aţi avea curajul să alegeţi acest model azi, într-un proiect real? Cam câţi clienţi concurenţi credeţi că ar suporta SQL Server 2005 Web Replication, pe un server "bun" (cumpărat în zilele noastre)? Eu recunosc că nu le am cu preformanţa acestor procese de replicare mai ales pe Web, de aceea vă cer părerea (eu doar mă bucur că avem un model conceptual mai util decât ce aveam până acum, în sensul că programatorul va avea o viaţă mai uşoară în a crea aplicaţiile. :))