Εδώ και καιρό ήθελα να ασχοληθώ και να γράψω ένα άρθρο με αυτό το θέμα.

Ένα θέμα το οποίο προσωπικά θεωρώ ότι είναι από τα καλύτερα και δυνατότερα κομμάτια του SQL Server. Με το που το είδα στον SQL Server 2005 (εδώ εμφανίστηκε για πρώτη φορά) έκανα σαν μωρό παιδί που του πήρανε καινούργιο παιχνίδι. Και αυτό γιατί όπως οι περισσότεροι γνωρίζεται είμαι στην μεριά των developers. Από το παρελθόν (21 χρόνια είμαι επαγγελματικά στο χώρο της πληροφορικής) έχω ασχοληθεί με distributed applications, queuing system, asynchronous systems programming. Οι εμπειρίες μου σε μερικές περιπτώσεις είναι τραυματικές με τέτοια συστήματα όπως επίσης και οι χιλιάδες γραμμές κώδικα που έχω γράψει για να υλοποίησω τέτοιες λύσεις. Κυρίως θα ήθελα να τονίσω ότι για να υλοποιηθούν τέτοιες λύσεις θα πρέπει να κάνεις να δουλέψουν σωστά πολλά διαφορετικά εργαλεία και τεχνολογίες.

Όταν πρωτοείδα τον Service Broker είπα μέσα μου εδώ έχει "ψωμί". Αυτό το "ψωμί" θα προσπαθήσω να το μοιραστώ μαζί σας σε περισσότερα από δύο posts (γιατί το θέμα είναι μεγάλο και δύσκολο).

Ο Service Broker είναι μια message-queuing τεχνολογία που είναι ενσωματωμένη στον SQL Server, η οποία επιτρέπει στους developers να κάνουν πλήρως intergate τον SQL Server σε distributed applications, μιας και τους παρέχει ένα asynchronous σύστημα για database to database communication. Τι σημαίνει αυτό; ‘Οτι με την χρήση του μπορείς από μια database να στείλεις μηνύματα σε μια άλλη database χωρίς να χρειάζεται να περιμένεις για reponse, πράγμα που σημαίνει ότι οι εφαρμογές θα συνεχίσουν να δουλεύουν ακόμα και όταν η δεύτερη δεν είναι διαθέσιμη.

Ο Service Broker σαν ένα καθαρόαιμο message-queuing σύστημα δουλεύει με το να στέλνει μηνυματα (messages) τα οποία περιέχουν δεδομένα σε ένα QUEUE. Τα messages παραμένουν αποθηκευμένα στο Queue μέχρι το σύστημα να έχει τα διαθέσιμα resources ώστε να τα επεξεργαστεί κάνοντας τις ενέργειες που το καθένα απαιτεί.

Έτσι με το Service Broker μπορώ να έχω καλύτερο scalability και resource management καθώς επίσης έχω και τις εγγυήσεις ότι κανένα message που έχει σταλθεί δεν θα χαθεί όπως επίσης και ότι αυτά επεξεργασθούν ακριβώς με την σειρά που μπήκαν στο queue. O Service Broker εγγυάται 100% αξιοπιστία κάτι που δύσκολα, για να μην πω καθόλου, θα το συνατήσεται σε άλλα παρόμοια συστήματα.

Στον SQL Server 2008 έγιναν μερικές σημαντικές αλλαγές κυρίως στην διαχείρiση μέσα απο Management Studio, τις οποίες θα δούμε αργότερα

Μέχρι εδώ καταλάβατε τι είναι ο Service Broker;

Πιθανές απαντήσεις

Α. ΝΑΙ, προχωράμε λοιπόν παρακάτω

Β. ΟΧΙ, ξαναδιαβάζουμε το άρθρο από την αρχή

Είμαι σίγουρος ότι πολλοί αναρωτιέστε που μπορείτε να χρησιμοποιήσετε το Service Broker. Ας δώσω μερικά παραδείγματα.

Παράδειγμα Α

