Nu mai tzin minte cerintele din postul original. Daca ce se doreste este intr-adevar replicare a datelor atunci evident replication ofera o solutzie 'la cheie'. SQL Express are citeva restrictzii in replicare, vezi http://technet.microsoft.com/en-us/library/ms165686.aspx, dar nu e nimic care sa blocheze proiectul.

Scenariile cind multa lume foloseste replication dar nu e o replicare a datelor au citeva simptome clasice:

• datele sint scrise intr-o tabela de catre subscriber si niciodata citite. Publisher-ul le  citeste si le sterege. Acesta e un scenariu de 'data-push' pentru care Service Broker e o alegere mai buna.
• subsriber-ul scrie intr-o tabela, publisher-ul face un update la acelasi row si apoi subscriberul reactioneaza la acest update. Acest scenariu este de fapt un schimb de mesaje intre subscriber si publisher, din nou Service Broker 'face sens'
• exista diferentze majore de schema intre subscriber si publisher.
  

In cazurile de mai sus replication este folosit ca un mechanism de comunicare intre aplicatzii. De ce Service Broker este mai bun in acest caz pentru ca semantica SSB este explicit de comunicare (SEND, RECEIVE, sesiune etc) si permite developer-ului sa gindeasca in termeni de comunicatzii, nu de insert/update/delete. Sa folosesti replication in acest caz este ca si cum ai folosi in loc de sockets API un API bazat pe copiere de fisiere in share-uri.

Un alt motiv pentru care SSB poate fi preferat este daca numarul de subscriberi scapa de sub control. Pe la 200-300 de subscriberi devine practic imposibil sa mai potzi face replicare (in primul rind din punct de vedere administrare si monitorizare, apoi performantza). SSB are suport pentru a scala mult mai sus (zeci si sute de mii de clienti) prin mechanisme ca routing si forwarding (fan-in si fan-out al conexiunilor).

Upgrade-urile la aplicatzie sint un alt factor (adesea neglijat). Versiunea v+next a aplicatzie aduce schimbari ale schemei datelor, care sint replicate imediat. Totzi subscriberi trebuie sa aiba noul cod al aplicatzie, pentru ca altfel nu pot citi noua schema. Deci pentru instalarea noii versiuni, intreaga infrastructura trebuie oprita, noul cod trebuie deployat, apoi re-pornita. Cind firma a crescut si acuma sint zeci poate chiar sute de subscriberi, in locatzii geografice indepartate, aceasta procedura nu poate fi practic implementata. Tehnologia folosita (replication) devine practic a frina care blocheaza orice upgrade, sau intirzie un upgrade pentru foarte lunga durata. Suna oarecum abstract si teoretic, dar am vazut asta in practica de nenumarate ori. Soultzia este sa izolezi aplicatzia intr-un 'fiefdom' care controleaza datele si resursele proprii si comunica cu alte aplicatzii (inclusiv alte instantze ale aceleasi aplicatzii) folosind mesaje definite in contracte formale. Cu alte cuvinte, SOA. Ceea ce ma duce la urmatorul criteriu:

Conteaza de asemenea viziunea de lunga durata. Pentru cine intzelege filozofia SOA si poate sa citeasca printre rinduri in tonele de maculatura care fac confuzie intre SOA si variatele standarde XML pentru bule de sapun... SSB transforma aplicatzia intr-un serviciu, impune comunicatzii definite intr-un contract formal intre aplicatzii, izoleaza folosirea si definirea resurselor  pentru fiecare aplicatzie individual (data schema, sers and security, locks etc. etc.).

Un factor care favorizeaza replication este experientza existenta. Developerii pot sa prefere o tehnologie cu care sint mai familiari, customer-ul poate sa refuze sa faca deployment la o tehnologie noua etc etc.