Monday, January 22, 2007

Struts 2.0 + EJB 3.0 - Τον ήπιαμε λίγο

(WARNING -Διαβάζεις μονο αν ξέρεις J2EE, αλλιώς θα βαρεθείς έντονα).

Λοιπόν έχουμε τα παραπάκατω facts τα οποία δεν αλλάζουν

1. Χρήση EJB3.0 , γιατί αυτή είναι η δουλειά μας, γιατί έχουμε φάει την ...τσα του 2.1, γιατί απο τις πρώτες υλοποιήσεις φαίνεται ότι δουλεύει, γαιτί θέλουμε τον container βλεπε JΒoss σε περιπτώσεις που το Spring δεν μας καλύπτει.
2. Χρήση Struts (1.2 ή 2) , γιατί το ξέρουμε, δεν εχουμε αυτη την στιγμή χρόνο να πάμε σε κάτι άλλο, γιατι γαμάει και δέρνει ως framework ιδιαίτερα το 2.ο, γιατι δεν μας αρέσει το JSF, γιατί δεν εχουμε χρόνο να το κάνουμε σε JSF.

Με μεγάλη λύπη μπορώ να σας διαβεβαιώσω ότι αυτη την στιγμή δηλαδή στο ξεκίνημα των Struts 2.0 και EJB3.0 τα πράγματα δεν ειναι καλά! Το πρόβλημα ειναι συγκεκριμένο φαντάζει μικρό αλλά ειναι ΜΕΓΙΣΤΗΣ σημασίας.

Το web layer ειναι μια χαρά οργανωμένο , αντίστοιχα και το business layer. Ειναι η στιγμή που θα τα ενώσεις. Για τους γνώστες να πουμε οτι συνήθως σε τέτοιες περιστάσεις απο το J2EE 1.4 θα πάρεις και θα υλοποιήσεις το πακετάκι απο pattern
ServiceLocator / Delegates. Ο ServiceLocator ειναι ενα singleton ο οποιος cacharei και βρίσκει EJB interfaces για σενα..και σου τα πασαρει στο web layer για μην γράφει συνέχεια duplicated κωδικα ο οποίος θα κάνει JNDI lookups και interface narrowing +παράλληλα ο delegate ειναι ακόμα ένας διαχωρισμός ο οποίος αποκτά σημασια στο να δώσει ακόμα έναν διαχωρισμό στην εύρεση του Businnes object per case.Ένα ατελείωτο layering . Και ήμασταν καλα!

Με την έλευση του EJB3 πολλά απο τα γνωστά interface, εχουν φύγει, για τον προγραμματιστή πράγματι η διαδικασία έχει απλοποιηθεί και το βάρος έχει πέσει στην πολυπλοκότητα του container (όπως έλεγε και ο Δημήτρης, για εσας j2ee developers τα πράγματα εχουν γινει ωραία, για εμας του container developers κόλαση).Μπορείς να φιάξεις εναν χαζό service locator ο οποίος βεβαια δεν θα μπορεί efficiently να κάνει caching interfaces αλλά μόνο look up (ευχαριστω πολύ αυτο το κάνω και απο το action- κατουσιαν).

