EJB 3.1 τι έρχεται - σχόλια απο το JavaOne 2007!

Ήθελα να γράψω ένα συνολικό post για τις παρουσιάσεις τις οποίες είδα στο JavaOne και τα δικά μου σχόλια! Δυστυχώς δεν μπορώ να κάτσω να γράψω ολόκληρο κατεβατό οπότε νομίζω θα γράψω ανά κατηγορία. Ένας τομέας που με απασχόλησε και σαν συμμετέχοντα στο JavaOne αλλά και ως επαγγελματία είναι η εξέλιξη του EJB 3.0 specification στο 3.1 αλλά και το JPA. Με κάποια εμπειρία στο EJB 2.1 και τωρινή εμπειρία από το project στο οποίο απασχολούμαι με το EJB 3.0 έχω δηλώσει αρκετές φορές οτι το νεο standard 3.x είναι απο τις επιτυχημένες εξελίξεις στον κόσμο της Enterprise Java, ιδιαίτερα με την προσθήκη του JPA (έστω και αν το spec για την ώρα είναι κουτσό - Criteria API γαμω το @#$23 μου!) .Κάποιος εξαιρετικά εύστοχα σε ένα blog είπε - _JPA 2.0 of tomorrow is Hibernate 3.x of today'!)

Αυτά που κράτησα για το επερχόμενο standard είναι (θα χρησιμοποιήσω μερικά points από την λίστα του Adam Bien από το αυτό το post - τον οποίο έτυχε να γνωρίσω και απο κοντά):

• νέο packaging enterprise εφαρμογών, θα μπορείς να πακετάρεις το τα (SB) EJB σου μέσα στο war!Ένα βήμα πιο κοντά στην απλότητα!
• To @Local είναι optional το οποίο ήταν καιρός πια οι application server να μας παρέχουν αυτή την ευελιξία - άσε που ακόμα αρκετός κόσμος μπερδεύεται για το τι να βάλει. Υπάρχουν συζητήσεις εδώ και χρόνια για το πως ο κάθε application server μπορεί με λίγο magic on the background να καταλαβαίνει αν η κληση γίνεται μέσα από το ίδιο VM η κάποιο άλλο για να αποφύγει το serialization, άσχετα με το πως έχεις μαρκάρει εσυ τα EJB σου- παρόλα αυτά προσωπικά την έχω - έχουμε πάθει μια φορά στον JBoss σε συγκεκριμένο release που ένα συγκεκριμένο switch δεν ήταν on και there was no magic! Μερικοί ex- συνάδελφοι που με διαβάζουν ίσως θυμηθούν!
• Singleton Beans : Λοιπόν, θα πει κάποιος καλά και γιατί να θέλουμε Singleton EJB παρόλα αυτά υπάρχουν μερικές φορές που θα ήθελες να έχεις ένα τέτοιο - per application context. Η αλήθεια είναι οτι το Singleton pattern στα πρώτα revision του EJB spec ήταν κάτι το οποίο δεν πρέπει να αγγίξεις- οι καιροί αλλάζουν και σίγουρα αν δεν κακό- χρησιμοποιηθεί θα είναι αρκετά χρήσιμο!
• Όσοι απο εσάς παίζουν με EJB timers σίγουρα θα έχουν πει τουλάχιστον μια φορά - πω μακάρι να ήταν πιο ευέλικτοι - μακάρι να μπορούσα να κάνω το A to B to Γ πιο εύκολα! O Bill Burke στο Enterprise Java Beans 3.0 έγραψε στο τέλος του κεφαλαίου για τους timers - για το πόσο ωραία θα ήταν αν είχαμε μια πιο CRON like συμπεριφορά! Guess What! Στο EJB 3.1 οι Timers θα αποκτήσουν πιο δυναμική συμπεριφορά και ευελιξία! Αρκετά καλή είδηση αυτό - μιας και προσωπικά έχω ηδη φιάξει 1-2 μηχανισμούς με αυτούς και σκεφτόμουν σοβαρά να τους αφαιρέσω για να αντικατασταθούν με Java Timers η Quartz Service σε απο κάποιο JMX service!
• Async methods : @Asynchronous annotation και τέλος. Για την ώρα go go καλό μου JMS αλλά όπως λέει και ο Gavin King μήπως είναι overkill;
• Statefull Session Beans exposed as web service : Αυτό πραγματικά δεν ξέρω πως θα υλοποιηθεί σωστά και τι μαγικά θα πρέπει να κάνει ο application server σε συνεργασία με τον web service consumer για να διατηρήσουν το state τους. Σίγουρα sounds cool enough!
• Εκείνο για το οποίο δεν είμαι σίγουρος κατά πόσο είναι καλό ή κακό ή θα οδηγήσει σε σημαντικά λάθη είναι το /η Bean Managed Concurrency - δηλαδή ένα Bean να μπορεί να είναι διαθέσιμο σε πολλαπλά threads για invocation. Για την ώρα αυτό που ξέρουμε είναι οτι κάτι τέτοιο δεν είναι δυνατό! Ένα EJB instance δεν μπορεί να εξυπηρετήσει concurrent threads. Υποθέτω υπάρχουν αρκετά σενάρια που θα ήθελε κάποιος να το κάνει αυτό - τώρα που το σκέφτομαι και εγώ μάλλον θα μπορούσα να το χρησιμοποιήσω - αλλά υπάρχει ένα μεγάλο αλλά! O developer πρέπει να φροντίσει εξαιρετικά απλά να μην κάνει μαλακίες στον κώδικα του ιδιαίτερα όταν θα μπορούν να τον διατρέξουν πολλά thread - ιδιαίτερα μέσα σε ενα EJB το οποίο βρίσκεται μέσα σε έναν container! Cool enough Λοιπόν, αλλά δεν ξέρω θα ήμουν αρκετά προσεκτικός!

Ιδιαίτερο ενδιαφέρον έχει ένα παλιό post του Gavin King του οποίου παρακολούθησα μια απο τις 2 παρουσιάσεις για το Seam και ενώ ως ομιλητής και Java άνθρωπος είναι εντυπωσιακός - μου έκανε κακή εντύπωση οτι η ομιλία του ήταν πρόχειρη και σε κάποιο σημείο βαρετή μιας και έγραφε κώδικα on the fly.