Last Night JMX saved my .time!

Λοιπόν, η κατάσταση έχει ως εξής! Συνήθως (επαναλαμβάνω - συνήθως δεν είναι ο κανόνας) οι τυπικές J2EE web εφαρμογές, λειτουργούν πάνω στη λογική οτι διαθέτουν ένα κομμάτι τους το οποίο θα υλοποιεί αυτό που ονομάζουμε Business λογική, ένα άλλο κομμάτι τους το οποίο θα αναλαμβάνει να πάρει τα δεδομένα απο τον χρήστη και να τα σπρώξει στα business components και ένα τρίτο κομμάτι όπου τα δεδομένα αυτά ο συσχετισμός τους η οποια άλλη λογική διεργασία καταλήγουν στον κουβά με τα δεδομένα το repository τη βάση δεδομένων. Αυτό είναι Λοιπόν, το απλό σενάριο μιας web based j2ee εφαρμογής.

1Client----> web framework -------> Businnes Layer ---------- Database

Ο χρήστης Λοιπόν εργάζεται σε ενα συγκεκριμένο - ας το ονομάσουμε γενικά οbject model - λογικες τις οποιες του παρουσιάζουν τα client - web components. Αποτελεί την πηγή πληροφοριών για το απλοϊκό μας παράδειγμα.

Αλλά ας το κάνουμε πιο πολύπλοκο το παράδειγμα. Πολλές φορές δε φτιάχνουμε μια τόσο απλοϊκή εφαρμογή, συνηθως σε enteprise σύστημα το πάρε δώσε πληροφοριών απο διαφορετικά συστήματα την ίδια στιγμή με σκοπό να γίνει μια μοναδική λογική διεργασία είναι αρκετά σύνηθες. Τεχνολογίες επι τεχνολογιών έχουν δημιουργηθεί και άλλες πόσες θεωρίες για ορισουν τους τρόπους αλλά και τους μηχανισμους όπου θα βοηθήσουν διαφορετικά (different kind of beasts) enterprise θηρία να αλλάξουν πληροφορία μεταξύ τους, να πάρουν απο κάποια πηγή πληροφορία και να τη μετασχηματίσουν.

Μια γενική προσέγγιση στο όλο πρόβλημα ήρθαν να δώσουν τα Web Services. Ιδιαίτερα όταν τα συστήματα ήταν φτιαγμένα απο εντελώς διαφορετικές τεχνολογίες. Πράγματι, η XML over HTTP λειτούργησε και λειτουργεί ικανοποιητικά για τέτοιου είδους πάρε δώσε, η enteprise εφαρμογή γίνεται service provider και consumer πληροφορίας.

Αλλά τι γίνεται όταν τα requirements μας, μας ορίζουν να ενσωματώσουν διάφορους παράξενους μηχανισμός έτσι ώστε να δίνουν τη δυνατότητα στην εφαρμογή μας να δέχεται δεδομένα και να τα επεξεργάζεται. Δε μας αρκεί μόνο το να κανουμε consume ένα Web Service απο μια γειτονική εφαρμογή αλλά ούτε και απλά ο χρήστης να χρησιμοποιήσει το web layer μας για να μας δώσει δεδομένα.

Θέλουμε να μιλήσουμε με εφαρμογές οι οποίες έχουν ιδιαίτερες προτιμήσεις οσο αναφορά τα πρωτόκολλα επικοινωνίας, ακόμα χειρότερα θέλουμε εμείς οι ίδιοι (η εφαρμογή μας) να γίνουν το κεντρικό σημείο όπου θα προσφέρουμε μηχανισμούς επικοινωνίας και θα τους χρησιμοποιούν τρίτοι για να μας ρίξουν δεδομένα!

Το J2EE μοντέλο σε αυτή την περίπτωση έχει ορίσει έναν μηχανισμό - και framework το οποιο σου επιτρέπει να ορίσεις ευέλικτους τρόπους η container based εφαρμογή σου να παρέχει αυτές τις διόδους επικοινωνίας προς τον έξω κόσμο (αμφίδρομη επικοινωνία).

