Αρχιτεκτονική εφαρμογών με JEE6;
84 views
Skip to first unread message
George Georgovassilis
Mar 25, 2013, 4:02:32 AM3/25/13
to jh...@googlegroups.com
Αγαπητοί,
Συνεχίζω και περιηγούμαι πλήρης θαυμασμού στον μαγικό κόσμο του JEE6 και βλέπω "βέβηλα" όντα όπως form backing objects με αναφορές σε services, persistent entities κλπ. Καταλαβαίνω την ειδοποιό διαφορά μεταξύ MVC á la Spring και JEE6 αρχιτεκτονικής να είναι το αναιμικό μοντέλο δεδομένων με ότι συνεπάγεται (DAOs, Services, DTOs, view) σε αντιδιαστολή με ένα πλήρες μοντέλο αντικειμένων όπου και το view έχει απευθείας πρόσβαση στο domain model, δυσκολεύομαι όμως να δω πως θα έχτιζε κανείς μια enterprise εφαρμογή με τον 2ο τρόπο με JEE6 χωρίς να χάσει τον μπούσουλα. Υπάρχουν συνταγές για την δόμηση εφαρμογών με JEE6; Έχω βρει κάποια παραδείγματα και pet ships, αλλά η εντύπωσή μου είναι ότι ο κάθε συγγραφέας λαμβάνει εκτεταμένη ποιητική άδεια σε αντίθεση με το spring όπου υπάρχει συνήθως μόνο ένας ( ο ) τρόπος να κάνεις δουλειά σου.
Αν έχετε άρθα ή links σε καλές συζητήσεις για το θέμα ή θέλετε να προσθέσετε την δική σας άποψη εδώ παρακαλώ γράψτε τα :-)
Ευχές,
Γ.
Συνεχίζω και περιηγούμαι πλήρης θαυμασμού στον μαγικό κόσμο του JEE6 και βλέπω "βέβηλα" όντα όπως form backing objects με αναφορές σε services, persistent entities κλπ. Καταλαβαίνω την ειδοποιό διαφορά μεταξύ MVC á la Spring και JEE6 αρχιτεκτονικής να είναι το αναιμικό μοντέλο δεδομένων με ότι συνεπάγεται (DAOs, Services, DTOs, view) σε αντιδιαστολή με ένα πλήρες μοντέλο αντικειμένων όπου και το view έχει απευθείας πρόσβαση στο domain model, δυσκολεύομαι όμως να δω πως θα έχτιζε κανείς μια enterprise εφαρμογή με τον 2ο τρόπο με JEE6 χωρίς να χάσει τον μπούσουλα. Υπάρχουν συνταγές για την δόμηση εφαρμογών με JEE6; Έχω βρει κάποια παραδείγματα και pet ships, αλλά η εντύπωσή μου είναι ότι ο κάθε συγγραφέας λαμβάνει εκτεταμένη ποιητική άδεια σε αντίθεση με το spring όπου υπάρχει συνήθως μόνο ένας ( ο ) τρόπος να κάνεις δουλειά σου.
Αν έχετε άρθα ή links σε καλές συζητήσεις για το θέμα ή θέλετε να προσθέσετε την δική σας άποψη εδώ παρακαλώ γράψτε τα :-)
Ευχές,
Γ.
Paris Apostolopoulos
Mar 26, 2013, 4:22:05 AM3/26/13
to jh...@googlegroups.com
Γεια σου Γιώργο!
Αντίστοιχα μεγάλη συζήτηση, εγώ από την όποια εμπειρία μου θα πω ότι όπως και το Spring έτσι και το J2EE έχει κάποιες directives σε θέματα αρχιτεκτονικής και θα έλεγα ότι μπορεί να μην είναι αρκετά εμφανή με το που κάνεις την εισαγωγή σου σε αυτό (δηλαδή σου δίνει την εντυπωση ότι εχει πολλά και διάφορα επίπεδα ελευθερίας) αλλά τελικά καταλήγεις να τα υπακούσεις ή ακολουθήσεις, μιας και οι τεχνολογίες που δίνουν σάρκα και οστά στο spec ...σε πάνε προς τα εκεί...πχ ένας container με τα καλά και τα άσχημα του. Παλιότερα που οι j2ee containers ήταν πιο beasts σε σχέση με το πιο ελαφρύ Spring οι διαφορές ήταν ακόμα πιο έντονες.
Τώρα σε ότι έχει να κάνει με τις αναζητήσεις σου, θα παραθέσω μερικά βιβλία που αξίζει να ρίξεις μια ματιά. Η καλή σου εμπειρία στο Spring αλλά και γενικότερα στον χώρο θα μετρήσει και δεν νομίζω να δυσκολευτείς καθόλου για να δεις τα αντίστοιχα concept.
1. Real World Java EE Patterns (Rethinking Best Practises) του Adam Bien- είναι νομίζω πραγματικά πολύ κοντά στις αναζητήσεις σου.
Μάλιστα έχει μια αρκετά καλή συλλογή από samples στο github (https://github.com/AdamBien)
2. Enterprise Java Beans 3.1 6th Edition - Oreilly- Reference βιβλίο κατα την γνώμη μου http://shop.oreilly.com/product/9780596158033.do
3. EJB3 in action (MEAP) το οποίο αγόρασα και πιστεύω ότι ειναι για την ώρα αξιόλογο - θα το ολοκληρώσει σε μερικούς μήνες! http://www.manning.com/panda2/
Ελπίζω να βοήθησα
Χαιρετισμούς!!
Αντίστοιχα μεγάλη συζήτηση, εγώ από την όποια εμπειρία μου θα πω ότι όπως και το Spring έτσι και το J2EE έχει κάποιες directives σε θέματα αρχιτεκτονικής και θα έλεγα ότι μπορεί να μην είναι αρκετά εμφανή με το που κάνεις την εισαγωγή σου σε αυτό (δηλαδή σου δίνει την εντυπωση ότι εχει πολλά και διάφορα επίπεδα ελευθερίας) αλλά τελικά καταλήγεις να τα υπακούσεις ή ακολουθήσεις, μιας και οι τεχνολογίες που δίνουν σάρκα και οστά στο spec ...σε πάνε προς τα εκεί...πχ ένας container με τα καλά και τα άσχημα του. Παλιότερα που οι j2ee containers ήταν πιο beasts σε σχέση με το πιο ελαφρύ Spring οι διαφορές ήταν ακόμα πιο έντονες.
Τώρα σε ότι έχει να κάνει με τις αναζητήσεις σου, θα παραθέσω μερικά βιβλία που αξίζει να ρίξεις μια ματιά. Η καλή σου εμπειρία στο Spring αλλά και γενικότερα στον χώρο θα μετρήσει και δεν νομίζω να δυσκολευτείς καθόλου για να δεις τα αντίστοιχα concept.
1. Real World Java EE Patterns (Rethinking Best Practises) του Adam Bien- είναι νομίζω πραγματικά πολύ κοντά στις αναζητήσεις σου.
Μάλιστα έχει μια αρκετά καλή συλλογή από samples στο github (https://github.com/AdamBien)
2. Enterprise Java Beans 3.1 6th Edition - Oreilly- Reference βιβλίο κατα την γνώμη μου http://shop.oreilly.com/product/9780596158033.do
3. EJB3 in action (MEAP) το οποίο αγόρασα και πιστεύω ότι ειναι για την ώρα αξιόλογο - θα το ολοκληρώσει σε μερικούς μήνες! http://www.manning.com/panda2/
Ελπίζω να βοήθησα
Χαιρετισμούς!!
Βασίλης Τσιρκινίδης
Mar 26, 2013, 10:53:30 AM3/26/13
to jh...@googlegroups.com
Με ενδιαφέρει και εμένα η ΕΕ αν και είμαι ακόμη φοιτητής. Θα ρίξω μια ματιά στα βιβλία, ευχαριστώ για τις υποδείξεις.
ΥΓ. Γενικότερα είναι συνηθισμένο σε project που γίνονται στην Ελλάδα έργα με NoSQL και JPA υλοποιήσεις; Αν συμβαίνει ποιες προτιμούνται; Φαντάζομαι το Spring...
ΥΓ. Γενικότερα είναι συνηθισμένο σε project που γίνονται στην Ελλάδα έργα με NoSQL και JPA υλοποιήσεις; Αν συμβαίνει ποιες προτιμούνται; Φαντάζομαι το Spring...
--
You received this message because you are subscribed to the Google Groups "jhug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhug+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Paris Apostolopoulos
Mar 26, 2013, 11:04:12 AM3/26/13
to jh...@googlegroups.com
Από αυτά που ακούω και βλέπω εγώ νομίζω ότι στην Ελλάδα ακόμα οι NoSQL based υλοποιήσεις δεν έχουν γίνει mainstream ..μόνο εξαιρέσεις .
Dionisis Petrakopoulos
Mar 27, 2013, 3:23:51 AM3/27/13
to jh...@googlegroups.com
Καλημέρα,
Συμφωνώ και εγώ ότι οι NoSQL υλοποιήσεις δεν είναι ακόμα το στάνταρ. Παρολαυτά αρκετές εταιρίες είτε παίζουν και με τα 2 είδη παράλληλα (RDBMS,NoSQL) είτε πειραματίζονται για την αλλαγή.
Συμφωνώ και εγώ ότι οι NoSQL υλοποιήσεις δεν είναι ακόμα το στάνταρ. Παρολαυτά αρκετές εταιρίες είτε παίζουν και με τα 2 είδη παράλληλα (RDBMS,NoSQL) είτε πειραματίζονται για την αλλαγή.
Λίγες είναι αυτές πάντως που έχουν εγκαταλείψει τελείως το RDBMS. Μιλάμε πάντα για Ελλάδα.
Πάντως σίγουρα η τάση είναι σαφώς μεγαλύτερη από το να πάει μια εταιρία π.χ. από Java σε Scala ή κάποια άλλη γλώσσα γιατί εκεί τα πράγματα είναι πιο ζόρικα από πολλές απόψεις (time to learn, μετατροπή legacy συστημάτων, υποστήριξη παλαιιού προϊόντος λόγω πελατών αλλά και νέου κλπ).
Markos Fragkakis
Mar 27, 2013, 3:53:28 AM3/27/13
to jh...@googlegroups.com
Μικρή παρένθεση. Χωρίς να έχω χρησιμοποιήσει NoSQL, από ότι έχω διαβάσει το τυπικό σενάριο δεν είναι ότι "εγκαταλείπω το RDBMS". Ένα σύνηθες σενάριο είναι ότι κάποια από τα δεδομένα μου είτε λόγω πλήθους είτε λόγω μορφής δεν αφήνουν την εφαρμογή να κάνει scale σε RDBMS, τότε για αυτά τα δεδομένα χρησιμοποιώ NoSQL. Και ανάλογα με τον τύπο δεδομένων, διαλέγω και διαφορετικό NoSQL paradigm.
Sent from my iPhone
Βασίλης Τσιρκινίδης
Mar 27, 2013, 8:18:43 AM3/27/13
to jh...@googlegroups.com
Από ότι έχω καταλάβει οι ORM υλοποιησείς βασίζονται στο RDBMS και προσφέρουν ένα επίπεδο επικοινωνίας κοντά στη γλώσσα προγραμματισμού. Δεδομένα σαν αντικείμενα και όχι σαν απλοί τύποι δεδομένων. Σε αυτές τις περιπτώσεις η μετάβαση δεν είναι σχετικά εύκολη;
Paris Apostolopoulos
Mar 27, 2013, 11:09:33 AM3/27/13
to jh...@googlegroups.com
Σε γενικές γραμμές σωστά καταλαβαίνεις. παρόλα αυτά πολλά ORM με τα χρόνια έχουν εξελιχθει αρκετά έτσι ώστε να αντιμετωπίζουν τα πράγματα υπό τον πρίσμα των RDBMS και της γενικότερης relational φιλοσοφίας. Τα οποία δεν τα κάνει τόσο συμβατά με την φιλοσοφία των NoSQL βάσεων ΧΩΡΙΣ να είναι απόλυτο το παραπάνω.
Στον κόσμο των NoSQL οι ιδέες είναι μια μείξη νέων concept (φυσικά φυσικά) αλλά και τωρινών μέσα από τα εργαλεία και τις τεχνικές που εξελίχθηκαν από την ωρίμανση των ORM.
Μια χαρακτηριστική προσπάθεια κλασικού Java ORM που κατέχει και τα πρωτεία χρήσης - βλέπε Hibernate- που παρέχει μια γέφυγα και για noSQL βάσεις βλέπε
Hibernate OGM - http://www.hibernate.org/subprojects/ogm.html
Στον κόσμο των NoSQL οι ιδέες είναι μια μείξη νέων concept (φυσικά φυσικά) αλλά και τωρινών μέσα από τα εργαλεία και τις τεχνικές που εξελίχθηκαν από την ωρίμανση των ORM.
Μια χαρακτηριστική προσπάθεια κλασικού Java ORM που κατέχει και τα πρωτεία χρήσης - βλέπε Hibernate- που παρέχει μια γέφυγα και για noSQL βάσεις βλέπε
Hibernate OGM - http://www.hibernate.org/subprojects/ogm.html
Christos KK Loverdos
Mar 27, 2013, 11:39:09 AM3/27/13
to jh...@googlegroups.com
Κάτι που συνήθως, με όλο αυτό το hype μπορεί να μας διαφύγει: Για να χρειαστεί να πάει κανείς σε NoSQL λόγω "big data" (άλλη μια χαϊπουριά), πρέπει πραγματικά να μιλάμε για πολύ συγκεκριμένες απαιτήσεις.
Το NoSQL δεν νομίζω ότι από μόνο του μπορεί να είναι design decision apriori, πρέπει να υπάρχει σαφής κατανόηση γιατί ένα RDBMS δεν κάνει τη δουλειά.
Θα μου πεις, πώς μπορώ να είμαι ευέλικτος και να κάνω switch όταν χρειαστεί; Πρώτον, αυτά τα "switch" είναι από μόνα τους projects. Δεύτερον, αν πραγματικά θέλεις εκ των προτέρων να "προβλέψεις" το μέλλον και να μειώσεις ενδεχομένως το κόστος μετάβασης, θα πρέπει να μοντελοποιήσεις γενικά με βάση τα business operations και όχι πώς υλοποιούνται. Με λίγα λόγια, έχε ένα κατώτερο επίπεδο που κάνει τη βρώμικη δουλειά (JDBC, Hibernate, ORM), αλλά κρύψτο από ένα ανώτερου επιπέδου API.
Με βάση τα παραπάνω, ένας δρόμος που ακολουθώ και βοηθάει, είναι ότι πάντα γράφω against a business-oriented API:
interface CustomerStore {
Customer insertNewCustomer(Customer customer)
Option<Customer> findCustomerByID(String id)
}
το οποίο και χρησιμοποιώ στην υπόλοιπη εφαρμογή, αντί να έχω χύμα τα οποιαδήποτε calls του μηχανισμού που στην πραγματικότητα το υλοποιεί *ακόμα και αν αυτά φαίνονται βολικά και αρκετά γενικά*.
Στην πραγματικότητα, ένα σχήμα βάσης (SQL ή NoSQL δεν έχει καμία σημασία), το θες για να κάνεις πάνω του *συγκεκριμένα* queries. Άρα, αφενός σχεδιάζουμε *πάντα* έχοντας υπόψη τα queries που μας ενδιαφέρουν και αφετέρου, επειδή τα queries έχουν πολύ συγκεκριμένο business value (ενώ το PreparedStatement δεν έχει κανένα), δουλεύουμε σε σχεδιαστικό επίπεδο με βάση αυτά και όχι τον τρόπο με τον οποίο θα υλοποιηθούν.
Φυσικά, το design είναι *πολύ δύσκολο* πράγμα και δεν υπάρχει μία λύση για όλα (πολλές φορές ούτε καν η "βέλτιστη" λύση για ένα πράγμα). Η πραγματικότητα είναι σκληρή και αρκετές φορές τα abstractions κάνουν leak. Όλα είναι στο πρόγραμμα :)
Christos KK Loverdos
@loverdos
stepsinscala.com
Everything that is really great and inspiring is created by the individual who can labor in freedom — Albert Einstein
Το NoSQL δεν νομίζω ότι από μόνο του μπορεί να είναι design decision apriori, πρέπει να υπάρχει σαφής κατανόηση γιατί ένα RDBMS δεν κάνει τη δουλειά.
Θα μου πεις, πώς μπορώ να είμαι ευέλικτος και να κάνω switch όταν χρειαστεί; Πρώτον, αυτά τα "switch" είναι από μόνα τους projects. Δεύτερον, αν πραγματικά θέλεις εκ των προτέρων να "προβλέψεις" το μέλλον και να μειώσεις ενδεχομένως το κόστος μετάβασης, θα πρέπει να μοντελοποιήσεις γενικά με βάση τα business operations και όχι πώς υλοποιούνται. Με λίγα λόγια, έχε ένα κατώτερο επίπεδο που κάνει τη βρώμικη δουλειά (JDBC, Hibernate, ORM), αλλά κρύψτο από ένα ανώτερου επιπέδου API.
Με βάση τα παραπάνω, ένας δρόμος που ακολουθώ και βοηθάει, είναι ότι πάντα γράφω against a business-oriented API:
interface CustomerStore {
Customer insertNewCustomer(Customer customer)
Option<Customer> findCustomerByID(String id)
}
το οποίο και χρησιμοποιώ στην υπόλοιπη εφαρμογή, αντί να έχω χύμα τα οποιαδήποτε calls του μηχανισμού που στην πραγματικότητα το υλοποιεί *ακόμα και αν αυτά φαίνονται βολικά και αρκετά γενικά*.
Στην πραγματικότητα, ένα σχήμα βάσης (SQL ή NoSQL δεν έχει καμία σημασία), το θες για να κάνεις πάνω του *συγκεκριμένα* queries. Άρα, αφενός σχεδιάζουμε *πάντα* έχοντας υπόψη τα queries που μας ενδιαφέρουν και αφετέρου, επειδή τα queries έχουν πολύ συγκεκριμένο business value (ενώ το PreparedStatement δεν έχει κανένα), δουλεύουμε σε σχεδιαστικό επίπεδο με βάση αυτά και όχι τον τρόπο με τον οποίο θα υλοποιηθούν.
Φυσικά, το design είναι *πολύ δύσκολο* πράγμα και δεν υπάρχει μία λύση για όλα (πολλές φορές ούτε καν η "βέλτιστη" λύση για ένα πράγμα). Η πραγματικότητα είναι σκληρή και αρκετές φορές τα abstractions κάνουν leak. Όλα είναι στο πρόγραμμα :)
@loverdos
stepsinscala.com
Everything that is really great and inspiring is created by the individual who can labor in freedom — Albert Einstein
Aggelos Karalias
Mar 28, 2013, 2:18:41 AM3/28/13
to jhug
2013/3/27 Markos Fragkakis <markos.f...@gmail.com>:
> Μικρή παρένθεση. Χωρίς να έχω χρησιμοποιήσει NoSQL, από ότι έχω διαβάσει το
> τυπικό σενάριο δεν είναι ότι "εγκαταλείπω το RDBMS"
Αν και η κουβέντα ξεφεύγει από το subject της νομίζω ότι σε αυτό που λέει ο Μάρκος είναι το ζουμί.
Γενικά δεν τίθεται θέμα rdbms or nosql. Επίσης είναι αρκετά naive το ότι τα NoSQL stores κάνουν scale. Πολλά δεν κάνουν. Το neo4j ταλαιπωρείται απίστευτα στο θέμα του sharding, το redis το υλοποιεί σε επίπεδο client κλπ. Το θέμα είναι ότι έχεις περισσότερες λύσεις στα χέρια σου που μπορεί να κάνουν καλύτερα fit στο πρόβλημα που έχεις και να έχουν και καλύτερο performance ανά περίπτωση.
Ειδικά πάντως όσον αφορά το "big data" σενάριο και πάλι ένα nosql store από μόνο του δεν φέρνει την άνοιξη. Στην πράξη εκεί τα layers είναι πολλά και περιέχουν αρκετά διαφορετικά stores. Ένα καλό book μέχρι τώρα φαίνεται να είναι το Big Data από τον Nathan Marz (είναι MEAP από την Manning Publications - http://www.manning.com/marz/). Το πιο ενδιαφέρον είναι ότι σε αυτές τις raw καταστάσεις αλλάζει τελείως το mindset, το modeling διαφέρει αρκετά από το τυπικό ER και γίνεται πιο fact-based.
Επίσης όσο περνάει ο καιρός και τα πράγματα ωριμάζουν τείνω να διαφωνώ με την άποψη στο ότι το big data είναι εξεζητημένη περίπτωση για λίγες εφαρμογές. Το κάθε project αποφασίζει το κατά πόσο θέλει να είναι big data ή όχι. Μπορείς να ανοίξεις εξαιρετικά το τι data αποθηκεύεις και το τι business value μπορείς να εξάγεις από αυτά. Για παράδειγμα μπορείς να έχεις το πιο απλό site, αλλά έχει σημασία για σένα να κρατάς για κάθε χρήστη τις συντεταγμένες (σε pixels) που βρίσκεται το mouse στην οθόνη κάθε 5 δευτερόλεπτα γιατί από αυτό καταλαβαίνεις καλύτερα την τάδε συμπεριφορά, οπότε άμεσα οι ανάγκες πέφτουν κάτω από το big data umbrella χωρίς να είσαι απαραίτητα η google.
Anyways το καλό είναι ότι υπάρχει πλέον mainstream πρόσβαση σε εξαιρετικές τεχνολογίες για χαρά και εργασία!
Χαιρετισμούς,
Άγγελος
Anestis Georgiadis
Mar 31, 2013, 5:06:50 PM3/31/13
to jh...@googlegroups.com
George,
Όσον αφορά το JEE 6 έχω να πω τα εξής:
Ξεκινήσαμε καινούργιο έργο, όπου πήραμε την απόφαση να πάμε by the book σε όλα. Τουτέστιν, JPA για persistence, EJBs για services (κυρίως JPA backed), JSF για UI, CDI για DI και interceptors κ.ο.κ. Deployment σε JBoss EAP 6, αλλά με προσπάθεια να δεθούμε σε JBoss-specific APIs όσο το δυνατόν λιγότερο (μέχρι τώρα μόνο μερικά Hibernate-specific annotations και infinispan).
Έχω ΕΝΤΥΠΩΣΙΑΣΤΕΙ με το πόσο κοντά έχει έρθει το JEE 6 με το Spring. Θα θυμάσαι φαντάζομαι από το κοινό μας career path πόσο αγαπάω το Spring, και πρέπει να σου ομολογήσω ότι ήμουν σίγουρος ότι θα υπήρχε κάποια ανάγκη που θα ανάγκαζε να φέρω κάτι από Spring στο έργο. Αρχιτεκτονικά έχω κάνει ότι θα έκανα και με Spring, decouple το UI (= MVC) από τα services μέσω APIs και (entity) model, AOP-like λύσεις για crosscutting concerns, the full monty. Έχουμε προσεγγίσει με διαφορετικό τρόπο πράγματα όπως το security ή το environment-specific configuration, αλλά το τελικό αποτέλεσμα είναι το ίδιο. Εάν δεν χρησιμοποιούσαμε Activiti δεν θα είχαμε ούτε ένα spring jar στο classpath!
Όταν είχε κάνει ο Gupta εκείνη την παρουσίαση στο JHUG πριν από 1-2 χρόνια είχα μείνει την απορία εάν θα κατάφερνε το spec να επιτρέψει την ανάπτυξη εφαρμογών χωρίς να χρειάζεσαι την Άρτα και τα Γιάννενα στο project, και παρόλο που υπάρχουν ακόμα περιθώρια βελτίωσης (με ποιο σημαντικό το να εξαλειφθούν τα κοινά στοιχεία μεταξύ των specs που αναπτύχθηκαν παράλληλα, και κυρίως η αλληλοκάλυψη μεταξύ CDI, JSF και καταλοίπων από JEE <5) νομίζω ότι το Spring δεν έχει πια νόημα σήμερα. Αυτό που χρειάζεται βέβαια είναι υποστήριξη για ένα ριζικά διαφορετικό τρόπο να γράφεις webapps σε JVM (για το enterprise επιφυλάσσομαι λίγο ακόμα, μιας και το περιβάλλον είναι αρκετά ρευστό), και από ότι φαίνεται τόσο η VMWare/SpringSource όσο και ο ίδιος ο Rod Johnson έχουν στρέψει το ενδιαφέρον τους προς τα εκεί.
Όσον αφορά συνταγές δεν έχω κατά νου ένα συγκεκριμένο βιβλίο που να αποτυπώνει σε μεγάλο βαθμό αυτό που έχουμε υλοποιήσει, όπως όμως δεν έχω και κάτι αντίστοιχο για Spring. Γενικά η προσέγγιση είναι αυτή του KISS and DRY, και εάν κανείς δεν έχει καταστραφεί από την παρατεταμένη έκθεση σε EJB 2.x era αηδίες τότε νομίζω ότι η κοινή λογική αρκεί.
Φιλικά,
Ανέστης
--
Anestis Georgiadis
Software architect, amateur photographer, aspiring cyclist
http://about.me/mranest
Όσον αφορά το JEE 6 έχω να πω τα εξής:
Ξεκινήσαμε καινούργιο έργο, όπου πήραμε την απόφαση να πάμε by the book σε όλα. Τουτέστιν, JPA για persistence, EJBs για services (κυρίως JPA backed), JSF για UI, CDI για DI και interceptors κ.ο.κ. Deployment σε JBoss EAP 6, αλλά με προσπάθεια να δεθούμε σε JBoss-specific APIs όσο το δυνατόν λιγότερο (μέχρι τώρα μόνο μερικά Hibernate-specific annotations και infinispan).
Έχω ΕΝΤΥΠΩΣΙΑΣΤΕΙ με το πόσο κοντά έχει έρθει το JEE 6 με το Spring. Θα θυμάσαι φαντάζομαι από το κοινό μας career path πόσο αγαπάω το Spring, και πρέπει να σου ομολογήσω ότι ήμουν σίγουρος ότι θα υπήρχε κάποια ανάγκη που θα ανάγκαζε να φέρω κάτι από Spring στο έργο. Αρχιτεκτονικά έχω κάνει ότι θα έκανα και με Spring, decouple το UI (= MVC) από τα services μέσω APIs και (entity) model, AOP-like λύσεις για crosscutting concerns, the full monty. Έχουμε προσεγγίσει με διαφορετικό τρόπο πράγματα όπως το security ή το environment-specific configuration, αλλά το τελικό αποτέλεσμα είναι το ίδιο. Εάν δεν χρησιμοποιούσαμε Activiti δεν θα είχαμε ούτε ένα spring jar στο classpath!
Όταν είχε κάνει ο Gupta εκείνη την παρουσίαση στο JHUG πριν από 1-2 χρόνια είχα μείνει την απορία εάν θα κατάφερνε το spec να επιτρέψει την ανάπτυξη εφαρμογών χωρίς να χρειάζεσαι την Άρτα και τα Γιάννενα στο project, και παρόλο που υπάρχουν ακόμα περιθώρια βελτίωσης (με ποιο σημαντικό το να εξαλειφθούν τα κοινά στοιχεία μεταξύ των specs που αναπτύχθηκαν παράλληλα, και κυρίως η αλληλοκάλυψη μεταξύ CDI, JSF και καταλοίπων από JEE <5) νομίζω ότι το Spring δεν έχει πια νόημα σήμερα. Αυτό που χρειάζεται βέβαια είναι υποστήριξη για ένα ριζικά διαφορετικό τρόπο να γράφεις webapps σε JVM (για το enterprise επιφυλάσσομαι λίγο ακόμα, μιας και το περιβάλλον είναι αρκετά ρευστό), και από ότι φαίνεται τόσο η VMWare/SpringSource όσο και ο ίδιος ο Rod Johnson έχουν στρέψει το ενδιαφέρον τους προς τα εκεί.
Όσον αφορά συνταγές δεν έχω κατά νου ένα συγκεκριμένο βιβλίο που να αποτυπώνει σε μεγάλο βαθμό αυτό που έχουμε υλοποιήσει, όπως όμως δεν έχω και κάτι αντίστοιχο για Spring. Γενικά η προσέγγιση είναι αυτή του KISS and DRY, και εάν κανείς δεν έχει καταστραφεί από την παρατεταμένη έκθεση σε EJB 2.x era αηδίες τότε νομίζω ότι η κοινή λογική αρκεί.
Φιλικά,
Ανέστης
--
Anestis Georgiadis
Software architect, amateur photographer, aspiring cyclist
http://about.me/mranest
Σπύρος Αναστασόπουλος
Apr 1, 2013, 6:21:24 AM4/1/13
to jh...@googlegroups.com
Καλημέρα
Με προβλημάτισαν οι παρακάτω φράσεις του Ανέστη, που νομίζω σηκώνουν λίγη ανάλυση παραπάνω, γιατί με την πρώτη ανάγνωση μπορούν εύκολα να παρερμηνευτούν.
"""νομίζω ότι το Spring δεν έχει πια νόημα σήμερα. Αυτό που χρειάζεται βέβαια είναι υποστήριξη για ένα ριζικά διαφορετικό τρόπο να γράφεις webapps σε JVM (για το enterprise επιφυλάσσομαι λίγο ακόμα, μιας και το περιβάλλον είναι αρκετά ρευστό), και από ότι φαίνεται τόσο η VMWare/SpringSource όσο και ο ίδιος ο Rod Johnson έχουν στρέψει το ενδιαφέρον τους προς τα εκεί."""
1. Spring: Το JEE είναι ένα μεγάλο spec που παρέχει standards για τα low level APIs όπως JDBC, JTA, JMS, HTTP(servlets) κτλ και ένα προγραμματιστικό μοντέλο πάνω σε αυτά με JPA, JSF, CDI κτλ. Απο εδώ υπάρχουν δύο κατευθύνσεις: ή υιοθετείς και δουλεύεις με όλο το spec όπως έκανε η ομάδα του Ανέστη, ή απλά βασίζεσαι στα low level APIs και χρησιμοποιείς όποιο προγραμματιστικό μοντέλο σου αρέσει, ένα εκ των οποίων είναι το spring. Προσωπικά μου αρέσει να βλέπω το JEE με το δεύτερο τρόπο. Ένα standard όσο καλό και να είναι σίγουρα δεν μπορεί να προβλέψει και να περιλάβει τα πάντα. Τέτοιες φιλοδοξίες καταλήγουν σε μεγάλα, δύσχρηστα standards. Τα παραδείγματα άπειρα με πιο χαρακτηριστικά τα CORBA, xhtml 2.0, SOAP/WSDL etc Επιπλέον αυτό που πάντα θα θέλει και θα ζητάει ο developer είναι ευελιξία στις επιλογές του. Καταλήγω ότι ακόμα και αν το JEE6 κάνει obsolete το spring, (not yet!!!), projects τύπου spring που θα έρθουν στο μέλλον θα είναι πάντα χρήσιμα και ευπρόσδεκτα και θα έχουν λόγω ύπαρξης. Η ουσία όπως είπα είναι πως το JEE δίνει τα low level APIs τα οποία είναι σταθερά απο το J2EE 1.3 και απο εκεί και πέρα μιλάμε για προγραμματιστικά μοντέλα, που είναι τόσα πολλά και δεν γίνεται ένα standard να τα περιλαμβάνει όλα.
2. τρόπος ανάπτυξης: Εδώ είναι το μεγάλο πρόβλημα της java. Η ανάπτυξη μιας web εφαρμογής σε java σε σύγκριση με την ανάπτυξη σε rails ή node.js ή python είναι πολύ γραφειοκρατική αν όχι μαζοχιστική. Ο λόγος είναι το enterprise και μόνο. Σε αυτό το χώρο η java κυριαρχεί επειδή ο java κώδικας είναι πιο scalable και maintenable όσο μεγαλώνει το project και τα enterprise έργα ήδη είναι αρκετά μεγάλα απο τα requirements πριν καν γραφτεί 1 γραμμή κώδικα. Στον enterprise χώρο όμως έχουμε και τους μεγάλους παίχτες όπως oracle και ibm που θέλουν να πουλάνε προΐντα σε ανίδεους managers. Η διαδικασία ανάπτυξης στο enterprise αντί να επικεντρωθεί στο core της java επικεντρώθηκε απο τους παίχτες στα προΐοντα τους. Χαρακτηριστικό παράδειγμα ότι έχουν περάσει σχεδόν 10 χρόνια απο τη java 5 και η γλώσσα ακόμα δεν έχει ένα σοβαρό module σύστημα γιατί και καλά αυτά τα χειρίζεται ο application server, το build tool, το domain κτλ Εργαλεία εμφανίζονται κατά καιρούς όπως το spring roo αλλά δεν φαίνεται να έχουν το impact που έχει το rails της ruby. Μετά έχουμε vendor frameworks όπως πχ seam, vendor βλακείες όπως BPEL και φτάνουμε σε ένα θολό τοπίο όπου για να βρείς το δρόμο σου χρειάζεσαι μαντικές ικανότητες. Υπάρχει ήδη jhug thread πάνω στον τεχνολογικό πληθωρισμό του JEE.
To άλλο θέμα είναι το java stack. Το μεγάλο στοίχημα της java είναι το cloud όπου έχει μείνει πίσω. Απο ότι φαίνεται το JEE spec δεν γίνεται scale καλώς. Κανένας cloud provider δεν παρέχει PaaS το full spec. Οι περισσότεροι παρέχουν spring ή play. Νομίζω αυτό οφείλεται στο ότι το JEE είναι ένα κτητικό spec δηλ υποθέτει ότι αν χρησιμοποιήσεις ένα κομμάτι του θα το χρησιμοποιήσεις όλο. Στο cloud όμως θέλεις μέγιστη ευελιξία, θέλεις να πληρώνεις μόνο για ότι χρησιμοποιείς και μόνο, θέλεις να παίζεις με το configuration συχνα κτλ Αυτό οδήγησε σε δύο τάσεις: 1. απλούστερα stacks για τη java όπως dropwizard, twitter commons, spring + jetty 2. υιοθέτηση της scala που παρέχει αυτά τα stacks πχ play, lift με out of the box εργαλεία για ανάπτυξη. Όσοι δεν έχετε ασχοληθεί απλά κατεβάστε το play και δείτε τη διαφορά στον τρόπο ανάπτυξης.
Σαν παρένθεση, απο ότι διαβάζω στα blogs των μεγάλων java users όπως twitter, square, linkedin κτλ κανένας δεν φαίνεται να έχει java κομμάτι πρώτη γραμμή. Φαίνεται πως οι clients μιλάνε σε κάποια ruby/php/scala μικρή "βιτρίνα" η οποία όταν χρειαστεί για διάφορες διαδικασίες κάνει RPC σε java servers με κάποιο platform independent framework όπως thrift ή finagle. Απο αυτό το σημείο και μετά παίζει java με τα scalability και performance ωφέλη της και φυσικά μιλάμε για custom πράγματα και όχι για JEE.
3. Είχα την εντύπωση(απο tweets) πως ο Rod έχει αφήσει το spring και παίζει με scala. Επέστρεψε ο άσωτος?
Που θέλω να καταλήξω? Υπάρχουν 2 flavors της java. Η enterprise και η cloud. Για την enterprise το JEE 6 φαίνεται να είναι καλό. Σε όποιον δεν αρέσει το spring υπάρχει ακόμα και παραμένει αξιόπιστο. Σχετικά όμως με το cloud ούτε το ένα ούτε το άλλο κάνουν στην τωρινή τους μορφή, η java ακόμα ψάχνεται και οι ανταγωνιστές (ruby, scala) δυναμώνουν
Ελπίζω να μην κούρασα με την πολυλογία μου
Ευχαριστώ
Σπύρος
Βασίλης Τσιρκινίδης
Apr 1, 2013, 11:01:02 AM4/1/13
to jh...@googlegroups.com
Καλημέρα,
Σαν φοιτητής που διαβάζει java με την ελπίδα να δουλέψει πάνω σε αυτό στο κοντινό μέλλον από ότι καταλαβαίνω είναι καλή επένδυση να διαβάσω και να γράψω σε spring από ότι λέτε, σωστά; Το λέω επείδη μου δίνετε την εντύπωση ότι τα πιο πολλά project ΕΕ είναι γραμμένα σε spring. Πόση σημάσια θα έπρεπε να δώσω σε πιο απλά framework όπως python / ruby και τα λοιπά;
Zisis Pontikas
Apr 1, 2013, 11:16:44 AM4/1/13
to jh...@googlegroups.com
1. Ναι στο spring (μάθε το spring-core, spring-data και spring-web) και θα έχεις πολύ καλές γνώσεις για την αγορά εργασίας σήμερα
2. python / ruby σε βοηθάει να στήσεις γρήγορα project και αν έχεις τον χρόνο να ασχοληθείς για να βάλεις μία από τις δύο στο βιογραφικό σου (δηλαδή να μπορείς να στήσεις ένα projectaki σε mysql και ένα crud interface τουλάχιστο) θα έχεις άλλο ένα πολύ δυνατό πλεονέκτημα στην αγορά.
αυτά και από εμένα...
Ioannis Canellos
Apr 1, 2013, 11:18:21 AM4/1/13
to jh...@googlegroups.com
Κάτι που γενικά συμβαίνει έιναι ότι τα πράγματα κάνουνε συνεχώς κύκλους. Από το JEE5 πάρα πολύ κόσμος πήγε στο Spring. Η νέα τάση είναι να φεύγεις από το Spring και να πηγαίνεις σε άλλες λύσεις (π.χ. JEE6 ή ακόμα και σε custom λύσεις). Πολλά project/frameworks προσπαθούν να κόψουν το dependency από το Spring ή να το κάνουν εντελώς optional.
Παρόλο που έχει χάσει πολύ από τη λάμψη του, θεωρώ πως έχει ακόμα μεγάλη εκπαιδευτική αξία για κάποιον που θέλει να μάθει τα concepts του dependency injection κτλ. Δεν θα σπαταλούσα όμως χρόνο στο να ασχοληθώ με τα side projects του.
Για python/ruby δεν έχω προσωπική εμπείρια. Ξέρω όμως ότι κάποιες εταιρίες που ψάχνουν για ruby on rails developers, δεν βρίσκουν εύκολα. Μια και ξεκινάς τώρα την καριέρα σου ένα "hard to find skill" ίσως να σε βοηθήσει.
stavros anastasiadis
Apr 1, 2013, 11:53:59 AM4/1/13
to jh...@googlegroups.com
Θεωρώ ότι ως νέος στην αγορά εργασίας θα σε βοηθήσει περισσότερο να έχεις μια πιο σφαιρική εικόνα σχετικά με τα διάφορα frameworks που χρησιμοποιούνται από εταιρίες σε μεγάλα και μικρά projects, και όχι απαραίτητα πολλή εξειδίκευση.
Θα είναι φυσικά πολύ καλό για εσένα να μπορείς να κάνεις μικρά CRUD projects χρησιμοποιόντας οποιοδήποτε framework (όσα περισσότερα μπορείς), όπως είπε και ο Ζήσης, και από εκεί και πέρα -τις περισσότερες φορές- η εξειδίκευση έρχεται από την επαγγελματική εμπειρία.
Βέβαια, δεν θα ήταν δόκιμο από αυτό το user group να πάρεις την κατεύθυνση να ακολουθήσεις μια άλλη γλώσσα προγραμματισμού εκτός από Java :-), αλλά νομίζω ότι όλοι θα συμφωνήσουν μαζί μου αν σου πω ότι πρέπει να παίξεις με όλα τα frameworks και θα δεις ποιό σου αρέσει/σε βολεύει περισσότερο. Άλλωστε υπάρχουν άπειρα blogs που συνεχώς συγκρίνουν και δοκιμάζουν όλα τα frameworks (γράψε στο google "spring vs JEE").
Τέλος, ρίχνε καμιά ματιά και στις αγγελίες που υπάρχουν στα διάφορα sites. Εκεί πολλές φορές οι εταιρίες αναφέρουν ποιά frameworks χρησιμοποιούν και μπορείς να διακρίνεις και μόνος σου κάποια trends της αγοράς.
Τέλος, ρίχνε καμιά ματιά και στις αγγελίες που υπάρχουν στα διάφορα sites. Εκεί πολλές φορές οι εταιρίες αναφέρουν ποιά frameworks χρησιμοποιούν και μπορείς να διακρίνεις και μόνος σου κάποια trends της αγοράς.
Βασίλης Τσιρκινίδης
Apr 1, 2013, 1:01:17 PM4/1/13
to jh...@googlegroups.com
Ευχαριστώ πολύ για τις σμβουλές!
Anestis Georgiadis
Apr 1, 2013, 1:50:32 PM4/1/13
to jh...@googlegroups.com
Σπύρο,
Ενδιαφέρουσες σκέψεις! Θα πάρω τα items ανάποδα:
3. Ο Johnson είναι στην Typesafe. Ακόμα. Και η VMWare το τελευταίο καιρό προωθεί αρκετά περισσότερο Groovy και Grails από ότι το ίδιο το Spring (όχι εντελώς αλήθεια, ακόμα φαίνεται να σπρώχνει τον tc-server). Αυτό που εννοούσα είναι ότι δημιουργός/εταιρία που στήθηκε γύρω από το Spring ακολούθησε/εξερευνούν εναλλακτικές.
2. Σαν έννοιες το PAAS και η Enteprise Java είναι λίγο ασύμβατες, με την λογική ότι συνήθως τα enterprise apps τα κάνεις host κατεξοχήν in-house. Παρόλα αυτά υπάρχει το OpenShift (https://www.openshift.com), το οποίο θεωρητικά μπορεί να τρέξει οποιδήποτε standard JEE 6 app. Το θέμα του πως οι μεγάλες εταιρίες αγοράζουν JEE stack είναι μεγάλο και δεν έχει νόημα να το θίξουμε. Αυτό όμως που παίζει γενικά είναι ότι σαν στάνταρ είναι σίγουρα πολύ καλύτερα documented από οποιοδήποτε άλλο stack υπάρχει αυτή τη στιγμή, ανεξαρτήτου πλατφόρμας, και για πολλές εταιρίες η σιγουριά του στάνταρ όσον αφορά maintenance, availability ανθρώπων και vendor support είναι πιο σημαντική από οποιοδήποτε πλεονέκτημα έχει ένα εναλλακτικό stack σε development time.
Θα ξαναπώ πάντως ότι το version 6 του JEE έχει πετάξει πολύ από το boilerplate και τη σαβούρα που κουβάλαγαν τα προηγούμενα versions. Υπάρχει καλό support από πολλούς vendors, RAD εργαλεία που παίζουν με το standard (Forge), υπάρχει το lightweight web profile το οποίο απαλλάσει τον vendor από την ανάγκη υλοποίησης όλου του spec (και τον developer από την ανάγκη να περιμένει αιώνες τον app server να κάνει restart). Αυτός είναι και ο λόγος που πιστεύω ότι το Spring έχει πάρει την άγουσα για τα αποδυτήρια. Ίσως αξίζει να ασχοληθεί κάποιος μαζί του για να δει μια σειρά από design patterns, αλλά την ίδια γνώση θα αποκτήσει διαβάζοντας π.χ. το documentation του weld και το Design Patterns του GoF.
Εάν τώρα βγάλουμε το 'enterprise' από το παιχνίδι, ο δρόμος είναι ανοιχτός. Κατά περίπτωση overhyped, αλλά σίγουρα με τρομερή ποικιλία επιλογών. Προσωπικά εάν στοιχημάτιζα κάπου αυτό θα ήταν Scala και Typesafe stack, αλλά είμαι ελαφρώς biased :-)
1. Μην ξεχνάς ότι το JEE είναι umbrella spec για platform, ορίζει τα minimum facilities που θα σου παρέχει ένας application server. Σχεδόν όλη η γκάμα των ακρωνυμίων είναι διαθέσιμη και εκτός JEE, και ο καθένας πια μπορεί να κάνει roll-out το δικό του execution platform. Αυτό που θέλω να πω είναι ότι δεν μπορείς να βλέπεις το JEE με άλλο τρόπο από τον στάνταρ, το να χρησιμοποιείς Spring ή να κάνεις roll-out τη δική σου μίξη από τα specs που χρειάζεσαι είναι ένας άλλος, εναλλακτικός τρόπος να γράφεις εφαρμογές. Αυτό που πάντα πρέπει να έχει κάποιος στο μυαλό, _ειδικά_ σε enterprise landscape, είναι σε πιο βαθμό θέλει να δεθεί με ένα vendor-specific technology, όσο καλό και να είναι (π.χ. tc-server, GWT, you-name-it), ή με το stack που ρόλλαρε κάποιος καταπληκτικός architect ο οποίος όμως σε 1-2 χρόνια μπορεί να την έχει κάνει για πρασινότερα λιβάδια.
Ουφ, βαριές κουβέντες πιάσαμε, και η εμπειρία έχει αποδείξει ότι αυτές ανταλλάσονται καλύτερα πάνω από τραπέζι με μπύρες :) Btw ποιοί άλλοι θα είναι στο Scala meeting την Πέμπτη;
Φιλικά,
Ανέστης
2013/4/1 Σπύρος Αναστασόπουλος <winw...@gmail.com>
Anestis Georgiadis
Apr 1, 2013, 2:09:51 PM4/1/13
to jh...@googlegroups.com
Βασίλη,
Η προσωπική μου άποψη είναι να επενδύσεις χρόνο μελετώντας, ή ακόμα καλύτερα συμμετέχοντας, σε projects στο github που σου προκαλούν ενδιαφέρον και θα σε κρατήσουν engaged. Η επιλογή της πλατφόρμας είναι περισσότερο προσωπική υπόθεση, και λιγότερο career choice, τουλάχιστον μακροπρόθεσμα, και το σίγουρο είναι ότι σε 10 χρόνια από τώρα τίποτα από αυτά που συζητάμε δεν θα βρίσκεται μαζί μας. Δυστυχώς στην στρεβλή αγορά της Ελλάδας η επιλογή των CVs γίνεται ακόμα με λάθος κριτήρια, αλλά κάποια στιγμή θα γίνουμε άνθρωποι κι εμείς.
Έχοντας πει αυτό η ruby και η python είναι εργαλεία του σατανά! Για το ΘΕΟ μακρυά! :-) Joking aside, στην Ελλάδα παίζει κυρίως Java και .NET στα μεγάλα μαγαζιά, ενώ μικρές εταιρίες, startups κλπ χρησιμοποιούν πολύ RoR, python, JS κλπ.
Φιλικά,
Ανέστης
Paris Apostolopoulos
Apr 1, 2013, 2:12:35 PM4/1/13
to jh...@googlegroups.com
@Ανέστης internal joke - διαβάζω τα post σου και με κάνεις πολύ περήφανο χεχεχε!!! Keep it up.
Εγώ εχω μια πολυ πιο direct θέση την οποία δεν διστάζω να εκφράσω εδώ και χρόνια. Ποτέ δεν μου άρεσε το Spring σαν τεχνολογία αλλά συμφωνώ ήταν μια άρτια υλοποίηση κάποιων pattern/ τεχνικών. Χαίρομαι που έγινε ο μοχλός έτσι ώστε η τότε Sun και οι partners να ταρακουνηθουν και να φτάσουμε στο jEE6 αλλά και σε λίγο καιρό στο Draft 7 (JSR 342) -http://jcp.org/en/jsr/detail?id=342, θεωρώ λογικό που φθίνει σε usage. Χαίρομαι που μετά από χρόνια βλέπω ξανα 2-3 διαφορετικούς ee container και διάφορα profile (αντί για ένα single core), μερικές επιλογές σε υλοποιήσεις web (άσχετα αν το JSF ακόμα μας πονάει...) κτλ κτλ.
Μια άσχετη σφήνα, ποτέ δεν καταλάβα γιατί οι νέες γλώσσες πρέπει αν ειναι συναντικά κουλές βλέπε Scala αντί να πάνε ένα βήμα παραπέρα σε ήδη καλά paradigms..πχ..η C# παραμένει μια ΠΟΛΥ ΑΞΙΟΛΟΓΗ ΓΛΩΣΣΑ , όπως φυσικά και η ίδια η Java..που αργά μεν αλλά σταθερά θα εξελιχθεί. Εξάλλου ειναι φανερό πια ότι όλα τα λεφτά πάνε στο JVM. Σποντίτσα για την Scala...μέχρι και h Clojure μου φαίνετια πιο λογική (*προσωπικά)
Τέλος, πολλοί μουρμουράνε πολλοί ρωτάνε, το ξέρω ότι εδώ και μήνες δεν έχουμε κανονίσει κάτι, λιγο οι υποχρεώσεις λίγο η γενικότερη κατάσταση, δεν μαζεύουμε και ένα βασικό κορμό παρουσιάσεων για να μαζευτούμε. Ίσως ένα java beer gatherting να είχε μεγαλύτερο νόημα, θα δημιουργήσω άλλο thread για να μην χαλάσω την εδώ συζήτηση.
Ευχαριστώ :)
Εγώ εχω μια πολυ πιο direct θέση την οποία δεν διστάζω να εκφράσω εδώ και χρόνια. Ποτέ δεν μου άρεσε το Spring σαν τεχνολογία αλλά συμφωνώ ήταν μια άρτια υλοποίηση κάποιων pattern/ τεχνικών. Χαίρομαι που έγινε ο μοχλός έτσι ώστε η τότε Sun και οι partners να ταρακουνηθουν και να φτάσουμε στο jEE6 αλλά και σε λίγο καιρό στο Draft 7 (JSR 342) -http://jcp.org/en/jsr/detail?id=342, θεωρώ λογικό που φθίνει σε usage. Χαίρομαι που μετά από χρόνια βλέπω ξανα 2-3 διαφορετικούς ee container και διάφορα profile (αντί για ένα single core), μερικές επιλογές σε υλοποιήσεις web (άσχετα αν το JSF ακόμα μας πονάει...) κτλ κτλ.
Μια άσχετη σφήνα, ποτέ δεν καταλάβα γιατί οι νέες γλώσσες πρέπει αν ειναι συναντικά κουλές βλέπε Scala αντί να πάνε ένα βήμα παραπέρα σε ήδη καλά paradigms..πχ..η C# παραμένει μια ΠΟΛΥ ΑΞΙΟΛΟΓΗ ΓΛΩΣΣΑ , όπως φυσικά και η ίδια η Java..που αργά μεν αλλά σταθερά θα εξελιχθεί. Εξάλλου ειναι φανερό πια ότι όλα τα λεφτά πάνε στο JVM. Σποντίτσα για την Scala...μέχρι και h Clojure μου φαίνετια πιο λογική (*προσωπικά)
Τέλος, πολλοί μουρμουράνε πολλοί ρωτάνε, το ξέρω ότι εδώ και μήνες δεν έχουμε κανονίσει κάτι, λιγο οι υποχρεώσεις λίγο η γενικότερη κατάσταση, δεν μαζεύουμε και ένα βασικό κορμό παρουσιάσεων για να μαζευτούμε. Ίσως ένα java beer gatherting να είχε μεγαλύτερο νόημα, θα δημιουργήσω άλλο thread για να μην χαλάσω την εδώ συζήτηση.
Ευχαριστώ :)
Thomas Pliakas
Apr 1, 2013, 3:08:09 PM4/1/13
to jh...@googlegroups.com
Καλησπέρα και από εμένα,
από ότι φαίνεται όλες οι λύσεις στο enterprise πεδίο έχουν αρχίσει και ωριμάζουν αρκετά. Το Spring είχε μια πιο κατανοητή υλοποίηση κάποιων partners, και σε μερικές περιπτώσεις και πολύ καλή υλοποίηση. Πολλές φορές με το Spring οι developers νοιώθουν αρκετά ασφαλείς (ψυχολογικά κυρίως).
Είναι απόλυτα φυσικό όλες οι τεχνολογίες να βελτιώνονται και θα συμφωνήσω με τον Πάρη ότι το JEE 6 έχει αρχίσει να βελτιώνεται ραγδαία και να γίνεται ακόμα πιό κατανοητό και προσιτό. Στις παλαιότερες εκδόσεις, κατά την δική μου άποψη, η υλοποίηση μια εφαρμογής σε JEE ήταν αρκετά δύστροπή και πολλές φορές ήθελε ένα αρκετά solid background σε patterns, τεχνικές και ήταν αρκετά bundled με τους διάφορους application servers. Πάντως είναι απόλυτα λογικό να φθίνει το Spring με τον καιρό, αν και πιστεύω ότι είναι αρκετά δύσκολο, ειδικά σε μεγάλα έργα να γίνεί μεταφορά από μια τεχνολογία σε μια άλλη. Προσωπικά πιστεύω ότι καλό είναι κάποιος να δίνει βάση στην "θεωρία", κατανόηση patterns, τεχνικών έτσι ώστε να μπορεί να καταλαβαίνει την χρήση της κάθε τεχνολογίας, τα υπέρ και τα κατά και να προχωρεί έχοντας γνώση των αδυναμιών της κάθε τεχνολογίας και με τον καιρό να μπορεί να διορθώνει τις αδυναμίες της εφαρμογής που υλοποιεί.
Σχετικά με την σφήνα του Πάρη, συμφωνώ και εγώ μαζί του, και μπορώ να ομολογήσω ότι μετά την καθυστέρηση που υπήρξε στο JDK6, JDK7, παρατηρείται μια γρήγορη ανάπτυξη στην γλώσσα και στις δυνατότητες που πρόκειται να προσφέρει. Υπάρχουν αρκετά καινούρια πράματα τόσο στο concurrency όσο και σε άλλους τομεις (lambda expressions, etc,. βλέπε upcoming jdk8. που κατά την γνώμη μου την κάνει ακόμα πιό ενδιαφέρουσα. Γενικά είμαι αντίθετος στην χρήση πολλών γλωσσών στις υλοποιήσεις, γιατί κάνουν την εφαρμογή αρκετά δύστροπή και δύσκολα διαχειρίσιμη όταν αυτή γίνεται αρκετά μεγάλη (millions lines of codes). Άσε που μερικές φορές και το testing μετά γίνεται εφιάλτης.
@Πάρης
Η Clojure φαίνεται αρκετά ενδιαφέρουσα ... ειδικά λόγω και της Lisp dialect :)
Χαιρετώ
Θωμάς
George Georgovassilis
Apr 3, 2013, 5:00:48 AM4/3/13
to jh...@googlegroups.com
@Πάρη: σε ευχαριστώ για την βιβλιογραφία, διαβάζω (αργά) το EJB in Action και το rant εναντίων του αναιμικού μοντέλου δεδομένων :) Με ενδιέφερε όπως έγραψα κυρίων να δω πως μπορεί να δομηθεί μια αρχιτεκτονική με ένα πλήρες μοντέλο δεδομένων, οψόμεθα.
@Ανέστη: το project σου φαίνεται να έχει ενδιαφέρον, ίσως να μας το έδειχνες σε μια από τις επόμενες παρουσιάσεις; Η απορία μου εστιάζει στο αν το JEE6 επιτρέπει μια αρχιτεκτονική που δεν βασίζεται στο αναιμικό μοντέλο και τον καθαρό διαχωρισμό ευθυνών και πως θα γινόταν αυτό καλύτερα. Για το KISS και DRY συμφωνούμε, αλλά πες πως θέλω και καλά να αυτοπυροβοληθώ για την εμπειρία :-) Λ.χ. ο συγγραφέας του EJB in Action αναφέρει ως πλεονέκτημα το ότι μπορείς να δώσεις session beans και entity beans απευθείας στο view. Δεν έχω προχωρήσει αρκετά στο βιβλίο ώστε να δω πως σκοπεύει να το κάνει, μέχρι να φτάσω εκεί βλέπω με καχυποψία κάτι τέτοιο γιατί μου θυμίζει εποχές που κάναμε όλες τις δουλειές μέσα σε JSP.
Testing: Δυστυχώς δεν έχω δει το arquilian ακόμα, ειδάλλως μου λείπει κάτι παρόμοιο σε δυνατότητες με το spring testing. Μαθαίνω για το embedded glassfish οτι βοηθάει την κατάσταση και μετά ένα μάτσο πράγματα που δεν δουλεύουν επειδή υποστηρίζει μόνο ένα light profile. Ένα σύνηθες επιχείρημα που διαβάζω είναι πως σε πραγματικό unit testing δεν χρειάζεσαι EJB/Spring dependencies. Προσωπικά βασίζομαι στην άνεση που μου δίνει το μισο-unit-μισο-integration testing του να σηκώνεις ένα application context με μερικά έτοιμα services και μια ψευτο-βάση και δεν θα ήθελα να δουλέψω μόνο με απόλυτο unit testing και mocking.
Apropos Activiti: το χρησιμοποιείτε για έλεγχο ροής ή για κανόνες; πόσο % του ελέγχου/κανόνων εκτιμάς ότι υλοποιήσατε σε activiti;
@Ανέστη, @Πάρη:
Αναφέρεις την υλοποίηση των προδιαγραφών του EJB3 και φοβάμαι πως κρύβει τον κίνδυνο του vendor lock-in ο οποίος είναι ο κυριότερος λόγος που κρατάει το JEE6 μακριά από πολλούς servers. Π.χ. η απλή εφαρμογή που έγραψα το προηγούμενο ΣΚ τρέχει αυτήν την στιγμή μόνο σε glassfish και δεν δουλεύει με jboss (δεν είχα χρόνο να το δω πιο κοντά).
Για την αποδοχή της τεχνολογίας: οι θέσεις για spring [1] είναι αρκετά περισσότερες από αυτές για EJB [2], ειδικά η ζήτηση για EJB3 ή JEE6 είναι σχεδόν ανύπαρκτη [3]. Δεν ξέρω πως να ερμηνεύσω τα ευρήματα, εικάζω πως η υφιστάμενη βάση του παλιού EJB μοιράζεται σε Spring και JEE6 ενώ νέα έργα μάλλον δεν γίνονται σε σημαντικό βαθμό με ΕJB(3)/JEE6.
[1] http://jobsuche.monster.de/Jobs/?q=spring&cy=de
[2] http://jobsuche.monster.de/Jobs/?q=ejb3-jee6-ejb&cy=de
[3] http://jobsuche.monster.de/Jobs/?q=jee6-ejb3&cy=de
@Ανέστη: το project σου φαίνεται να έχει ενδιαφέρον, ίσως να μας το έδειχνες σε μια από τις επόμενες παρουσιάσεις; Η απορία μου εστιάζει στο αν το JEE6 επιτρέπει μια αρχιτεκτονική που δεν βασίζεται στο αναιμικό μοντέλο και τον καθαρό διαχωρισμό ευθυνών και πως θα γινόταν αυτό καλύτερα. Για το KISS και DRY συμφωνούμε, αλλά πες πως θέλω και καλά να αυτοπυροβοληθώ για την εμπειρία :-) Λ.χ. ο συγγραφέας του EJB in Action αναφέρει ως πλεονέκτημα το ότι μπορείς να δώσεις session beans και entity beans απευθείας στο view. Δεν έχω προχωρήσει αρκετά στο βιβλίο ώστε να δω πως σκοπεύει να το κάνει, μέχρι να φτάσω εκεί βλέπω με καχυποψία κάτι τέτοιο γιατί μου θυμίζει εποχές που κάναμε όλες τις δουλειές μέσα σε JSP.
Testing: Δυστυχώς δεν έχω δει το arquilian ακόμα, ειδάλλως μου λείπει κάτι παρόμοιο σε δυνατότητες με το spring testing. Μαθαίνω για το embedded glassfish οτι βοηθάει την κατάσταση και μετά ένα μάτσο πράγματα που δεν δουλεύουν επειδή υποστηρίζει μόνο ένα light profile. Ένα σύνηθες επιχείρημα που διαβάζω είναι πως σε πραγματικό unit testing δεν χρειάζεσαι EJB/Spring dependencies. Προσωπικά βασίζομαι στην άνεση που μου δίνει το μισο-unit-μισο-integration testing του να σηκώνεις ένα application context με μερικά έτοιμα services και μια ψευτο-βάση και δεν θα ήθελα να δουλέψω μόνο με απόλυτο unit testing και mocking.
Apropos Activiti: το χρησιμοποιείτε για έλεγχο ροής ή για κανόνες; πόσο % του ελέγχου/κανόνων εκτιμάς ότι υλοποιήσατε σε activiti;
@Ανέστη, @Πάρη:
Αναφέρεις την υλοποίηση των προδιαγραφών του EJB3 και φοβάμαι πως κρύβει τον κίνδυνο του vendor lock-in ο οποίος είναι ο κυριότερος λόγος που κρατάει το JEE6 μακριά από πολλούς servers. Π.χ. η απλή εφαρμογή που έγραψα το προηγούμενο ΣΚ τρέχει αυτήν την στιγμή μόνο σε glassfish και δεν δουλεύει με jboss (δεν είχα χρόνο να το δω πιο κοντά).
Για την αποδοχή της τεχνολογίας: οι θέσεις για spring [1] είναι αρκετά περισσότερες από αυτές για EJB [2], ειδικά η ζήτηση για EJB3 ή JEE6 είναι σχεδόν ανύπαρκτη [3]. Δεν ξέρω πως να ερμηνεύσω τα ευρήματα, εικάζω πως η υφιστάμενη βάση του παλιού EJB μοιράζεται σε Spring και JEE6 ενώ νέα έργα μάλλον δεν γίνονται σε σημαντικό βαθμό με ΕJB(3)/JEE6.
[1] http://jobsuche.monster.de/Jobs/?q=spring&cy=de
[2] http://jobsuche.monster.de/Jobs/?q=ejb3-jee6-ejb&cy=de
[3] http://jobsuche.monster.de/Jobs/?q=jee6-ejb3&cy=de
Reply all
Reply to author
Forward
0 new messages