Chiar si numai din punct de vedere strict teoretic replication ascunde multe alte probleme, subiectul a fost pe larg tratat in urma peste zece ani de Jim Gray si Pat Helland, o lectura obligatorie este http://portal.acm.org/citation.cfm?id=233330&coll=portal&dl=ACM. Si in implementarile practice replication nu scaleaza peste sute de subscriptions in primul rind din motive operationale (mentinerea/administrarea subscriptiilor este practic imposibila).

Dar problema este mult mai fundamentala, si anuma din abordarea 'aplicatiilor distribute' ca aplicatii care share-uiesc date relationale. Modelul acesta introduce un tight-coupling care blocheaza orice proiect la scurt timp dupa darea in functionare: modificarile cer o schimbare a tuturor partenerilor implicatzi in applicatie. Daca upgrade-uri ale clientilor intr-un mediu omogen pot fi, cu greu, scoase la capat, in mediile heterogene (business-to-business si adesea intre departamentele aceluiasi business) acesta este imposibil din cauza independentei operationale a partenerilor. Cu alte cuvinte, un partener pur si simplu refuza (fundamentat!) sa upgradeze schema de date, blocind upgrade-ul intregii aplicatzii.
Un alt tight-coupling introdus de replication si adesea neglijat in proiectarea aplicatiilor este cel legat de securitatea accesului la date. Adesea se ajunge ca totzi participantzii in aplicatiza distribuita sa stie despre userii/grupurile tutror celorlatzi participantzii. Problema in general este pur si simplu ignorata la design, considerindu-se ca totzi participantzii la aplicatie apartzin la acelasi domeniu. In practica aceasta nu mai este adevarat in momentul in care aplicatia incerca sa intre in domeniul business-to-business si, din nou, adesea intre departamentele aceluiasi business.

In alta ordine de idei este destul de raspindita misconceptia in aplicatiile distribuite ca 'tranzactiile trebuiesc propagate intre parteneri'. Pentru dezvoltatori, este o solutie simpla. Si daca tranzactiile sint asa de bune pentru mediul client-server, ele nu pot decit sa fie la fel de bune si pentru mediile distribuite, nu? In realitate introducerea tranzactiilor distribuite e primul pas spre dezastru. 2-phase-commit limiteaza throughput-ul aplicatiei de la mii de tranzactii pe secunda la zeci. Pentru a functiona, aplicatia are nevoie de disponibilitatea imediata a tuturor partenerilor implicatzi in tranzactie. Un router are un hick-up de 5 secunde, aplicatzia e blocata 5 secunde (pentru ca nu poate continu pina COMMIT-ul nu intoarce controlul). Un partener in aplicatie are un crash la momentul oportun, log-ul tuturor celor implicatzi nu poate fi reciclat pina cind 2-phase-commit nu-si da acordul (si imaginatzi-va cazul cind un X lock nu poate fi eliberat din acelasi motiv!!). Ca idee generala, in momentul in care un design contzine termene ca 'linked server', 'ITransactionContext' sau '[Transaction(TransactionOption....)]' e timpul pentru a merge innapoi la 'plansa de proiectare'.

Solutziile care au avut de satisfacut cerintele de consistenta in medii distribuite si au supravietzuit in practica au totate un numitor comun: tranzactii locale si logica de compensare in applicatie pentru erori. Ceea ce introduce oarecum ideea de baza pentru aplicatiile distribuite: independenta locala. Fiecare participant in aplicatie are control asupra datelor (schema etc)/securitatzii/tranzactiilor locale si comunica cu ceilalti participanti prin intelegeri 'contractuale' (adica 'service level agreements'), implementate ca mesaje. Cu alte cuvinte, SOA. Si nu, SOA nu inseamna XML si Web Services :). Pentru o introducere in domeniu recomand din nou Pat Helland, in special Architect Webcasts: Autonomous Computing: Fiefdoms and Emissaries

Ca solutie practica cu ce exista la momentul actual pe piatza recomandarea principal este http://msdn2.microsoft.com/en-us/library/aa964144.aspx

Cei 2 centi ai mei,
~ Remus