Ας υποθέσουμε ότι έχουμε μια εταιρία που έχει δύο sites ( Α και Β ) όπου στο κάθε ένα έχει από μια βάση σε SQL Server. Έστω ότι έχω ένα transaction (distributed) το οποίο ξεκινάει από μια διαδικασια στην database του Α site και το οποίο ενημερώνει την τοπική database αλλα και την database στο Β site.

Στην περίπτωση που το Β site δεν είναι διαθέσιμο τι θα γίνει με το transaction αυτό;

Σωστά σκεφτήκατε θα γίνει rollback.

Όμως αν αντί να ενημερώνω το B (με την λογική του distibuted transaction) έστελνα ένα μήνυμα με την πληροφορία που θέλω να πάει στον Β Service Broker (κατά την διάρκεια του transaction στο A site ) τότε ακόμα και όταν το Β site δεν είναι διαθέσιμο το transaction το οποίο έχω ξεκινήσει στο A site θα είναι committed. Απλά το Β site θα μάθει τι θα κάνει όταν είναι ξανα στον αέρα και αφού διαβάσει τα μηνύματα που του έχουν έρθει. Εδώ θα πρέπει να επισημάνω ότι αν για οποιοδήποτε άλλο λόγο το transaction στο A site γίνει rollback και το μήνυμα το οποίο στάλθηκε στο B site θα γίνει και αυτό rollback. Μήπως θυμάται κανείς σας τι έπρεπε να κάνετε στο κοντινό παρελθόν με COM+ και Messege Queue Service;

Παράδειγμα Β

Ας υποθέσουμε ότι θέλουμε να εκτελέσουμε ένα περίπλοκο batch ή query μέσα από την εφαρμογή μας το οποίο είναι και χρονοβώρο. Θα ξεκινούσαμε την εκτέλεση και θα περιμέναμε μέχρι να τελειώσει. Φανταστήτε να γινόνταν η εκτέλεση αυτή μέσα από μια εφαρμογή. Ο χρήστης που την εκτελούσε δεν θα μπορούσε να κάνει τίποτα άλλο μέσα από την εφαρμογή μέχρι αυτή να τελειώσει. Και για να προλάβω κάποιους που θα μου πουν ότι θα το έβαζαν να τρέξει σε ξεχωριστό thread και όλα καλά, απλά να τους θυμίσω τις γραμμές κώδικα που έχουν γράψει για να το πετύχουν αυτό.

Σε αυτή την περίπτωση θα μπορούσα να στείλω ένα μήνυμα στον Service Broker και αυτός να αναλάβει την εκτέλεση του κάποια στιγμή που δεν θα υπάρχει φόρτος εργασίας.

Εννοείται βέβαια ότι δεν υπάρχει περίπτωση να χρησιμοποιήσουμε τον Service Broker όταν θέλουμε real time transactions ή θέλουμε να έχουμε άμεσες απαντήσεις. Επίσης εννοείται ότι δεν εκτελούμε SELECT σε μια remote database. Γενικά τον Service Broker τον χρησιμοποιούμε σε σενάρια όπως Asynchronous triggers, Bulk processing, Distributed order processing.

Με την παραπάνω παράγραφο στο μυαλό μας ελπίζω να σας έδωσα την πραγματική και πρακτική αξία του Service Broker. Αν πραγματικά το βρήσκετε ενδιαφέρον και προκείτε να το αξιοποιήσετε προχωρήστε παρακάτω, αλλιώς ζητώ συγνώμη για τον μέχρι τώρα χρόνο σας. ( ει, δεν θα φύγει κανείς, έχει και συνέχεια!!!)

Ποία όμως είναι η Αρχιτεκτονική του Service Broker;.

Βασικά είναι μια ξεκάθαρη client/server αρχιτεκτονική.

Ένα Service Broker application αποτελείται από ένα client service το οποίο ξεκινάει ένα διάλογο και ένα receiving service το οποίο δέχεται και επεξεργάζεται τα μηνύματα. Κάθε service αντιστοιχίζεται σε ένα queue. O συνδετικός κρίκος ανάμεσα στο service και στο queue είναι το contract το οποίο ορίζει το τύπο του μηνυματος (message) το οποίο στέλνεται από το service στο queue. H ανταλλαγή μηνυμάτων μεταξύ δύο services λέγεται conversation dialog.

