S-a “furisat” nestiut si neanuntat de nimeni pe site-ul nostru. E vorba de Remus Rusanu un al treilea roman de peste ocean de la Redmond care ne calca pragul si intr-un mod foarte productiv ! Gandindu-ma la acest lucru am sarit speriat: nu cumva tot asa , printre noi se afla William Gates III si nu stim ! , daca e asa, vreau sa ma asigur :
”Mr. Gates, please give us a sign of your presence, I must take you an interview !”
Revenind la ale noastre ii multumim lui Remus Rusanu ca e alaturi de noi:
Gheorghe Ciubuc : Cine se ascunde in spatele contului "rremus" de pe site-ul nostru ?
Remus Rusanu : Remus Rusanu, inginer de dezvoltare software (SDE) in grupul de Storage Engine din SQL Server. Responsabilitatile mele principale sint componentele de comunicatie si securitate pentru Service Broker si Database Mirroring, dar m-am ocupat de-a lungul timpului de mai multe tehnologii si componente din SQL Server, cele mai multe fiind legate de Service Broker.
GC : Ce inseamna si ce impact are conceptul "Service Broker" in lumea software de la noi din Romania si de afara?
RR: Service Broker este rezultatul unui efort dedicat pentru a rezolva o problema grea in dezvoltarea de software: aplicatiile distribuite. Acest gen de aplicatii au nevoie sa comunice intre diverse componente si toate solutiile de success au in comun aceleasi 'pattern'-uri de cum au rezolvat problema comunicarii: mesaje schimbate prin 'cozi' care nu impun disponibilitatea simultana a partenerilor de comunicatie, eliminarea mesajelor care asteapta un raspuns (diversele forme de RPC) si inlocuirea lor cu mesaje asincrone, specificarea explicita a unui 'contract' de comunicatie, separarea canalelor de comunicatie logica de cele fizice, un minim de garantii pentru livrarea mesajelor (EOIO: Exactly Once In Order). In plus marea majoritate a acestor aplicatii distribuite sint aplicatii de baze de date: mesajele sint trimise ca rezultat al unor operatii in baza de date si receptionarea lor rezulta in operatiuni asupra unei baze de
date.Service Broker este asemanator cu un system de comunicatii prin mesaje traditional (de genul MSMQ) dar introduce un numar de inovatzii care-l plaseaza intr-o noua clasa:
· elementul de baza in Service Broker este o 'conversatie', nu un 'mesaj': o conversatie garanteaza ordinea mesajelor livrate, este bidirectionala si are specificatii clare pentru intreruperea conversatiei. Pentru cei familiarizati cu programe de comunicatii, aceasta este aceasi diferenta ca folosirea unui 'stream' TCP in locul pachetelor UPD.
· blocarea conversatiilor pentru procesare paralela ('conversation group locking'): codul care proceseaza o conversatie este garantat access exclusiv la toate mesajele acelei conversatii, usurind procesarea in paralel a conversatiilor deoarece codul nu trebuie sa se preocupe de alte processe accesind mesajele aceleasi conversatii
· integrarea in SQL Server ofera o solutie unica atit ca performata (se elimina necesitatea tranzactiilor distribuite intre baza de date si sistemul de mesaje) cit si pentru disponibilitatea mesajelor si a bazei de date (un singur produs care necesita instalare, administrare, backup/restore, failover, mirroring)
Dupa ce SQL Server a fost lansat am fost cu suprinsi de cite noi utilizari s-au gasit pentru Service Broker de catre utilizatori. Anumite functionalitati necesare pentru arhitecturile distribuite care le-am planificat initial s-au dovedit a fi foarte folositoare pentru utilizatorii SQL Server care nu erau preocupati in nici un fel de aplicatii distribuite, dar aveau nevoie de solutii la problemele lor de zi cu zi. Un exemplu
este folosirea mecanismului de activare de proceduri al Service Broker pur si simplu pentru a lansa in executie proceduri traditionale care dureaza mult, fara a bloca aplicatia asteptind ca procedura sa se termine.
GC: In ce zona de aplicatii recomandati Service Broker si in care replicare?
RR: Service Broker si replication sint solutii pentru probleme diferite. E drept ca in mod traditional replication a fost folosit pentru a comunica intre aplicatii, din lipsa unui alt mecanism: aplicatia A scrie un record intr-o tabela si aceast record 'apare', prin replication, in tabela aplicatiei B. B 'vede' record-ul, executa o actiune si raspunde prin modificarea acestui record. A 'vede' aceasta modificare si o interpreteaza ca un 'raspuns' de la B. Acesta este un mod de folosire a functionalitatilor de replicare care este mult mai bine rezolvat de Service Broker: actiunile de comunicatie sint clar separate de operatiuni asupra datelor, exista mecanisme clare de a comunicare erori, configurarea canalelor de comunicatii este explicita, se ofera o izolare a partenerilor de comunicatie A si B din punct de vedere a schemei datelor etc. Pentru aplicatiile care au nevoie de mutarea datelor (de ex. pentru a rula rapoarte pe copii ale datelor), evident replicarea este solutia cea mai indicata.
GC: Care sunt cele mai "adevarate" resurse pentru a deslusi ce inseamna Service Broker?
RR: In primul rind 'The Rational Guide To SQL Server 2005 Service Broker', de Roger Wolter. A Developer's Guide to SQL Server 2005 de Bob Beauchemin si Dan Sullivan are citeva capitole dedicate programarii Service Broker. BOL contine capitole care descriu arhitecture Service Broker si moduri de folosire: http://msdn2.microsoft.com/en-us/library/ms166125.aspx. Tot Roger Wolter a scris si un white paper dedicat acestui subiect http://msdn2.microsoft.com/en-us/library/aa964144.aspx
GC: Rivalizeaza Service Broker cu ceva similar pe lumea asta?
RR: Desi inovatiile care le-am mentionat mai sus sint unice pentru Service Broker, exista sistemele traditionale de transmitere de mesaje: IBM MQ Series, Oracle Advanced Queueing si MSMQ. Dar mutarea modelului de programare de la mesaje la conversatii este ceva unic pentru Service Broker.
GC: O intrebare deja celebra: in tara cand sunt sanse sa ne vedem, cum stati cu dorul de casa?
RR :O sa-mi petrec o scurta vacanta la sfirsitul lui decembrie in Romania.
GC: Va multumim si va asteptam la una din intalnirile Romanian SQL Server User Group.
RR: Sper si eu sa ma intilnesc cu membrii grupului!
Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)