Thiseas:

Όχι πια 3-tier, N-tier και σε "πείσμα" όλων των συγγραφέων του κόσμου!!  εμείς έχουμε διαπιστώσει οτι η μεθοδολογία (2-tier, thin-client και business logic στην βάση - σε SPs ) είναι από πλευράς perfomance η καλύτερη δυνατή....

Αυτό που περιγράφεις είναι η αρχιτεκτονική (όχι μεθοδολογία) client/server. Ο λόγος που υπάρχει η 3-tier είναι ότι η client/server δεν είναι scalable. Πετυχαίνεις καλύτερη απόδοση όταν έχεις 200 clients με μόνο 20 ελεγχόμενες συνδέσεις συνολικά στη βάση, παρά όταν έχεις 200 συνδέσεις. Γι αυτό το λόγο υπάρχουν τα Transaction Processing Monitors (από τη δεκαετία του 80, αν όχι νωρίτερα), γι αυτό υπάρχει το COM+ και το JBOSS. Πρώτα και κύρια, είναι transaction processing monitors, τα οποία ελέγχουν την πρόσβαση στο Database Server. Και δεν μιλάμε για πολυσύχναστα web sites, όπου τα transactions μπορούν να είναι εκατοντάδες το λεπτό. Εξάλλου, και τα TPC benchmarks περιλαμβάνουν οπωσδήποτε τη χρήση TPM.

Η αρχιτεκτονική N-tier δεν είναι θέμα συγγραφέων, αλλά ουσίας. Ο λόγος που η client/server αρχιτεκτονική δεν είναι scalable είναι αρκετοί και βασικοί:

• Όταν ο κάθε client έχει μία σύνδεση στο server, ο server αναγκάζεται να συντηρεί πολύ περισσότερες συνδέσεις απ' όσες χρειάζεται
• Όσο αυξάνονται οι ταυτόχρονες συνδέσεις, αυξάνονται τα blocks μεταξύ τους, γεωμετρικά. Όσο καλά και να γράψεις τα sprocs σου, τα blocks θα συνεχίσουν να αυξάνονται. Ταυτόχρονα, θα αυξάνεται ο κίνδυνος deadlock.
• Δεν υπάρχει τρόπος να περιοριστούν οι ταυτόχρονες συνδέσεις. Ο server μπορεί να ικανοποιήσει πολύ γρηγορότερα 200 κλήσεις αν επιτρέπονται μόνο 20 τη φορά, παρά αν προσπαθήσει να τις εκτελέσει και τις 200.

Αντίθετα, χρησιμοποιώντας μία καλή αρχιτεκτονική 3-tier (η οποία περιλαμβάνει τη χρήση του COM+ ως TPM) μπορείς να ορίσεις ένα ορισμένο αριθμό συνδέσεων προς το server. Οι επιπλέον κλήσεις θα περιμένουν να ελευθερωθεί μία σύνδεση για να προχωρήσουν.

Τέλος, ο τρόπος αντιμετώπισης του collation είναι μάλλον υπερβολικός και κατά πάσα πιθανότητα κρύβει προβλήματα στη διαδικασία. Εκτός και χρησιμοποιείς varchar αντί nvarchar, το collation δεν δημιουργεί πολλά προβλήματα. Όπως και να έχει όμως, όταν εγκαθιστάς μία νέα βάση, ένα νέο πίνακα, ακόμα και ένα νέο column, εσύ ορίζεις πιό είναι το επιθυμητό collation. Για να υπάρχει θέμα collation, κάποιο βήμα πρέπει να μένει ανεξέλεγκτο. Το upgrade μίας βάσης χρειάζεται περισσότερη προσοχή από το απλό Generate Scripts.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Παναγιώτης Καναβός:

