[Tech] Gestionali, Mysql e altre domande

[Marco Ermini]

Christian Surchi <christian@firenze.linux.it> wrote:
> On Wed, Feb 12, 2003 at 12:48:10PM +0100, Marco Ermini wrote:
> > Io vorrei scrivere un software che sia web based, quindi scalabile
> > dalla
> > singola macchina alla multiutenza. Mi dispiace dirlo, ma il paradigma
> > client-server da un punto di vista tecnologico e' morto e sepolto,
> > sono anni che e' in auge il three-tier.
> 
> "Che cavolo stai dicendo, Willis?" :-)
> 
> A casa mia con "three-tier" si intende la separazione dello sviluppo tra
> dati e sistema di accesso, con metodologie, scelte tecniche e spesso
> anche piattaforme diverse, ma il tutto in una architettura che resta
> client-server, visto che devi comunque accedere ad un db. 
> Non vedo proprio da cosa e come possa essere stato sepolto il paradigma
> client-server.

Allora, come (quasi) tutti dicono i professori universitari, "grazie per
avermi posto la domanda" ;-)

Anche se francamente credevo di sfondare una porta aperta...


> Riferimenti esplicativi sui termini usati:
> 
> 
> http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=client-server
> 
> http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=three-tier

Innanzitutto inviterei a non prendere definizioni da dizionari, tanto piu'
online ;-) comunque, a parte le battute, immagino che si tratti piu' che altro
di capire quale significato si danno alle parole. Io sto per riportare quello
che generalmente si intende nel poco popoloso mondo degli analisi e degli
architetti di sistema di cui da relativamente poco mi onoro di appartenere;
uno sviluppatore, magari piu' incentrato sui dettagli, potra' ritenere i
concetti forse logicamente piu' simili o sfumati di come non li veda io.
Questo, per dire che non pretendo di riportare una definizione da dizionario,
ma solo di dire cosa "la maggioranza" in genere intende, ma ovviamente possono
essere punti di vista.

Innanzitutto, chiariamo che quando si parla di client/server e di three-tier
si sta parlando ovviamente di analisi architetturale, ma soprattutto da un
punto di vista logico ("logical architecture") e, se siamo gia' al three-tier,
siamo nell'ambito della decomposizione del problema tramite la metodologia
dell'analisi object oriented. Three-tier, come dice la parola stessa, e' un
modello di analisi e progettazione di applicazioni che propaganda la
separazione tra tre "livelli di business" come dicono i "dotti" dell'analisi,
ovvero la parte di presentation, quella di backend e l'RDBMS. Ripeto si sta
parlando di analisi al fine dell'implementazione architetturale (casomai
rimanderei a http://www.rational.com/products/whitepapers/461.jsp).

Quando si parla di client/server si sta parlando di un vecchio paradigma, in
auge soprattutto in epoca "pre-web revolution", se mi passate il linguaggio da
 hippie ;-), che significa in genere GUI + RDBMS (mi si potra' obbiettare che
e' molto di piu'. Sono d'accordo nel senso che, in applicazioni abbastanza
grandi e che subiscono variazioni spesso nel giro di una settimana, come
quelle MIS, le scelte architetturali e di object-orientation si e' costretti
comunque a farle; si veda l'eccellente whitepaper in proposito di Grady Booch
"Objectifying Information Technology", che mi pare sia disponibile anche sul
sito Rational).

Parlando invece di three-tier si parla, *in genere*, di una frammentazione
dell'architettura diversa. Intanto, siamo in un'epoca e in un contesto
completamente differenti. C'e' stato il "boom" del web, e sono sorte nuove
esigenze. In una applicazione client/server, il numero di utenti e'
controllato (quantificabile in genere in centinaia o migliaia), la "distanza
concettuale" tra l'RDBMS e il client e' poca, le applicazioni sono in genere
modellate sul database (o sui database) che sono al "centro" del sistema, e
consistono lato client in un applicativo installato localmente che puo' essere
ragionevolmente cambiato ma e' sostanzialmente stabile, e su cui si pongono
notevoli problematiche di software redistribution (per fare un esempio tecnico
che forse mi fa comprendere di piu': il locking sull'RDBMS e' affrontato con
nei modi piu' disparati, lato client, lato RDBMS o misto...). In caso di
three-tier, si presuppone un contesto totalmente diverso: il numero degli
utenti e' a volte imprevedibile (e puo' essere anche nell'ordine dei milioni),
la composizione del backend e' estremamente variegata e composta di molte
parti diverse che cambiano ed evolvono in continuazione. Infine, gli attori
(nella terminologia di "attore" UML) in gioco sono in genere molto pochi in
una applicazione client/server, in una three-tier possono essere molti (giusto
per dire i primi che vengono in mente, i content provider, o i graphic
designer).

Questo cosa implica dal punto di vista dello sviluppo? implica un fork
abbastanza deciso nelle metodologie del processo di ideazione, progettazione,
realizzazione, test e deploy delle applicazioni, che come e' facile intuire e'
completamente diverso nei due casi - mi risultano ben pochi *casi reali* dove,
per esempio, il paradigma MVC sia applicato ad una GUI di una applicazione
client/server... ovviamente cio' e' teoricamente possibile, ma l'unico
tentativo che ho visto fare e' stato in un progetto di IBM per Trenitalia a
cui ho partecipato e che dopo un anno di giri a vuoto e' stato sospeso...
mentre nel mondo web e' una prassi a dir poco abitudinaria, praticamente.

Posso altresi' capire che, nell'ambito di applicazioni relativamente piccole,
o comunque dove non c'e' stato un processo di razionalizzazione degli
strumenti utilizzati per lo sviluppo, e da parte di programmatori che non
hanno una particolare formazione sull'argomento (cosa assolutamente normale e
giusta, non preoccupatevi, anche perche' in genere non e' il programmatore che
si occupa di queste cose ;-) la percezione della differenza tra le due
architetture sia relativamente poca (prima facevo una GUI e mi collegavo ad un
DB, ora faccio delle pagine PHP e mi collego ad un DB: per lo sviluppatore si
puo' quasi dire che siano cambiati solo il linguaggio e qualche altro
strumento di sviluppo!!!). Questo magari succede a livello degli sviluppatori,
oppure in realta' "limitate" da molti punti di vista o locali, che se gli
parli di non dico di RUP, ma anche solo di UML, metodologie di analisi o
architettura del software ti guardano a bocca aperta (o ti sputano nel viso
;-)

Ora, tornando allo scopo originale del thread, cosa significa questo in
pratica ed in particolare per Umberto? che la sua applicazione non e' non
sara' mai grande e complessa come il sistema demografico della Protezione
civile o il servizio di raccolta dati elettorali della Prefettura e quindi
sicuramente non servira' una analisi Vision 2000 per portarla da Access a PHP,
pero' significa che personalmente preferisco *tenere in mente* che esistono
architetture e paradigmi diversi, e preferisco rimanere in un ambito in cui io
possa modularizzare il piu' possibile l'applicazione, in modo eventualmente da
poterla facilmente rendere piu' generica o utile anche ad altri - a maggior
ragione perche' potrebbe essere distribuita come GPL.


ciao

PS. scusate la prolissita', sara' la digestione dell'arancino che mi sono
appena pappato :-P


---
Marco Ermini
http://macchi.markoer.org - ICQ 50825709 - GPG KEY 0x64ABF7C6 - L.U. #180221
Perche' perdere tempo ad imparare quando l'ignoranza e' istantanea? (Hobbes)