Design & Architecture

Απ: Λιγότερα roundtrips vs Modularity

Dimitris Papadimitriou — Tue, 12 Jan 2010 00:05:46 GMT

Δεν απαντώ επίτηδες περιμένοντας να ακουστούν και άλλες γνώμες.

Απ: Λιγότερα roundtrips vs Modularity

anjelinio — Mon, 11 Jan 2010 22:45:50 GMT

Εγώ θα πήγαινα κατευθείαν στο δ. με μια γερή δόση caching και asynchronicity. Αν μοντελοποιήσεις τις κλήσεις του εκάστοτε UI component σε κάποιου είδους IDataRequest interface, και το κεντρικοποιήσεις - ότι ακριβώς προτείνεις δηλαδή αν δεν κάνω λάθος - πιστεύω ότι είσαι πολύ πιο ευέλικτος σε επιλογές και refactoring όταν και όπου χρειαστεί.

Επίσης είναι πολύ πιθανό να καταλήξεις σε ένα όμορφο generic client - server design, το οποιό θα χρησιμοποιήσεις σε διάφορα projects, άσχετα με τον τύπο του client ( ο κόσμος όλος δεν είναι ακόμα WPF ή Silverlight ... )

Βέβαια, αυτό σημαίνει οτι θα πρέπει να "ακροβατήσεις" λίγο στην αρχή μεταξύ ευελιξίας και πραγματικότητας ( ... φαντάζομαι ότι μπορεί να μπλέξεις για .. αιώνες προσπαθώντας να καλύψεις υποπεριπτώσεις υποπεριπτώσεων, και όπως όλοι ξέρουμε ο χρόνος δεν είναι άπειρος ... ) στο design σου, αλλά .. πως να το πώ ... it feels right φίλε :D

Απ: Λιγότερα roundtrips vs Modularity

Panagiotis Kefalidis — Mon, 11 Jan 2010 03:37:49 GMT

Εξήγησε μας λίγο παραπάνω γιατί θέλεις να υπάρχει αυτή η μέθοδος η οποία μαζεύει όλα τα request και επιστρέφει όλα τα responses? Εννοείς ένα ένα; Δηλαδή να του δίνεις το request id πχ και να σου επιστρέφει το response το οποίο μπορεί να έχει πάρει ήδη (το οποίο το τραβάει απο το array)?

Εάν είναι ασύγχρονο υπάρχει callback method η οποία καλείτε, δεν χρειάζεται να φτιάξεις δικό σου.

Κάπου σε χάνω, για ρίξε λίγο φως.

Απ: Λιγότερα roundtrips vs Modularity

Dimitris Papadimitriou — Mon, 11 Jan 2010 03:19:50 GMT

Panagiotis Kefalidis:

Ένα flag το οποίο υποδηλώνει ότι όλα τα επόμενα calls πρέπει να φύγουν σαν batch θα καλύψει αυτό το scenario (Initilization της εφαρμογής κλπ) χωρίς να αυξήσει την πολυπλοκότητα.

Καλή ιδέα κι αυτή! Κάνει περισσότερο ευέλικτο το κόλπο. Πάντα με τη χρήση μιας generic composite method όμως που θα παίρνει όλα τα requests και θα επιστρέφει όλα τα responses.

Απ: Λιγότερα roundtrips vs Modularity

Panagiotis Kefalidis — Mon, 11 Jan 2010 03:10:40 GMT

A οκ για το σχήμα, makes sense τώρα.

Δεν νομίζω ότι θα πρέπει να το κάνεις τόσο πολύπλοκο απλά για να καλύψεις κάποιες περιπτώσεις. Ένα flag το οποίο υποδηλώνει ότι όλα τα επόμενα calls πρέπει να φύγουν σαν batch θα καλύψει αυτό το scenario (Initilization της εφαρμογής κλπ) χωρίς να αυξήσει την πολυπλοκότητα. Θα είναι δουλειά του data module να τα μαζέψει αυτά σε ένα call και να τα στείλει.

Απ: Λιγότερα roundtrips vs Modularity

Dimitris Papadimitriou — Mon, 11 Jan 2010 02:43:22 GMT

ok, άρα προτείνεις κυρίως α και β.

σημείωση: είναι λίγο απλοϊκό το σχήμα μου :), μην πιάνεστε από το αυτό. Απλά ήθελα να δείξω ένα παράδειγμα όπου μια κλήση ενεργοποιήτε επειδή υπάρχει το module 1 και μια άλλη λόγω του module 2.

Να προσθέσω ότι η περίπτωση δ είναι ίσως χρήσιμη και αξίζει την πολυπλοκότητά της σε ιδιαίτερες περιπτώσεις. π.χ. κατά το άνοιγμα ενός client ξέρω ότι θα γίνουν μερικές συγκεκριμένες κλήσεις, οπότε τις συγκεντρώνω σε μια κλήση και τις εκτελώ μαζί. Βοηθά αρκετά στη μείωση του χρόνου που χρειάζεται για να ανοίξει ένας client.