Αυτό που περιγράφεις είναι η αρχιτεκτονική (όχι μεθοδολογία) client/server. Ο λόγος που υπάρχει η 3-tier είναι ότι η client/server δεν είναι scalable. Πετυχαίνεις καλύτερη απόδοση όταν έχεις 200 clients με μόνο 20 ελεγχόμενες συνδέσεις συνολικά στη βάση, παρά όταν έχεις 200 συνδέσεις. Γι αυτό το λόγο υπάρχουν τα Transaction Processing Monitors (από τη δεκαετία του 80, αν όχι νωρίτερα), γι αυτό υπάρχει το COM+ και το JBOSS. Πρώτα και κύρια, είναι transaction processing monitors, τα οποία ελέγχουν την πρόσβαση στο Database Server.

[1]. thnx για την διόρθωση.... αν και στην προκειμένη περίπτωση δεν με απασχολεί η "ονοματολογία" ούτε και η φιλοσοφία της διαφοράς "μεθόδου" και "αρχιτεκτονικής". Θα μου επιτρέψεις να επιμείνω στην λέξη "μεθοδολογία".

Παναγιώτης Καναβός:

Και δεν μιλάμε για πολυσύχναστα web sites, όπου τα transactions μπορούν να είναι εκατοντάδες το λεπτό.

[2]. Δεν μιλάω μόνο για web sites, ... για να γίνω πιο συγκεκριμένος δεν είχα στο μυαλό μου καθόλου web εφαρμογές, αλλά τοπικά δίκτυα! Ο αριθμός των χρηστών ειναι συγκεκριμένος και όχι μεταβλητός και άγνωστος. Οι 2 προσεγγίσης έχουνε ΤΕΡΑΣΤΙΑ διαφορά!! Μα ΤΕΡΑΣΤΙΑ!!

Παναγιώτης Καναβός:

Το upgrade μίας βάσης χρειάζεται περισσότερη προσοχή από το απλό Generate Scripts.

Τι ακρβώς εννοείς? Νομίζω το Post δεν "μιλάει" για DB-upgrade γενικά, αλλά για κάτι συγκεκριμενο που αντιμετωπίζουν όσοι δουλεύουν την πληροφορική στο "χαράκωμα".... θα μου επιτέψεις να πω!
Εγώ μίλησα για Stored Procedures συγκεκριμένα.
Νομίζω οτι τα πλαίσια του.... "upgrade" ορίστηκαν από τον φίλο που έβαλε το post.

Όμως, λέγοντας ένα γενικό θεωρητικό κανόνα όπως αυτόν δεν βοηθάς κανέναν.
Εσύ τι ακριβώς εννοείς "urgrades" γιατί αν εννοείς ένα γενικό "upgrade", tables, triggers, SPs, UDFs, indexes etc etc τότε το πράγμα αλλάζει και δεν είναι απλό καθόλου.
Θα θεωρειθεί γελοίο να έλεγα οτι αυτό το "upgrade" πετυχαίνεται με ένα Generate Scripts.
Μια που το έφερε η κουβέντα όμως μπορείς να το αιτιολογήσεις?
Τι περισσότερη προσοχή χρειάζετε και που?



PS: BTW.... καλώς σας βρήκα!

---

Nothing to declare...

Υπάρχει μεγάλη διαφορά μεταξύ των δύο προσεγγίσεων, εις βάρος της client/server, υπό τον όρο ότι έχουν υλοποιηθεί σωστά και οι δύο. Από τη μία οι stored procedures θα πρέπει να χρησιμοποιούν transactions όπου χρειάζονται, να μην χρησιμοποιούνται cursors, να μην υπάρχουν υπερβολικά locks. Από την άλλη, τα COM+ αντικείμενα θα πρέπει να είναι stateless, να χρησιμοποιείται connection pooling και transaction pooling, να μην εκτελούνται σε κώδικα όσα θα πρέπει να εκτελούνται σε stored procedures και το αντίστροφο. Σε αυτή την περίπτωση, μπορείς να εξυπηρετήσεις πολύ περισσότερους clients με 3-tier αρχιτεκτονική παρά με client/server.