To EJB 3.0 σαν το Spring κάνει χρήση του Dependency Injection. Ιδιαίτερα σε web layer όπως απλά servlets αλλά και JSF το δέσιμο του web action class με το πραγματικό SLSB (Stateless Session bean) λύνεται ευκολα και γρήγορα με annotations και Dependency injection . Εσύ γράφεις ενα @EJB (name = κτλ κτλ και ο container σου κάνει inject το object που έχεις ορίσει. τι ωραια τι καλά!

Πάμε στο Struts 2.0 υποστηρίζει dependency Injection και μάλιστα το κάνει με ενα project της google Grucie . Υπάρχει υποστήριξη για Spring αλλά όχι EJB3.

Με άλλα λόγια είτε θα πρέπει να φιάξω δικα μου anottation και να υλοποιήσω εγώ το dependency injection στο Struts ,ειτε να βάλω μέσα το Spring για να μου κάνει αυτο το IoC, ειτε να ακολουθήσω τον δρόμο του κουτσου service locator , ειτε σαν χασάπης να κάνω κλησεις στο initial context απο τα Struts Action , ειτε να αλλάξω framework!

Ειμαι λίγο απογοητευμένος που το νέο struts δεν έχει υποστήριξη γιάυτο το κομμάτι. Θα ήθελα πάρα πολύ να είμαι ο πρώτος που θα το έκανα contribute (και οχι με work around) αλλα ο χρόνος ειναι μηδενικός.Από την άλλη δεν θέλω να αλλάξω framework γιατι το struts καλύπτεις τις ανάγκες του project..

Ελπίζω να βγέι καποιο extention plugin...προς το παρον

Context c = new InitialContext();
return (TestSessionLocal) c.lookup("java:comp/env/ejb/TestSessionBean");





4 comments:

  1. Χαίρε φίλτατε Πάρη!

    Καταρχήν δεν τον ήπιες καθόλου. Παίρνουμε τα πράγματα με τη σειρά και έχουμε:

    1) Δεν υπάρχει πιθανότητα να μην σε καλύψει το Spring και να σε καλύψουν τα EJB3 αφού το spring σε μεγάλο βαθμό είναι υπερσύνολο των EJB3 (αν θέλεις μπορώ να μπω σε λεπτομέρειες).

    2) Ο ServiceLocator μπορεί να κάνει cache ένα EJB μόνο από το web tier (δες http://www.tzavellas.com/techblog/?p=15).

    3) Αν δεν είσαι δογματικός και βάλεις λίγο Spring στην ζωή σου μπορείς να έχεις dependency injection των EJB3 στα Struts2 Action σου. Με την λύση αυτή δεν θα έχεις κανένα dependency στο Spring στον Java κωδικά σου και το μόνο που θα χρειαστεί να κάνεις είναι να γράψεις ένα spring xml που θα δένεις να Action με τα EJB3.

    Για να το κάνεις αυτό ένας τρόπος είναι ο εξής:
    - Χρησιμοποιήσεις το Spring plugin του Struts2
    - Γράφεις τα Action σου στα οποία έχεις setter injection με τα interfaces των EJB3.
    - Στο xml του Spring δηλώνεις τα EJB3 τα οποία κάνεις lookup από το jndi (πχ με το jee namespace)
    - Στο xml του Spring δηλώνεις τα Action και είτε τα δένεις με property tags είτε ορίζει σε κάθε Action autowire by type.

    Για περισσότερες λεπτομέριες ή εναλλακτικές προτάσεις κτλ email, msn, τηλ ...

    ReplyDelete
  2. έλα σπυρο..χεχε περίμενα την απάντηση σου μιας και μυρίζεσαι Spring απο μακρυα!

    Λοιπόν ναι έχεις δίκιο,μπορώ να το κάνω με Spring, το Struts 2 ηδη εχει ετοιμο plugin.

    Παρόλα αυτά έλα και λίγο στην θέση μου. Μέχρι τώρα ως EJB guy δεν ηθελα extra framework για το δέσιμο αυτό. Αυτη την στιγμή εγω ας το πουμε τεχνολογιά δεν θέλω να εμπλέξω και στο stack μου το Spring (τουλαχιστον για την ωρα).

    Μην το παίρνεις βαριά, θα το κάνω όταν πια φτάσω σε σημειο και δω οτι τα απλά workaround δεν δουλευουν.Αλλά όταν επιλέγεις τεχνολογίες σε ενα project ξέρεις ειναι δυσκολο ξαφνικά να βάλεις και άλλες στο stack και άλλες και άλλες.

    EJB3 για την χρήση που το θέλω καλυπτει πληρως τις ανάγκες μου απλά το δέσιμο με το συγκεκριμένο framework ειναι πια προβληματικο!

    Η αληθεια ειναι οτι έχω πάει ηδη στα forum του SPring και ειδα τα παραδείγματα οποτε υπάρχει πράγματι back -up plan.

    Η αληθεια ειναι οτι επειτηδες λιγο στις λιστες του Struts πήγα και γκρίνιαξα..γιατί το θεωρώ ως κάπως χτυπητό!

    Το Seam φαίνεται να τα καταφέρνει μια χαρά..αλλα είναι αυτή η μαλακία το JSF που η λογική μου με δυσκολευει.

    Τελικά..ναι πράγματι συνφωνώ τα ΕJB factory του Spring ισως ειναι η πιο elegant λυση at the time being.

    ReplyDelete
  3. http://twasink.net/blog/archives/2007/02/using_ejb3_with.html

    afto to exis dei?
    aftomatopiiei to injection meso
    spring

    kanei inject ta beans se seters
    kai me ligo piragma mprei na ta vazei kai se private field

    nomizo me ligo sxetika kopo
    linei pliros to provlima..

    ReplyDelete
  4. γεια σου Κώστα, thanksγ για το comment. Ο μόνος λόγος που δεν ακολούθησα (για την ώρα) αυτή την προσέγγιση είναι ότι δεν θέλω να προσθέσω ακόμα ενα framework στο stack της λύσης και ίσως κάποιο overhead παραπάνω, για κάτι το οποίο τελικά οκ το κάνω με λίγο κώδικα παραπάνω. Παρόλα αυτά επιφυλάσσομαι αν στο μέλλον το project γίνει πιο μεγάλο να το ξανασκεφτώ!

    ReplyDelete