Salut Sorin,

Nu pot sa estimez daca o sa castigi pariul sau nu. Insa pot sa iti reamintesc de incercarea cu ObjectSpaces si mai nou entity data model (EDM) (Next-Generation Data Access: Making the Conceptual Level Real). Eu cred ca SOA o sa prinda si datele de orice tip vor fi consolidate intr-un spatiu comun. In plus evolutia bazelor de date este descrisa destul de bine (zic eu) de Jim Gray aici:  What's Next for Database?

Jim Gray vorbeste despre un ecosistem de informatii, despre baze de date de Petabytes etc. Merita prezentarea.

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

Am o parere care intareste ceea ce spune Remus cand recomanda in principal utilizarea Service Broker ca o solutie practica: intre servere prin SB poti schimba documente XML adica informatie semistructurata in timp ce la replicare informatia este in principal structurata - lucru dat de caracterul relational al datelor.

Pe de alta parte, in documentul de la link-ul indicat in finalul postarii, se spune

"While SSB is a database feature that can be accessed in a variety of ways from many different platforms (basically, anything that can connect to SQL Server), you can't build a Service Broker without SQL Server, and you can't run SQL Server on anything but Windows."

mai departe intreb:

Pe o masina undeva am SQL Server 2005 instalat ; este configurat Service Broker; printr-un endpoint creat pentru SOAP adica

CREATE ENDPOINT endPointName [ AUTHORIZATION login ]
[ STATE = { STARTED | STOPPED | DISABLED } ]
AS { HTTP | TCP } (
   <protocol_specific_arguments>
        )
FOR { SOAP ......

 sa inteleg ca pot, Service Broker-ul meu poate sa accepte XML-uri, sau orice alte pachete, sa spunem de pe o masina Linux cu  ORACLE sau altceva pe ea?

Stie cineva de o incercare de felul asta, reusita sau nu ?

Service Broker communica intre instantele SQL folosind un protocol binar care la momentul actual nu ests public. Ca atare SSB poate fi folosit doar ca solutie pentru commincare intre instante de SQL Server 2005 (orice SKU). Endpoint-ul de SSB nu ests SOAP, este un endpoint FOR SERVICE_BROKER (....). Nivelul de performanta dorit pt SSB (>2000 msgs/sec pt a obtine credibilitate in mediul enterprise) a eliminat din calcul varianta XML/SOAP. In plus la momentul cind SSB a fost proiectat/implementat nu existau standardele necesare W3C pt interoperatibilitate SOAP (ceea ce mai tirziu a devenit WS-Security, WS-Auth, WS-Trust, WS-ReliableMessaging, WS-Reliability, WS-Transactions etc etc, majoritatea nefiind inca definite nici acum). SSB permite transmiterea de mesaje XML ca user-payload si ofera validarea XML (well formatted sau schema).

In practica am vazut clienti care folosesc SSB ca mediu de comunicare intre server Informix! prin linked server pe o instanta SQL Express.

HTH,
~ Remus

Asa cum exista de acum "Oracle snapshot publications " sper ca in versiunile viitoare sa fie facut pasul inainte si pe directia

SSB mai ales pentru faptul ca se preconizeaza aplicatii spectaculoase la care acesta isi aduce aportul.

Revin la discutia/intrebarea ridicata de mine mai sus:

Tot cautand prin resursele indicate pe aceasta tema de dl. RRemus (multumesc mult) am dat peste ceva care, intuiesc eu ar fi un prim pas pentru  comunicarea SSB cu alte sisteme ( sa nu uitam ca un linked server inseamna o legatura directa cu masina de care te legi, adica te bagi in intimitatea acesteia !, lucru care uneori poate deranja sau deveni o poarta de intrare pentru alte lucruri)

Iata aici   ,la ExternalActivator-0.1-docs ,este un sample , citez : "This sample shows how to build a Windows Service for dynamically launching Service Broker programs as external processes. ". In concluzie poti activa SSB cu acest mecanism ca un prim pas in comunicarea cu alta aplicatie.

(In curand, voi fi in postura testarii acestei piste asa ca atunci voi avea un feed-back)

Absolut de acord, linked server introduce un 'tight-coupling' din multe puncte de vedere: availability (server-ul respectiv trebuie sa ruleze cind il accesezi), schema (trebuie sa stii exact ce catalog/tabele/proceduri treuiesc apelate pentru a realiza 'serviciul' dorit), security (trebuie sa ai un context care serverul il poate autentifica si autoriza) etc etc. L-am mentionat ca examplu de ingeniozitate din partea user-ilor.

Sample-ul de external activator arata cum se poate folosi mecanismul de 'external activation' (un 'event notification for queue_activation') pentru a lansa instante ale unui process (.exe) care sa implementeze un serviciu. Mesajele SSB sint schimbate tot intre instante de SQL Server, dar procesarea lor (implementarea serviciului) este realizata (posibil) pe o alta masina (adevarat insa ca acest proces poate sa ruleze pe orice platforma care se poate conecta la SQL Server via ODBC, JDBC, FreeTDS, SOAP etc)

Daca vrei sa descrii proiectul la care lucrezi/testezi pot sa-tzi dau un feedback mai 'la obiect'.

HTH,
~ Remus

In linii mari , iata despre ce e vorba: intre 2 parteneri se schimba date in pachete (printr-un port oarecare) modul in care se impacheteaza si apoi despacheteaza acele date este standardizat; doresc ca tratarea acestor mesaje adica receptia si trimiterea pentru mine ca partener A, sa o fac prin mecanismul SSB; nu ma intereseaza ce mecanism are partenerul B, nu intru in bucataria lui; pe mine ma intereseaza sa-i trimit si sa receptionez acele date standardizate. Daca e sa desenam arhitectura SSB cu cei 2 parteneri , sa ne imaginam ca undeva la mijloc se taie cu o linie , nu stiu ce este la celalat, insa in continuare tratez ce primesc si ce trimit.

De aceea mai devreme am avansat ideea cu SOAP: ma gandeam ca endpointul de tip SOAP este poarta de intrare pt ce vine de la/pentru partenerul B in timp ce, normal SSB , primeste/trimite prin endpoint de tip service broker. Ramane ca endpointurile sa se "inteleaga" intre ele cumva.

Ma gindeam la o descriere mai la obiect, nu generica. Ce contin pachetele? Ce este 'A'? Ce este 'B'?