Αυτό δεν είναι θεωρία αλλά πείρα "από τα χαρακώματα" όπως λες κι εσύ. Ούτε και τα νούμερα ήταν τυχαία. Είχα υπόψη μία πλατφόρμα στην οποία δούλευα πριν από 7 χρόνια, όπου είχαμε 200 ταυτόχρονους clients, ένα Windows 2000 COM+ server και 1 clustered SQL Server 2000. Στον COM+ server υπήρχε object pooling (τότε δεν υπήρχε το connection pooling του .NET) το οποίο επέτρεπε περίπου 20 ταυτόχρονα connection το μέγιστο. Σε συνδυασμό με τα automatic transactions μπορέσαμε να εξυπηρετήσουμε όλο τον όγκο με αρκετή ευκολία, καθώς δεν υπήρχε τόσο μεγάλη ανάγκη micro-tuning των stored procedures για να αποφύγουμε τα locks. Αν είχαμε 200 ταυτόχρονες συνδέσεις, θα ήταν πολύ δυσκολότερο να πετύχουμε την ίδια απόδοση. Το συγκεκριμένο σύστημα σε stress test έφτασε τους 10.000 simulated χρήστες, με τον καθένα να εκτελεί πολλά transactions ανά λεπτό, πριν ... σκάσει το switch του ορόφου.

Θα καταλαβαίνεις πλέον ότι όταν ανέφερα τα web sites αναφερόμουν απλά σε μία ακόμα πιο δύσκολη περίπτωση. Εξάλλου τα χαρακτηριστικά ενός transactional συστήματος δεν επηρεάζονται από το αν οι clients είναι fat, thin, web, mobile, SMS ή με σήματα καπνού. Το μόνο που αλλάζει είναι ο όγκος των συναλλαγών. Ένα web site μπορεί να δημιουργήσει πολύ μεγαλύτερο όγκο συναλλαγών από ένα εσωτερικό σύστημα.

Αυτή η κουβέντα πάντως ξεφεύγει πλέον από την αρχική ερώτηση, και μάλλον ταιριάζει στο forum της Αρχιτεκτονικής.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Είναι λίγο γενικό και αόριστο το statement

Όχι πια 3-tier, N-tier και σε "πείσμα" όλων των συγγραφέων του κόσμου!!  εμείς έχουμε διαπιστώσει οτι η μεθοδολογία (2-tier, thin-client και business logic στην βάση - σε SPs ) είναι από πλευράς perfomance η καλύτερη δυνατή....

και υπάρχει κίνδυνος παρεξήγησης, όπως και φάνηκε άλλωστε, καθώς ο Παναγιώτης κατάλαβε ότι αναφέρεσαι σε distributed enteprise applications. Οπότε αρχικά θα πρέπει να προσδιοριστεί για το τι εφαρμογές μιλάμε. Κατόπιν, θα πρέπει να προσδιοριστεί η έννοια του performance. Ας πούμε, ένα μετρήσιμο μέγεθος, όπως είπε και ο Παναγιώτης, είναι τα TPC benchmarks. Εσύ τι εννοείς όταν λες performance της εφαρμογής;

Πάντως, ένα γενικότερο σχόλιο, έστω και πάνω στη γενικής φύσεως προηγούμενη διατύπωση: Υποθέτω ότι όταν λες για business logic στις stored procedures μιλάς για Cursors και row by row operations ή διαφορετικά μόνο για set operations όπερ σημαίνει ότι το business logic είναι υπερβολικά απλό (γιατί περίπλοκο business logic χωρίς procedural λογική μου είναι λίγο δύσκολο να φανταστώ). Στην πρώτη περίπτωση μου κάνει μεγάλη εντύπωση να έχει καλό performance ένα σύστημα που βασίζεται σε server side cursors καθώς αυτοί συνεπάγονται temp tables, εκτεταμένο locking και διάφορα άλλα δεινά . Άπό την άλλη, στην δεύτερη περίπτωση οι stored procedures σαφώς δεν προσφέρουν διαφοροποίηση στο performance σε σχέση με τα dynamic queries.

---

Vir prudens non contra ventum mingit

