Conexinea este refolosita pentru tot traficul de Broker intre cele doua instante de SQL Server. Conexiunile se inchid automat dupa o perioada de inactivitate.

Pentru securizarea conversatziilor trebuie sa ne gindim ca exista doua puncte de vedere: aplicatzia cere ca sa existe securitate (o decizie care se stie in momentul in care se scrie codul aplicatziei) sau aplicatzia nu cere securitate dar 'deployment'-ul cere securitate (o decizie care nu este cunoscuta la momentul scrierii codului aplicatziei ci depinde de administrarea unui 'deployment' al aplicatziei).

Cind o aplicatzie cere securitate specifica in codul ei prin folosirea optiunii WITH ENCRYPTION = ON la verbul BEGIN DIALOG. Daca aceasta optiune este folosita, situl unde aplicatatia a fost instalat trebuie sa configureze securitatea (folosind REMOTE SERVICE BINDING).

Cind aplicatia nu cere securitate, atunci trebuie sa specifice WITH ENCRYPTION = OFF. In acest caz administratorul sitului aplicatziei are optiunea sa lase conversatziile fara securitate sau sa impuna securitatea (creeind un REMOTE SERVICE BINDING).

Aceleasi lucruri le-am descris si in blogul meu mai demult: http://blogs.msdn.com/remusrusanu/archive/2006/07/07/with-encryption-off-is-the-conversation-encrypted-or-not.aspx

Deci cind scrii o aplicatie e recomandata totdeauna sa folosesti WITH ENCRYPTION = OFF daca securitatea nu este ceruta, lasind administratorului sitului unde aplicatzia ruleaza sa aleaga daca instaleaza sau nu securitate.

 Despre ce sint si la ce folosesc REMOTE SERVICE BINDING (RSB) ele au rolul sa asocieze un serviciu remote (deci doar un nume de serviciu, un string, nu un obiect in baza de date locala) cu un 'database principal' (un user). Prin aceasta se declara ca mesajele sint trimise acelui user specificat in RSB. Folosind principiile criptografiei cu cheie publica, daca vrei sa trimitzi un mesaj care sa poata fi citit doar de un anumit user trebuie sa incriptezi mesajul folosind cheia lui publica, pentru ca numai el il poate decripta folosind cheia sa privata corespunzatoare. De aceea user-ul specificat in RSB trebuie sa posede un certificat care va fi folosit ca sa se incripteze mesajul si acest certificat trebuie sa fie obtiut prin importul certificatului folosit de owner-ul serviciului destinatie. Pe baza acelorasi principii ale criptografiei cu cheie publica cineva poate semna un mesaj folosind o cheie privata pentru ca oricine sa poata verifica semnatura folosind cheia publica. In cazul conversatiilor Service Broker user-ul care este owner-ul serviciului initiator trebuie sa posede un certificat care va fi folosit pentru a semna mesajele. Pentru ca mesajele sint semnate cu acest certificat, serviciul target poate folosi aceasta semnatura ca sa autentifice user-ul care a trimis mesajul (owner-ul certificatului importat in baza de date target) si acest user poate fi autorizat (SEND permission).