Monday, February 12, 2007

Last Night JMX saved my...time!

log.info("heavy j2ee post");

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

Client- 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 σου και της ίδιας της εφαρμογής σου.

3 comments:

  1. Άλλος ένας που είδε το φώς :)

    Θα ήταν ωραία μία τεχνική παρουσίαση να μας πεις τις εμπειρίες σου με τα mbeans.

    Το σημείο εκκίνησης για κάποιον που θέλει να γράψει κάποιο mbean στον jboss:

    http://www.jboss.org/wiki/Wiki.jsp?page=FAQJBossJMX

    Χαιρετώ

    ReplyDelete
  2. Ενώ το JMX δεν είναι πολύπλοκο; Την τελευταία φορά που το κοίταξα ήταν ένας μηχανισμός για να φορτώνει και να διαχειρίζεται custom beans. Την ίδια δουλειά που κάνεις πολύ πιο κομψά με Spring και προχωρημένα με OSGI.

    ReplyDelete
  3. custom beans? τα MBeans σίγουρα δεν ειναι απλά beans. Είναι μέρη ολοκληρου μηχανισμού και ακολουθουν lifecycle κανονες που ορίζει ο container. Στην περίπτωση μου ειχα ηδη στην διάθεση μου έναν ισχυρό container τον Jboss, δεν βρίσκω τον λόγο γιατί να πρέπει να χρησιμοποιήσω ακόμα εναν έστω και micro για να κάνω αυτό το πράγμα.
    Ναι και το spring μπορεί να κάνει την ίδια δουλειά αλλα ο application server είναι ηδη έτοιμος για να μου προσφέρει τέτοιου ειδους υπηρεσιες.

    έχω διαβάσει αρκετά λίγα πράγματα για OSGi νομίζω οτι θα υπάρξει υποστήρικη στο μέλλον απο αρκετους vendor προς το παρόν δεν ηταν μέσα στις τεχνολογίε που έχω στην διάθεση μου.

    ReplyDelete