JMS topic/queue μια απλή εξήγηση sort of!

Πολλές φορές προσπαθώ να εξηγήσω κάποιες τεχνικές λεπτομέρειες με ιδιαίτερα απλοϊκά και κατανοητά πράγματα. Άλλες φορές το καταφέρνω άλλες όχι. Σε αυτό το post θα κάνω μια προσπάθεια - όπως έκανα δηλαδή με έναν νέο συνάδελφο να του εξηγήσω στο context των JMS based Message Driven Beans το Topic και το Queue!

Φαντάσου οτι η εφαρμογή μας είναι σαν μια εταιρία - PapoSoft! Η οποία έχει διαφορετικά τμήματα. Αυτή η εταιρία είναι λογικό οτι κατά τη διάρκεια της ημέρας δέχεται μηνύματα (email - τηλέφωνα - επιστολές) από τον έξω κόσμο αλλά παράλληλα το κάθε τμήμα της επικοινωνεί και με τον έξω κόσμο αλλά και με άλλα τμήματα. Μια βροχή Λοιπόν, μηνυμάτων!

Σενάριο Α) Queue Είμαι ένα marketing manager από μια άλλη εταιρία και θέλω να συζητήσω το ενδεχόμενο συνεργασίας με το αντίστοιχο marketing τμήμα της PapoSoft στη λίστα με τις επαφές μου έχω το email του marketing τμήματος της Paposoft. Στέλνω το μήνυμα μου και περιμένω απάντηση! Αν ήθελα μαγικά να μοντελοποιήσω με JMS και Message Driven beans τον μηχανισμό στο τμήμα marketing της Paposoft το οποίο θα λάβει το μήνυμα μου τότε, θα είχα ένα JMS Queue (μια ουρά) στο οποίο θα καταλήγανε όλα τα μηνύματα που έρχονταν από τον έξω κόσμο. Καθώς το μήνυμα έρχεται- έχω στη διάθεση μου έναν maximum αριθμό (MDB thread pool) υπαλλήλων οι οποίοι θα προσπαθήσουν ο καθένας να ασχοληθεί με ένα μήνυμα! Άρα έρχεται το μήνυμα από τον έξω κόσμο έχω 5 διαθέσιμους υπαλλήλους αν η ουρά μου είναι άδεια και αυτό μόλις έφτασε ρίχνω τον πρώτο στη μάχη να κάτσει να διαβάσει το μήνυμα και να πράξει ανάλογα. Αν εκείνη τη στιγμή φτάσουν άλλα 2 τότε κατευθείαν ρίχνω - ΠΑΡΑΛΛΗΛΑ - τους επόμενους 2 διαθέσιμους! Αν η ουρά μου έχει πιο πολλά μηνύματα από τον αριθμό των διαθέσιμων free υπαλλήλων (Message Driven Beans) τότε περιμένουν στην ουρά! Το βασικό εδώ είναι οτι εγώ ο εξωτερικός marketing manager επέλεξα μια Point To Point επικοινωνία με την PapoSoft. Ήθελα συγκεκριμένο τμήμα. Σίγουρα δεν μπορώ να ξέρω αν το marketing τμήμα της PapoSoft έχει έναν ή 5 υπαλλήλους αλλά πάντως δεν ήθελα να επικοινωνήσω ούτε με το HR ούτε με το Management ούτε με το λογιστήριο.Όπως και η PapoSoft δε θα ήθελε υπάλληλοι από άλλα τμήματα της να χάνουν την ώρα τους με μηνύματα που δεν τους ενδιαφέρουν!

Σε γενικές γραμμές χρησιμοποιούμε ένα Queue όταν θέλουμε να πετύχουμε επικοινωνία σημείου - είμαστε σίγουροι και συγκεκριμένοι οτι ένα μήνυμα μας απ' όποιον και να σταλεί (έναν ή πολλούς) θα μπει σε μια κεντρική ουρά - και συγκεκριμένη λογική (Message Driven Bean) θα ενεργοποιηθεί για να επεξεργαστεί κάθε μήνυμα από την ουρά αυτή.

Σενάριο Β) Topic Είμαι υπάλληλος της PapoSoft, και έχω αποφασίσει οτι θέλω να παραιτηθώ! Ξέρω οτι μέσα στην PapoSoft υπάρχει ένας κοινός κώδικας επικοινωνίας και κανόνες οι οποίοι πρέπει να τηρούνται όσο αναφορά την παραίτηση μου. Ιδεατά Λοιπόν, το μήνυμα της παραίτησης μου, θα πρέπει να το μάθουν πολλά διαφορετικά τμήματα και να πράξουν ανάλογα! Θέλω Λοιπόν, να στείλω την κλασική επιστολή παραίτησης στο τμήμα management το οποίο θα με καλέσει για συζήτηση, παράλληλα το τμήμα HR με το που αντιληφθεί οτι φεύγω θα ξεκινήσει να βλέπει σιγά σιγά βιογραφικά άλλων μηχανικών για να με αντικαταστήσουν, το λογιστήριο θα ξεκινήσει διαδικασίες παραίτησης και θα μου βγάλει το υπόλοιπο των χρημάτων που θα πρέπει να πάρω. Κάθε τμήμα ενδιαφέρεται για διαφορετικούς λόγους για την παραίτηση μου και όπως είναι φανερό έχει το δικό του functionality να υλοποιήσει με το που λάβει το μήνυμα παραίτησης

Αν θα ήθελα να μοντελοποιήσω το παραπάνω - απλό σενάριο (μην μπλέξουμε με comment - ναι θα μπορούσε να υπάρχει άλλο chain λογικής κτλ) τότε θα δημιουργούσα στην εταιρία (container - εφαρμογή) ένα JMS Topic, σε αυτό το topic θα δήλωναν ενδιαφέρον να -ακούνε- για μηνύματα MDBs από διαφορετικά τμήματα.Άρα με το που στέλνω το JMS μήνυμα μου με type Παραίτηση στο Topic της PapoSoft (ενδο εταιρικά). Τότε Παράλληλα το μήνυμα αυτό γίνεται ας πούμε broadcast στους τελικούς παραλήπτες οι οποίοι είναι components από διαφορετικά τμήματα με διαφορετική λογική και θα πράξουν διαφορετικά πράγματα ο καθένας. Η λογική αυτή σε πολλά σχετικά βιβλία θα τη δείτε ως μοντέλο Publish - Subscribe! Εγώ ο υπάλληλος κάνω publish στο topic το μήνυμα της παραίτησης μου - τα διάφορα τμήματα της εταιρίας κάνουν subscribe στο topic για να ακούσουν το καθένα για τους δικούς του λόγους τι έχω να πω!

Ελπίζω να σου έδωσα μια ιδέα, και να μη σε μπέρδεψα! Η αλήθεια είναι οτι πολλές φορές δεν είναι 100% καθαρό για το τι πρέπει να χρησιμοποιήσεις και υπάρχουν άλλες φορές που και οι 2 πιθανοί μηχανισμοί ακούγονται εξίσου καλοί! Από τη δική μου εμπειρία τις πιο πολλές φορές έπεσα σε περιπτώσεις όπου ένα απλό Queue ήταν αρκετό. Αλλά αυτό δεν είναι πάντα ο κανόνας! Στο κεφάλαιο 12 του Enterprise Java Beans 3 θα βρεις μια αρκετά καλή και συγκεκριμένη εισαγωγή στο JMS+ πολλά παραδείγματα!