Τί είναι το Service;

Το service είναι ένα endpoint για το διάλογο του Service Broker. Αυτό είτε μπορεί να είναι ένα service το οποίο ξεκινάει τον διάλογο αυτό (initiating-sending service) με την αποστολή του μηνύματος, είτε είναι ο αποδέκτης (target-receiving service), αυτό δηλαδή που λαμβάνει το μήνυμα από το queue. Κάθε service αντιστοιχίζεται σε ένα queue και σε ένα contract το οποίο ορίζει το τύπο του μηνύματος το οποίο στέλενται στο queue, διασφαλίζοντας το conversation contract.

Τί είναι το Queue;

Είναι με απλά λόγια ο κουβάς με τα μηνύματα (εντάξει δεν είναι χύμα στο κύμα αλλά επιτρέψετε μου για χάρη ευκολίας και αστείου να το λέω έτσι). Κάθε queue μπορεί να έχει αντιστιχοιθεί με πολλά services (διαφορετικά, μην ξεχνιώμαστε). Ακόμα κάθε queue μπορεί να συνδεθεί με μια stored procedure η οποία θα εκτελείται κάθε φορά που ένα νέο μήνυμα μπαίνει στον κουβά, δίνοντας μου την δυνατότητα να επεξεργάζομαι το μήνυμα άμεσα (θεικό ε;). Όμως μπορώ να έχω και διαφορετικούς τρόπους επεξεργασίας των μηνυμάτων όπως π.χ. χρησιμοποιόντας τον SQL Server Agent και τα jobs του. Επίσης κάθε queue μπορώ να το έχω active ή όχι χωρίς να πειράζω την όλη υλοποίηση μου (σαν να ήταν ένα service του λειτουργικού).

Στο σημείο αυτό θα ήθελα να δώσω μερικές χρήσιμες, πιστεύω, παρατηρήσεις για το queue.

· Εάν το sending και το receiving service είναι στο ίδιο SQL Server instance τότε μπορούν να μοιράζονται το ίδιο queue, αλλιώς διαφορετικά queues.

· Εάν το receiving queue είναι σε άλλο SQL Server instance ή δεν είναι για κάποιο λόγο ενεργό (active), το μήνυμα θα πρέπει να μπαίνει στο transmission queue για της βάσης όπου το sending service ανήκει. Αυτό ισχύει και αντίστροφα. Χρησιμοποιόντας την view sys.transmission_queue μπορούμε να δούμε τα εκκρεμή μηνύματα.

Τί είναι το Message;

Κάθε μήνυμα είναι στην ουσία μια γραμμή στο queue. To format του ορίζεται από το τύπο του μηνύματος (message type) από το contract που υπάρχει ανάμεσα σε δύο services. Μπορεί να είναι empty, well-formed XML, XML το οποίο είναι valid ως προς κάποιο σχήμα ή να περιέχει binary data.

Τί είναι το Dialog Conversation;

Αντιπροσωπεύει την ανταλλαγή των μηνυμάτων μεταξύ δύο services. Τα μηνύματα μέσα σε ένα τέτοιο διάλογο μπαίνουν στο queue με την σειρά με την οποία στάλθηκαν. Ο διάλογος σταματάει όταν κάποια από τις εφαρμογές που συμμετέχουν σε αυτόν σταματήσει την συμμετοχής της είτε εκτελώντας την END CONVERSATION εντολή είτε υπάρχει error. Εάν δεν χρησιμοποιήσουμε την παραπάνω εντολή ο διάλογος παραμένει ανοικτός στην database που ανήκει. Με την sys.conversation_endpoints μπορώ να δω τους ενεργούς διαλόγους.

Κάθε διάλογος διασφαλίζει τα παρακάτω:

1. Guaranteed delivery

Ο Service Broker είναι ένα reliable messaging system. Αυτό σημαίνει ότι ο αποστολέας του μηνύματος είναι σίγουρος ότι ο παραλήπτης θα πάρει το μήνυμα αυτό ακόμα και αν κατά την διάρκεια της αποστολής δεν είναι διαθέσιμος.

2. Long-lived