Απ: Λιγότερα roundtrips vs Modularity

Panagiotis Kefalidis — Mon, 11 Jan 2010 02:14:12 GMT

Έτσι όπως το έχει σχεδιάσει πάντως στην εικόνα, δεν είναι κι ότι καλύτερο. Τα modules τα οποία έχουν να κάνουν με data πρέπει να καλέσουν το "module data". Κοινώς να καλέσουν το module το οποίο είναι υπεύθυνο να δώσει δεδομένα στους άλλους (κάτι σαν το δ) που περιέγραψες).

Εκεί επάνω θα εφαρμόσεις Caching και Asynchronous calls ώστε να γλύτωσεις round-trip με την βάση αλλα και να για μπορείς να χρησιμοποιήσεις τεχνολογίες όπως το Windows Server AppFabric (former Velocity) και το memcached εύκολα, εφόσον όλα τα data calls είναι "συγκεντρωμένα". Εφόσον τα request θα εκτελούνται ασύγχρονα δεν χρειάζεται να έχεις ένα array απο requests κι ενα array απο responses κλπ. Ασύγχρονο είναι, όσο έρχονται, σερβίρεις.

Λιγότερα roundtrips vs Modularity

Dimitris Papadimitriou — Sun, 10 Jan 2010 22:28:44 GMT

Θα σας εκφράσω μια σκέψη μου και μου λέτε πως το βλέπετε κι εσείς.

Λιγότερα Roundtrips: Όταν έχεις μια multi-tier εφαρμογή προσπαθείς να ελαττώσεις όσο γίνεται τις κλήσεις από το ένα tier στο άλλο (συνήθως μεταξύ του end-user client και του application server). Ο σκοπός είναι πάντα να βελτιώσεις το performance και το scalability. Δηλαδή πιο γρήγορος client και λιγότερα resources στον server.

Modularity: Όταν έχεις ένα modular client (modules προστίθενται/ενεργοποιηούνται ανάλογα με configuration και άλλα κριτήρια) προσπαθείς να κρατήσεις αυτά τα modules ανεξάρτητα το ένα από το άλλο. π.χ. στην εικόνα υπάρχουν 2 modules που καλούν τον server για να πάρουν τα data που θέλουν να εμφανίσουν. Δεν γίνεται μια κλήση για να φέρει τα data και για τα δυο, γιατί πολύ απλά δεν είναι απαραίτητο ότι και τα δυο αυτά modules θα είναι ορατά. Επίσης δεν είναι απαραίτητο ότι είναι ορατά μόνο αυτά. Μπορεί αν υπάρχουν και άλλα ορατά modules!

Τι κάνουμε λοιπόν (με σειρά ευκολίας και λιγότερων συμβιβασμών);

α) Cache: Όπου είναι δυνατόν προσπαθούμε να χρησιμοποιήσουμε κάποιας μορφής cache. Έτσι αφήνουμε τα modules να κάνουν τις κλήσεις που θέλουν ανεξάρτητα από τα άλλα (καλό modularity), αλλά τα data να έρχονται από την cache χωρίς να γίνεται κλήση στον server (λιγότερα roundtrips).

β) Asynchronous calls: Χρησιμοποιούμε ασύγχρονες κλήσεις για το φόρτωμα των δεδομένων. Δεν γλιτώνουμε roundtrips αλλά πιθανότατα κάνουμε τον client να λειτουργεί πιο γρήγορα μια που τα modules θα καλούν τον server παράλληλα και όχι το ένα μετά το άλλο.

γ) Sacrifice: Προσπαθούμε να ομαδοποιήσουμε κάποιες κλήσεις θυσιάζοντας το modularity. π.χ. ενώνουμε κάποια modules που θεωρούμε ότι το πιθανότερο είναι να λειτουργούν ταυτόχρονα.

δ) Composite Server Calls: Δημιουργούμε κάποιους mediators/proxies στον client τους οποίους καλούν τα modules αντί να καλούν απευθείας τον server. Αυτοί οι mediators γνωρίζουν ποια modules είναι ενεργά και ξέρουν ότι κάποια στιγμή θα λάβουν κλήσεις από αυτά. Καλούν λοιπόν μια φορά τον server και φέρνουν όλα τα data που θέλουν τα modules χρησιμοποιώντας μια composite server method που παίρνει ένα array από requests (ένα request από κάθε module) και επιστρέφει ένα array από responses. Όταν πάρουν την απάντηση με το array από τα responses το κρατάνε κάπου και όταν τα modules καλούν δίνουν έτοιμες τις απαντήσεις.