Ας μου επιτραπεί να ξεκαθαρίσω μερικά πράγματα, μιας και τα posts μεταφέρθηκαν (και καλώς μεταφέρθηκαν) από ένα άλλο αρχικό Posts το οποίο είχα χρησιμοποιήσει ως βάση.... οπότε τώρα μερικά πράγματα φαίνοται λίγο ξεκάρφωτα....

Πράγματι το θέμα performance ειναι τεράστιο και όποτε κάποιος το θίγει, κάποιος άλλος θα του πει (πολύ σωστά).... "Ρε φίλε τι εννοείς perfomance?"
Μήπως εννοείς τα παρακάτω βασικά settings πρέπει να καθοριστού, όπως:
DBCC FREEPROCCACHE on
DBCC DROPCLEANBUFFERS on
CHECKPOINT
SET STATISTICS IO on
SET STATISTICS TIME on
SET STATISTICS PROFILE on
SET SHOWPLAN_ALL
κλπ κλπ....

Όχι.... δεν εννοώ αυτό.
Εννοώ το εξής:
Είσαι στον πελάτη την 1η μέρα της εφαρμογής του νέου προγράμματος (live).
Μια ουρά 10 ατόμων περιμένει να βγεί το πρώτο τιμολόγιο για να εξυπηρετηθεί ο επόμενος....
Αυτό πεισματικά αρνείται να εκτελεστεί γρήγορα!
Γυρίζει ο χρήστης και σου λέει:
"Μα το πρόγραμμα σε DOS που είχα πριν που ήτανε σε.... Clipper το έβγαζε... πιο γρήγορα."
Γυρίζει ο ιδιοκτήτης και σου λέει:
Εγώ έδωσα 30.000 euro για να πάρω μηχανήματα, προγράμματα, δίκτυα, server, καλώδια, να βάλω όλους του χρήστες μου στο δικό σου πρόγραμμα.... και όλα αυτα?? για να είναι πιο αργό από το προηγούμενο?
Τι του λες?
Όταν όμως "γυρίσαμε" όλες τις  διαδικασίες τιμολόγησης από τον client (Delphi) στον server με stored procedures.... οι χρόνοι με 5 χρήστες,... μειωθήκανε στο 75% και στο 50% του.... Clipper!!! {DOS σ' έφαγα!!}
.... αυτό εννοώ performance...

Ζητώ συγγνώμη αν το ύφος μου για μερικούς συγγραφείς βιβλίων ήτανε λίγο ειρωνικό αλλά σας διαβεβαιώ οτι έχω ξοδέψει πάρα πάρα πολλές ώρες προσπαθώντας να μετατρέψω το "ιδεατό" σε ..."ύλη"... ματαίως!
Η μπάλα παίρνει και το "πολύ" Object Oriented Programming.... αλλά αν αρχίσω και μ' αυτό ... θα ξεφύγουμε... και ίσως δεν τελειώσουμε ΠΟΤΕ!

Που θέλω να καταλήξω?
Οτι πολλές φορές η πιο απλή και ίσως "παρακατιανή" λύση είναι και η καλύτερη αντιμετώπιση ενός πραγματικού προβλήματος.
Και να καταθέσω οτι αυτό που μετράει (στην τελική) είναι το αποτέλεσμα.

---

Nothing to declare...

Αυτό που περιγράφεις, είναι ότι από client/server αρχιτεκτονική, με τις βαριές εργασίες στον client, πήγατε σε client/server με τις βαριές εργασίες στο server. Το N-Tier ή το object-oriented δεν εφαρμόστηκε πουθενά, ή τουλάχιστον δεν αναφέρεις ότι εφαρμόστηκε πουθενά. Αυτά που περιγράφεις λένε απλά ότι η αρχική εφαρμογή ήταν κακοσχεδιασμένη. Γι αυτό κι εγώ στην αρχή είπα ότι η σύγκριση πρέπει να γίνει μεταξύ καλοσχεδιασμένης εφαρμογής client/server και καλοσχεδιασμένης N-tier. Όταν συγκρίνεις κακή σχεδίαση με καλή σχεδίαση, η καλή είναι πάντα γρηγορότερη.

Περιπτώσεις σαν και αυτές που περιγράφεις έχω αντιμετωπίσει άπειρες και συνήθως αφορούν εφαρμογές οι οποίες ξεκίνησαν σαν dekstop εφαρμογές για ένα χρήστη και "προσαρμόστηκαν" να δουλέψουν σε περιβάλλον client/server. Το αποτέλεσμα ... απίστευτες καθυστερήσεις. Ο κώδικας που δούλευε γρήγορα με την τοπική βάση, είναι απίστευτα αργός σε client/server. Συνήθως αυτό οφείλεται στο ότι αντί για queries χρησιμοποιήθηκαν cursors/Recordsets/Datasets στον client με αποτέλεσμα ο κάθε client να κρατάει ανοικτές συνδέσεις και locks για πολύ μεγάλο χρονικό διάστημα, και να υπάρχει πολύ μεγάλη κίνηση στο δίκτυο. Ο λόγος που πολλοί επιλέγουν τέτοιες λύσεις είναι ότι νοιώθουν άβολα με την SQL και δεν έχουν καταλάβει το σχεσιακό μοντέλο, το οποίο αφορά την επεξεργασία συνόλων από δεδομένα και όχι την επεξεργασία μίας γραμμής τη φορά.

Για 5 μόλις χρήστες η χρήση του client/server δεν είναι κακή, αν και μπορεί να σε καθυστερήσει άσχημα, π.χ. όταν 2 χρήστες προσπαθήσουν να τρέξουν ταυτόχρονα δύο βαρειά reports, ή αν τρέξουν και οι δύο stored procedures τα οποία μπλοκάρουν το ένα το άλλο. Εξάλλου, οι κακογραμμένες stored procedures και triggers, η χρήση cursors αντί για nested queries, τα κακά ή ανύπαρκτα indexes θα δημιουργήσουν και αυτά σημαντικές καθυστερήσεις, ακόμα και με τους 5 χρήστες.
Όταν όμως χρειαστεί να υποστηρίξεις λίγο μεγαλύτερες εγκαταστάσεις, π.χ. 20 χρήστες, θα αντιμετωπίσεις πάλι πρόβλημα. Γι αυτό και οι (σωστά σχεδιασμένες) εφαρμογές είναι 3-tier και χρησιμοποιούν COM+ ή (πλέον) WCF. Άσε που και η ανάπτυξη είναι ευκολότερη, καθώς η διαχείριση των transactions και των συνδέσεων είναι πολύ ευκολότερη.

Και επειδή, όπως λες, αυτό που μετράει στο τέλος είναι το αποτέλεσμα, η ταχύτητα μιας καλής 3-tier αρχιτεκτονικής μπορεί να αυξάνεται ακόμα και γεωμετρικά σε σχέση με μία client/server. Κι εγώ πριν από 7 χρόνια συνάντησα μία εφαρμογή η οποία έκανε τον μεγαλύτερο όγκο της δουλειάς στους client, και δεν μπορούσε να τρέξει σωστά τους 10 client, όχι τους 50 που ήθελε ο πελάτης. Οι προγραμματιστές που είχαν φτιάξει την εφαρμογη βλέπεις, την είχαν φτιάξει για desktop, όχι για client/server . Με φοβερό κόπο το data processing μεταφέρθηκε στη βάση, αλλά και πάλι τους 50 χρήστες ... Η νέα έκδοση της εφαρμογής σχεδιάστηκε από το 0, σε λογική 3-tier και στόχο να δουλέψει με 200 χρήστες. Η ανάπτυξη της ήταν πολύ ευκολότερη (καθώς έλειπε η απειλή των συνεχών blocks) και είναι αυτή η οποία μπόρεσε να σηκώσει τους 10.000.

Πρόσφατα αντιμετώπισα μία παρόμοια περίπτωση. Και πάλι κακή σχεδίαση, client/server αυτή τη φορά με το μεγαλύτερο μέρος του data processing στη βάση, αλλά με cursors, temp tables, χαμός. Έπρεπε από 5 χρήστες που εξυπηρετούσε συνήθως η εφαρμογή να εξυπηρετήσει 20, αλλά κανείς δεν ανέλαβε να πει στο αφεντικό ότι έπρεπε να σχεδιαστεί από την αρχή. Αποτέλεσμα ... η εφαρμογή ποτέ δεν έφτασε τους 20 χρήστες και στο τέλος το έργο ακυρώθηκε.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Το θέμα συνοψίζεται όπως πολύ σωστά αναφέρεις στον κακό σχεδιασμό.

Ο κακός σχεδισμός μπορεί να "αχρηστεύσει" οποιαδήποτε μεθοδολογία.... ή αρχιτεκτονική (δεν θα τα χαλάσουμε εδώ!).

Όταν κάποτε κάναμε το τεράστιο λάθος να υλοποιήσουμε τόσες κλάσεις όσα και τα tables μιας βάσης που η υλοποίηση κάθε κλάσης (object) μια member function επέστρεφε κάθε φορά ΟΛΕΣ τις στήλες του πίνακα ανεξάρτητα του πόσες στήλες θέλαμε πραγματικά,... το μετανοιώσαμε πάρα πολύ πικρά!
Ο SQL Server αλλά και οποιαδήποτε βάση θα σου επιστρέψει ίσως με ελάχιστη χρονικη διαφορά είτε 10 rows είτε 100,... η διαφορά όμως θα είναι τεράστια αν ζητήσεις 10 στήλες σε σχέση με 100... (λέμε τώρα).

Θα συμφωνήσω με το Performance  στα θέματα cursors, isolation levels, with(no lock) cases, indexes!!, left/outer/inner joins, ταχύτητα διαμεταγωγής στο δίκτυο, πλήθος χρηστών, πλήθος hits/sec στον server, μεγέθους των transactions (ASAP => As Short As Possible ), μεγέθους της μνήμης του server, σεταρίσματος του SQL-server, χρήση terminal server ή πιο καθαρού C/S με client & server διαφορετικά Κλπ Κλπ....

Όμως η λέξεις Object Oriented και "κακός σχεδισμός" πολλές φορές ίσως χρησιμοποιείται και ως άλλοθι όταν η ίδια η σχεδίαση δεν μπορεί να προσαρμόζεται (ή να είναι μη εύκολα προσαρμόσιμη "non-adaptable") σε ένα δυναμικό σύστημα που υπόκειται σε πολλαπλές αλλαγές πάρα πολύ συχνά! Πολλές φορές, αυτή η ανάγκη απαιτεί τον σχεδιασμό να είναι τόσο abstract που είναι δώρον-άδωρον η ωφελιμότητα του.
Ο σχεδιασμός με κλάσεις απαιτεί αρκετές φορές αυστηρή ανάλυση και σχεδιασμό των οντοτήτων, των σχέσεων μεταξύ τους καθώς και των ιεραρχιών τους. Όταν όλα τα παραπάνω αλλάζουν δυναμικά είναι πάρα πολύ δύσκολο να συλλάβεις, να υλοποιήσεις και να επιτύχεις ένα σχεδιασμό που θα "αντέξει" στα δύσκολα!

Μιας και αναφέρθηκες στην περίφημη 3-tier architecture θα ήθελα να αναφέρω τα εξής:
tier-1: Database
tier-2: Business Logic
tier-3: Client Interfece (GUIs, Forms etc.)

Το business logic πως το υλοποιείς?
Με κάποιον application server? Αν ναι, αυτός ο server υλοποιείται φυσικά σε 3ο μηχάνημα ή στο device του Data Base server?
Σε κάθε περίπτωση δεν υλοποιείς ένα πρόσθετο Layer?
Το tier 2. Που το υλοποιείς αυτό?
Πως γίνεται ένα layer παραπάνω να μειώνει αντί να προσθέτει overhead?
Επίσης είμαι περίεργος (χωρίς όμως να το αμφισβητώ) πως υλοποιείς πιο εύκολα το 3-tier με transactions? Με MTS?
Αν θα ήθελες και μπορούσες να έδινες ένα παράδειγμα με το software που χρησιμοποίησες κάθε φορά.
Π.χ.
tier-1: Database SQL Server
tier-2: Business Logic σε MSC++ και MTS και COM+...
tier-3: (GUIs, Forms etc.) σε DELPHI με αρχιτεκτονική COM + remote datamodules για την επαφή τους με τον middle layer (2nd tier)

Το COM γενικά δε θα έλεγα πως είναι οτι καλύτερο έχει υλοποιηθεί για open architecture και inter-process communications... αν και νομίζω οτι δεν "παίζει" πια.... άσε που στον Win2003 είναι by default false για λόγους security (άλλος πονοκέφαλος ... εκεί - να το σετάρεις να "παίζει")

Επισης η λογική 200 χρήστες με 20 συνδέσεις προσωπικά δεν την έχω δοκιμάσει αλλά σε peaks δεν θα δημιουργεί απίστευτο collision? - εκτός κι αν από τους 200 κάθε φορά κάνουνε real hits οι 20.

---

Nothing to declare...

Μου ζητάς να σου περιγράψω όλη τη θεωρία του N-tier και του τρόπου υλοποίησης σε Windows? Αυτό είναι θέμα ολόκληρων βιβλίων. Το "COM and .NET Component Services" του Juval Lowy είναι ένα πολύ καλό βιβλίο για το θέμα. Εξάλλου, MTS δεν υπάρχει εδώ και 7 χρόνια. MTS ήταν το service το οποίο υπήρχε το 1999 στα Windows NT 4. Από εκείνο τον καιρό έχουν αλλάξει πάρα πολλά πράγματα. Το service λέγεται COM+ και έχει τεράστια διαφορά με τον MTS.

Απ' όσα λες φαίνεται ότι έχεις μπλέξει τον MTS με το COM, το DCOM και το COM+. To COM και το DCOM είναι πρωτόκολλα, ο MTS και το COM+ services.

Για να σου γράψω την εξέλιξη στην αρχιτεκτονική εφαρμογών των τελευταίων 7 ετών θα χρειαστεί να γράψω ένα ολόκληρο άρθρο. Καλύτερα να ψάξεις π.χ. στο MSDN Magazine για να βρεις ένα τέτοιο άρθρο, καθώς οι αρθρογράφοι του σίγουρα είναι καλύτεροι από εμένα. Αν θέλεις, μπορώ να σου απαντήσω σε συγκεκριμένες ερωτήσεις, όπως π.χ. γιατί το connection pooling είναι καλύτερο από τα πολλά ταυτόχρονα connections. Διαφορετικά θα πρέπει να πάρουμε όλη την κουβέντα περί αρχιτεκτονικής από τα βασικά.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Οι ερωτήση μου πιστεύω οτι ειναι και απλή και ξεκάθαρη.
Άσχετα με το αν πιστεύεις για το τι έχω μπερδέψει και τι όχι - lol - (δεν θα το σχολιάσω μιας και τα τυπογραφικά λάθη είναι πανεύκολα όταν ασχολείται κάποιος με τον OcenAbreeviation της Μ$oft) και μάλλον υπέπεσα σε μερικά τέτοια...

Δεν νομίζω όμως οτι χρειάζεται καμιά βιβλιογραφία για να δείξεις πως υλοποιείς κάτι. Αν το υλοποιείς τελικά.

Επίσης θα ήθελα real world Xmples... αν είναι με την 1η ευκαιρια να με παραπέμπεις σε.... βιβλία.....

Anyway.... νομίζω δεν βγάζει κάπου...

Σ' ευχαριστώ για τον χρόνο σου.

 

---

Nothing to declare...