Τα dialogs συνήθως ζουν για μερικά δευτερόλεπτα, αλλα μπορούν να ζήσουν και χρόνια ολοκλήρα εφόσον έχω long-running business processes.

3. Exactly once (αυτό μου αρέσει πολύ)

Η αποστολή του μηνύματος μέσα από τον διάλογο στον Service Broker μου εγγυάται την μοναδικότητα του μηνύματος. Δηλαδή, ακόμα και αν το initiator service πρέπει να ξαναστείλει το ίδιο μήνυμα επειδή κάτι πήγε στραβά, τότε και τα δυο θα πάνε στον παραλήπτη αλλά μόνο το ένα από τα δυο θα γίνει processes. To άλλο αυτόματα θα διαγραφεί. ( ρε παιδία δεν καιρός να δούμε τον exchange server σε SQL Server database;)

4. In-order delivery

Διασφαλίζει ότι τα μηνύματα θα παραληφθούν με την ίδια σειρά που εστάλησαν.

5. Persistence

Ένας Service Broker dialog επιβιώνει μετά από restart του database server, επειδή τα messages και οι dialogs είναι persisted απευθείας στην database. Αυτό σημαίνει ότι ακόμα όλα τα l open dialogs αλλά και τα unprocessed messages είναι persisted αυτόματα και γίνονται ξανά διάθεσιμα όταν ξεκινήσει ξανά το database engine service!!!.

Τί είναι τα Conversation Groups;

Κάθε conversation group εμπεριέχει έναν ή περισσότερους διαλόγους και επιτρέπει στον Service Broker εύκολα να βρήσκει τα conversations που εμπλέκονται σε μια συγκεκριμένη εργασία. Η σημασία τους είναι τεράστια και αυτό διότι εαν πχ μια εφαρμογή στέλνει ή παίρνει ένα μηνυμα ο SQL Server κλειδώνει το group στο οποίο το μήνυμα ανήκει με σκοπό να παραγματώσει αυτό που είπαμε παραπάνω το EOIO delivery (exactly once in order).

Τί είναι το Contract;

To contract ορίζει τον τύπο του μηνύματος που το service χρησιμοποίει για να πραγματώσει την διαδικασία. Είναι η συμφωνία μεταξύ δύο services για το τι το κάθε ένα παίρνει και στέλνει στην επικοινωνία μετάξυ τους . Επίσης διασφαλίζει ότι μόνο οι τύποι των μηνυμάτων που έχουν ορισθεί στο contract θα γίνουν processes.

Τί είναι το Service Broker Endpoint;

Εάν δύο services σε ένα conversation είναι σε διαφορετικά instances του SQL Server χρειάζεται να δημιουργήσουμε ένα Service Broker endpoint το οποίο θα δέχεται τα incoming and outgoing TCP/IP connections σε συγκεκριμένη πόρτα. 'Ενα SQL Server instance μπορεί να έχει ένα και μόνο ένα Service Broker endpoint το οποίο γίνεται shared σε όλα τα services στο instance αυτό.

Τί είναι τα Remote Service Bindings;

Τα Remote Service Bindings χρησιμοποιούνται για να ορίσουμε το security context με το οποίο το initiating service συνδέεται στο remote service το οποίο είναι σε διαφορετικό instance του SQL Server. Τα Remote Service Binding χρησιμοποιούν certificate το οποίο δένεται με συγκεκριμένο database user account για να συνδεθούμε στο remote instance.

Τί είναι τα Routes;

Ο Service Broker χρησιμοποιεί τα routes για να εντοπίσει το service με το οποίο θα στείλει το μήνυμα. Εάν δεν υπάρχει κάποιο route το οποίο να είναι συνδεδεμένο με το το service τοτε by default ο Service Broker θα κάνει παράδοση του μηνύματος στο τρέχων instance. Ένα route περιέχει το όνομα του service με το οποίο γίνεται η σύνδεση, το ID του Service Broker instance το οποίο κάνει host το service, και το network address του remote Service Broker endpoint.

Εδώ λέω να σταματήσω το πρώτο μέρος. Ελπίζω το θέμα αυτό να σας αρέσει. Περιμένω τα σχόλια σας για αυτό.