Newsgroup: it.comp.programmare
Titolo: Abbandonare i batch files

Ciao,
spero sia il newsgroup corretto, dato che la domanda è piuttosto
generica.
Lavoro in banca e quotidianamente, da anni, ricevo e gestisco decine e
decine di flussi - classici batch files provenienti da DB2 - tramite
DTS o comunque applicazioni eseguite da un client "integrato"
all'applicazione che utilizza i dati.
Vorrei provare ad evolvere l'attuale architettura in una orientata ai
servizi, spostando quindi la business logic verso l'esterno per
renderla fruibile a tutte le applicazioni che ne fanno uso.
Insomma: vorrei fare in modo che le applicazioni consumino dei servizi
per rendere più agevole anche la manutenzione/evoluzione del layer
dedicato ai dati.
Tra i tanti tasselli mi piacerebbe utilizzare dei web services per
fare in modo che i vari dipartimenti della banca non spediscano a noi
decine e decine di flussi in standard differenti (enormi stringhe
posizionali di testo) facendo invece in modo che possano "invocare" un
web service diventando parte attiva del processo che non vivrebbe più
di polling e/o schedulazioni.
Il dubbio è: le informazioni che in modalità batch vengono accodate in
flussi da decine o centinaia di MB, possono mettere in crisi un web
service a livello prestazionale (memoria, stress della CPU...)?
Immagino che l'utilizzo canonico sia basato su una singola transazione
piuttosto che per caricamenti di massa, ma se le prestazioni non sono
un problema può essere un passo per muoversi verso la nuova
architettura.
Grazie!
Bye,
   Ricky

 service a livello prestazionale (memoria, stress della CPU...)? 
Dipende da come è scritto il web service e l'application server.
In teoria non ci sono problemi.
Una volta ricevuti questi dati, che ci deve fare il web service?
Manlio Perillo

Una volta ricevuti questi dati, che ci deve fare il web service?
Ci sono alcuni scenari possibili.
Un esempio tipico potrebbe essere quello di un controllo di base
portato a termine tramite una lista di esclusione ottenuta
interrogando una tabella in un DB.
I passi successivi sono potenziali INSERT o UPDATE, magari tramite
stored procedure, verso il DB di produzione.
Senza però far accedere nessuno direttamente al DB di produzione o
"scolpire" troppa logica nelle stored o in DTS poi difficili da
manutenere.
Parlo di flussi con 20-30.000 record da parsare (nel web service) e da
scrivere in un DB in sostanza, a partire da un qualsiasi sistema
informativo che possa raggiungere la porta 80 di un mio web server.
Che ne pensi?
Bye,
   Ricky

 
Che se puoi parsare e processare un record alla volta non ci sono 
problemi, dato che puoi processare i dati man mano che arrivano dal 
client.
Il tutto dipende, comunque, anche da quanti di questi flussi deve gestire 
il server al minuto (ma sospetto siano pochi).
Per scrivere nel database, ti consiglio di fare alcune ottimizzazioni, 
invece di effettuare una query per record.
Ad esempio, per le INSERT, puoi aspettare di avere N records, e poi fare 
una unica query.
Versioni recenti di PostgreSQL (>= 8.2) permettono insert multiple:
http://www.postgresql.org/docs/8.3/interactive/sql-insert.html
(ma non so se sia standard).
Oppure puoi usare COPY (sempre con PostgreSQL), che dovrebbe essere il 
metodo più efficiente.
Ciao  Manlio