Αυτή η τεχνολογία ακούει στο όνομα Java Connector Architecture (JCA) και σχετικά πρόσφατα έχει έρθει στην έκδοση 1.5 η οποια φαντάζει ιδιαίτερα ευέλικτη, ιδιαίτερα στα σενάρια τα όποια περιγράψαμε πιο πάνω στην Business 2 Business επικοινωνία συστημάτων. Σου δίνει ορισμούς - μηχανισμούς για να κάνεις τον μηχανισμό ευέλικτο και scalable - σε ένα βαθμό προσπαθεί με τη γενικότητα της (δε θα περίμενες κάτι άλλο) να καλύψει την πολυπλοκότητα μίας πιθανής υλοποίησης.

Ωραία που είναι το πρόβλημα λες εσυ;

Ωραία η Β2Β point to point επικοινωνία αλλά τι γίνεται όταν θες να τραβήξεις το spec απο τα μαλλιά, και ναι μεν θες να παρέχεις διόδους επικοινωνίας για τη container based εφαρμογή σου αλλά δεν ταιριάζει 100% στην by the spec οδηγία του JCA.

Πχ θέλεις να μπορείς να δέχεσαι incoming XML δεδομένα over TCP όχι μόνο από μία εφαρμογή απο πολλές παράλληλα.

Η αλήθεια είναι οτι και πάλι μπορείς να πάρεις τον δρόμο του JCA ιδιαίτερα η έκδοση 1.5 αλλά κατά την ταπεινή μου άποψη είναι πολύΠΛΟΚΗ! Δεν ξέρω πόσοι απο εσάς εκεί έξω έχετε γράψει σωστούς inbound η outbound jca connectors η αλήθεια είναι οτι οι δικοί μου δε μου άρεσαν και απο ένα σημείο και μετά δεν μπορούσα να βρω τρόπους να υλοποιήσω με ευκολία ολα αυτά που ήθελα να κάνω.

Λύση JMX

Ένας απο τους λόγους που αγαπώ τον JΒοss ήταν γιατί έφερε τη χρήση (εδώ και χρόνια - σε λίγο θα το αλλάξουν φαντάσου) του JMX σε τέτοιο επίπεδο που πολλοί όταν ορίζανε το spec του δεν μπορούσαν να το φανταστούν. Τα πράγματα έχουν αλλάξει αρκετά αυτό τον καιρό και μέχρι το ίδιο το JVM το χρησιμοποιεί internally για να κάνει monitor και instrumentation κάποια πράγματα.

Εφόσον ο application server μας είναι ουσιαστικά ένας JMX server ( ή μάλλον, μέσα του ζει ένας JMX server) και πολλά απο τα components του ακόμα και τα EJB μας είναι ΜΒeans (Managed beans) γιατί να μη χρησιμοποιήσω το JMX και την ηδη έτοιμη δουλειά και μηχανισμοί).

Άρα, το να χτίσω τους δρόμους επικοινωνίας απο και προς τον container μου επιλέγω να κοτσάρω στον Container αντίστοιχα Mbeans τα όποια θα υλοποιούν ΟΤΙ ΕΓΩ γουστάρω ως μηχανισμός επικοινωνίας και με τον τρόπο που θέλω! Added value το γεγονός οτι ένα MBean είναι ουσιαστικά μέρος του Container και μπορεί να χρησιμοποιήσει εύκολα services του Container πχ JNDI , queues, Message Driven Beans Session Beans etc.

Φυσικά, το γεγονός οτι γράφεις κώδικα ο οποίος πάλι τρέχει στον container πρέπει να σε κάνει προσεκτικό με θέματα όπως το threading και παράλληλα να σεβαστείς το lifecycle το οποιο ορίζει ο container για τα Mbeans του. Υπάρχουν περιπτώσεις που σχετικά πρόχειρο development και αγνοώντας τους κανόνες που παίζει ο server να κάνεις τον μικρό αγαπημένο σου Jboss απλά να κολλήσει.

Η ουσία είναι οτι κατάφερα εύκολα, γρήγορα και ευέλικτα να επεκτείνω την εφαρμογή μου επικοινωνιακά με το να υποστηρίζω πολλαπλούς μηχανισμούς, ιδιαίτερα inbound communication κανάλια χωρίς να κουραστώ πάρα πολύ και χωρίς να χαθώ στο abstraction των εννοιών του JCA!

Αυτό το κείμενο θα είναι ένα πρόλογος για μια σύντομη παρουσίαση που θέλω να κάνω σε μελλοντικό event- ημερίδα του JHUG για τη δύναμη του JMX και το πως αρκετά εύκολα, γρήγορα και σωστά μπορείς να αυξήσεις τις δυνατότητες του container σου και της ίδιας της εφαρμογής σου.