Newsgroup: it.comp.lang.c++
Titolo: Architettura sistema 3-tier: ACE? [lungo]

Ciao a tutti,
mi dispiace per il messaggio un po' troppo vago mandato in precedenza a cui
"sbirish" ha dato risposta con richiesta di dettagli.
Il problema che mi trovo a dover risolvere e' relativo alla migrazione di un
sistema 2-tier verso un sistema 3-tier.
In realta' sarebbe piu' corretto parlare di un sistema 2-tier e 1/2 poiche'
l'applicazione che devo modificare ha gia' parti realizzate secondo una
specie di architettura a 3 livelli.
Ad oggi la parte client dell'applicazione e' realizzata in C++ (Microsoft
ver 6.0), la parte che adempie a ruolo di Application Server e' anch'essa
realizzata in C++ (sempre Microsoft ver 6.0) ed a valle di tutto cio' c'e'
il solito Oracle.
2 tier e 1/2 perche' vi domanderete.
Semplice... dipende dal fatto che i dati sono sempre stati sullo stesso DB
(Oracle quindi) e che da tempo le persone, sapendo che i DB sarebbero
restati quelli, hanno fatto uso chi + chi - di chiamate mediante NET8
direttamente ad Oracle. (Per la cronaca... non pensate a niente di non
standard... NET8 e' C++ di basso profilo). Abbiamo quindi che certuni hanno
realizzato SW a 3 livelli, altri no.
Passiamo all'application server.
Realizzato a suo tempo... ironizzerei dicendo "Made in Jerusalem"... e'
MOLTO light... Non ha niente a che fare con i moderni AS. Semplicemente e'
un eseguibile che analizza dei pacchetti in ingresso, ne fa un parsing crudo
ed avanza richieste al DB di turno.
Cardinalita':
Esistono 19 DB sparsi in tutta Italia... con dati diversi. Su ognuno di essi
viene fatto girare il suddetto light Application Server.
Un AS vede solo il DB della macchina server (DB server) sul quale viene
fatto girare.
I client... tenetevi forte... 5000 e destinati a crescere. Alcuni rimarrano
su Visual C++ altri faranno uso di una versione light che girera' su web.
Trasferimento dati:
Il grosso degli utenti fa attivita' di accesso ai DB alle stesse ore (o
diciamo in un certo intervallo di tempo... le prime ore della mattina per
intenderci).
La mole dei dati non e' il classico centinaio di k, bensi' una sorta di vero
e proprio download: fino a 5 mega (caso peggiorativo, il caso medio viaggia
sui 700k).
Allora... il sistema sta diventando debole, non e' piu' supportato e
manutenuto l'AS ed il protocollo basato su TCP sul quale comunica il client
con l'AS va incontro allo stesso destino.
Indi... scatta il redesign dello strato comunicativo.
Obiettivo:
1-gestire la compressione dei dati tra AS e client. Attualmente la coppia
"protocollo di  comunicazione/AS" supportano la compressione dei dati.;
2-gestione delle transazioni
Obiettivo (mio):
1-Non riscrivere tonnellate di codice gia' scritto
Molto infatti e' gia' stato fatto in passato e la comunicazione verso il DB
con NET8 va bene. (Questo permette anche di gestire le transazioni).
Vorrei sapere cosa ne pensate sull'argomento... tenendo presenti i numeri di
cui vi ho detto e che una buona fetta di utenti in futuro si potra' anche
accontentare di un client light via web. ...si introduce quindi un discorso
Java.
La mia idea fino a qualche giorno fa e' stata relativa all'uso della
libreria gSOAP. Carino... in specie per quanto concerne allo sviluppo futuro
con client Java. Purtroppo non ho alcuna gestione delle transazioni con
l'adozione di SOAP.
Ho pensato quindi ad ACE... se non altro confidando sulla bonta' della
libreria in seguito alla scelta di Stroustrup di trattarlo nei testi di una
sua collana (dopo aver considerato Andrei Alexandrescu, Boost (Graphic
Library), Exceptional e More Exceptional tanto per citarne altri).
Purtroppo non so nulla di ACE, per la cronaca non so nulla di Corba, quindi
eccomi qui. Chi vuole condividere la scelta con me si faccia avanti.
Grazie a quanti sono gia' arrivati fin qui a leggere,
Francesco Vitale
fRA

Francesco Vitale
... scusa l'invadenza francesco.. posso contattarti in privato?
sbirish

 ha scritto nel messaggio
news:6285cv84s36ccni2b...@4ax.com...
